* Introduce a new "added-in" template and use it on endpoints
* Use "added-in" on schema properties too
* Annotate sections of the spec with their added versions
* Demo of "added-in" on a room version (to be fleshed out)
* Use clearer versioning semantics
* Update and fix validator for Swagger custom properties
* Fix docs
* Cut/paste room version spec to its own page
* Move grammar to bottom + add feature matrix
The version grammar is not as interesting as the actual room versions, so this moves that whole section to the bottom.
* Fix all links to room versions
* Clarify how redacted_because actually works for events
* changelog
* mention federation
* Fix wording
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
The Pagination section in the C-S API was, basically, full of rubbish. I think that anything of any value it contained was repeated either directly on the API definitions or in the text specific to syncing at https://spec.matrix.org/unstable/client-server-api/#syncing.
The conventions I've added to the Appendices are based on the discussions in #1898. They are there because I don't want to have to go through it all again next time we add a paginated API.
Fixes: #1898Fixes: #2268
This change drops the Origin and Accept header names from the
recommended value for the CORS Access-Control-Allow-Headers header. Per
the CORS protocol, it’s not necessary or useful to include them.
Per-spec at https://fetch.spec.whatwg.org/#forbidden-header-name, Origin
is a “forbidden header name” set by the browser and that frontend
JavaScript code is never allowed to set.
So the value of Access-Control-Allow-Headers isn’t relevant to Origin or
in general to other headers set by the browser itself — the browser
never ever consults the Access-Control-Allow-Headers value to confirm
that it’s OK for the request to include an Origin header.
And per-spec at https://fetch.spec.whatwg.org/#cors-safelisted-request-header,
Accept is a “CORS-safelisted request-header”, which means that browsers
allow requests to contain the Accept header regardless of whether the
Access-Control-Allow-Headers value contains "Accept".
So it’s unnecessary for the Access-Control-Allow-Headers to explicitly
include Accept. Browsers will not perform a CORS preflight for requests
containing an Accept request header.
Related: Related: https://github.com/matrix-org/synapse/pull/10114
Signed-off-by: Michael[tm] Smith <mike@w3.org>
Travis Ralston