-
-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CORP headers to media repo #1197
Conversation
@@ -19,6 +19,12 @@ When serving content, the server SHOULD provide a | |||
`Content-Security-Policy` header. The recommended policy is | |||
`sandbox; default-src 'none'; script-src 'none'; plugin-types application/pdf; style-src 'unsafe-inline'; object-src 'self';`. | |||
|
|||
{{% added-in v="1.4" %}} | |||
|
|||
The server SHOULD additionally provide `Cross-Origin-Resource-Policy: cross-origin` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we weren't doing RFC2119 keywords?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since when? We've always used SHOULD and MUST, just not MAY. It's in the API standards section...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷 fair enough. I thought at some point we'd decided not to use it as it's not familiar for most readers.
It's in the API standards section...
I don't see this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I swear it was there. Somewhere we describe that we use MUST and SHOULD (which have the same meaning as must and should), but not MAY and such.
If we don't have this written down somewhere, my whole life has been a lie 😭
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd search github for "MUST", but that isn't going to go well :-S
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though our content doesn't need 2 paragraphs, it's good to have the capability to render it in the future.
// Make pairs of "added-in" and content inline to each other. We do pairs so authors can | ||
// describe two paragraphs with added-in prefixes within a single box, reducing DOM | ||
// complexity. Each paragraph is expected to be prefixed with an added-in, however. | ||
// | ||
// XXX: We assume the added-in and text will be rendered as paragraph elements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as mentioned in the commit: we don't need the complexity of 2+ paragraphs yet, but it's good behaviour to have for when we need it in the future.
can/should we simplify this now that #1204 is (hopefully) fixed? |
MSC: matrix-org/matrix-spec-proposals#3828
Preview: https://pr1197--matrix-spec-previews.netlify.app