This tweaks the DAG to be simpler, with two linear event chains E4 -> E3
-> E2 -> E1 and E6 -> E5 -> E2 -> E1. The extremities of the DAG are now
the first and only point in the DAG where multiple event parents occur.
Since the point of the diagram is to demonstrate this very situation,
it's better didactically if there is only one such situation in the
diagram.
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>
Fixes#3146.
This PR changes the Matrix Spec Proposals page to clarify that implementations **do not** need to wait until a spec release to use stable prefixes, but that they can do so after the corresponding MSC has been merged. The justification is that once an MSC has been merged, it's fairly guaranteed that it will land in the spec. Yet it will take time for the spec release process to run its course, and we shouldn't make implementations wait for that.
The exception to this is if implementating a feature in a backwards-compatible way requires a new spec version to indicate to clients/servers that a feature has been added/changed. This situation is rare though, and most implementations won't fall into this category.
It wasn't entirely clear what should happen to the FCP timer (and state) when a concern is raised during FCP. After some discussion, we agreed that when a concern is raised:
1. FCP will continue to not conclude until at least 5 days have passed, but once those 5 days are up it *still* won't conclude until all concerns raised during FCP are resolved.
2. If a concern warrants a large enough change in the document, then the Spec Core Team may consider cancelling FCP and restarting the timer in order for people to have some time to think about and review the new changes.
Denis Kasak