Return 200 OK for all OPTIONS requests#7534
Conversation
|
I requested review on this to make sure I'm on the right page. I left a few questions in the description which need to be worked through still. |
|
(I haven't thought about this, but is a possible alternative to just reply to all options requests, no matter the path?) |
|
@erikjohnston That could be an option (no pun intended) as well. We could probably do it via the root endpoint actually. I'll take a look at that. |
|
@erikjohnston So looks like it IS possible, although as you said we need to think about whether that makes sense. I just pushed b390d12 although I don't expect anything to break from it. |
|
Yeah, personally I think just returning OPTIONS everywhere is the easiest thing here (saves having to find all the places where we conditionally add resources). |
In the brave new world there shouldn't be a difference between master and workers :)
Yeah, it just means that webapps will have to do another round trip to get the 404. This shouldn't happen in production much, so I think its fine.
🎉 |
The handling of OPTIONS requests was consolidated in #7534, but the endpoint specific handlers were not removed.
This is an attempt to fix #7313.
For workers which don't have amedialistener it adds dummy endpoints which return a 200 OK forOPTIONSrequests to themselves and any leaf below them. Any other requests method (POST,PUT,GET, etc.) is a 404.For all endpoints under the root endpoint it will return a 200 OK for
OPTIONSrequests. Other requests will act as "normal".I do have some questions:
/_matrix/media/r0/foo/bar). Is that OK?