Document the CORS/preflight headers #1365
Conversation
specification/client_server_api.rst
Outdated
|
|
||
| It is realistic to expect that some clients will be written to be run within a | ||
| web browser or similar environment. In these cases, the homeserver should respond | ||
| to pre-flight requests and supply Cross-Origin Resource Sharing (CORS) headers. |
There was a problem hiding this comment.
maybe "... supply Cross-Origin Resource Sharing (CORS) headers on all requests." (add "on all requests" at the end.)
specification/client_server_api.rst
Outdated
| to pre-flight requests and supply Cross-Origin Resource Sharing (CORS) headers. | ||
|
|
||
| When a client approaches the server with a pre-flight (``OPTIONS``) request, the | ||
| server should respond with the CORS headers for that route. If the route does not |
There was a problem hiding this comment.
s/should/must/ ? (and also on the next line)
There was a problem hiding this comment.
"must" makes sense for the first one. The second one actually seems to have a whole different story to it.
Abbreviated console output:
$ curl -sv -X OPTIONS https://matrix.org/_matrix/client/r0/this/does/not/exist
< HTTP/2 200
< date: Wed, 04 Jul 2018 20:23:25 GMT
< content-type: application/json
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
There was a problem hiding this comment.
What do you think about specing it as 200 OK for OPTIONS? (the alternative being leaving it undefined and putting that part through the proposal process, imo)
There was a problem hiding this comment.
I think that we can leave it undefined for now, and, looking at this again, we might also want to leave the exact headers undefined as well, as some servers may want to be more or less strict about some of them. e.g. some servers may want to set Access-Control-Allow-Methods to only return the methods that actually exist on that route. Maybe just suggest that servers should set Access-Control-Allow-Headers to allow for Origin, X-Requested-With, Content-Type, Accept, Authorization.
|
@uhoreg This should be updated now. Please take another look. |
| all requests. | ||
|
|
||
| When a client approaches the server with a pre-flight (``OPTIONS``) request, the | ||
| server should respond with the CORS headers for that route. The recommended CORS |
There was a problem hiding this comment.
I'd personally prefer "An example of CORS headers..." rather than "The recommended CORS headers...", but I'm also fine with it just going in like this.
Fixes #1006
This PR documents existing behaviour and does not attempt to improve or change the situation.
Reference: https://github.com/matrix-org/synapse/blob/53969e196004659c6a9f138f5d8abd86f4957d74/synapse/http/server.py#L455-L462