OPTIONS support

[emersion]

It would be nice to add support for OPTIONS to push endpoints. This would allow the HTTP clients to check which methods are supported and check CORS.

[p1gp1g]

Can be related to #30

@karmanyaahm @sparchatus for suggestions

[emersion]

Hm, it seems like that RFC does not recommend OPTIONS: https://www.rfc-editor.org/rfc/rfc9205.html#section-4.5.2

[karmanyaahm]

idk tbh. Do web browsers really need to post to UP? And in any non-browser context, the current GET based discovery without CORS is sufficient.
Mandating it would further complicate push providers, and making it optional would make it useless for reliable detection.

Do you have a specific use case in mind?

[karmanyaahm]

Yes, semantically, I think it may have been better to do discovery on OPTIONS, but 1. GET is much more common and 2. that ship has already sailed.

[emersion]

My use-case is to check whether a push endpoint is valid without hardcoding anything UnifiedPush specific. I also support other Web Push endpoints.

I've switched to just sending a test push message since then, so I'm okay with closing this.

[karmanyaahm]

Interesting ... Do most web push servers automatically support OPTIONS?

RFC8030 doesn't say anything about it. I agree that being able to detect WebPush and UnifiedPush in one would be helpful, though test pushes are even better. Closing is your call.

[emersion]

At least the Mozilla server (updates.push.services.mozilla.com) seems to support OPTIONS… Haven't tested the rest.

Indeed, RFC 8030 doesn't say anything about it, so nothing would stop a Web Push server from rejecting OPTIONS.

Let's close this for now.