MSC4138: Update allowed HTTP methods in CORS responses #4138
Conversation
turt2live
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- None, in my opinion. See "unstable prefix" section for rationale.
turt2live
removed
the
needs-implementation
matrix-org/matrix-spec-proposals#4138 we already had HEAD Signed-off-by: strawberry <[email protected]>
|
Seems quite reasonable! @mscbot fcp merge |
|
Team member @clokep has proposed to merge this. The next step is review by the rest of the tagged people: Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
mscbot
added
proposed-final-comment-period
matrix-org/matrix-spec-proposals#4138 we already had HEAD Signed-off-by: strawberry <[email protected]>
matrix-org/matrix-spec-proposals#4138 we already had HEAD Signed-off-by: strawberry <[email protected]>
| The following methods are *not* included because they don't have foreseeable use in Matrix: | ||
|
|
||
| * `CONNECT` | ||
| * `TRACE` |
There was a problem hiding this comment.
I might suggest that this could be an MSC where we propose a literal update to the text of the spec: the current spec just plucks a recommendation out of thin air with no explanation of why it's recommended, but this MSC contains a bunch of useful context. I know you're trying to write it without including a reference to an in-review MSC in the spec, but I'm finding the result quite obtuse: "future use" just makes me wonder why the server wouldn't add those methods when it has an endpoint that actually uses them.
I would suggest something along the lines of, "if you implement all of the Matrix spec, you'll need this set, however this expanded set would be safe and sensible should you ever implement any MSCs that use them"?
There was a problem hiding this comment.
or maybe something along the lines of "... if you implement any other endpoints that use other HTTP methods, make sure that you also include those methods on CORS".
There was a problem hiding this comment.
#4138 (comment) is in line with this thread.
Will update the MSC.
|
it feels weird to be allowing methods without matching MSCs that demand them, but not enough to block it. |
| The [`Access-Control-Allow-Methods` header's recommended value](https://spec.matrix.org/v1.10/client-server-api/#web-browser-clients) | ||
| is updated to include the following: | ||
|
|
||
| * `PATCH` - A plausibly useful HTTP method for future use. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
mscbot
added
final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
mscbot
added
finished-final-comment-period
and removed
disposition-merge
final-comment-period
|
updated by #4187 |
turt2live
added
spec-pr-missing
|
Partially addressed by matrix-org/matrix-spec#1995 |
|
Second spec PR: matrix-org/matrix-spec#2011 |
turt2live
added
spec-pr-in-review
Rendered
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published with my role as a member of the SCT.
Related: matrix-org/matrix-js-sdk#4188
FCP tickyboxes