"MXC URI" -> "mxc:// URI" (#1500)

* "MXC URI" -> "`mxc://` URI"

We're a bit inconsistent with this currently, and IMHO "`mxc://` URI" is more
explicit.

* Update content/client-server-api/modules/content_repo.md

Co-authored-by: Hubert Chathi <hubertc@matrix.org>

* more MXCs

---------

Co-authored-by: Hubert Chathi <hubertc@matrix.org>
This commit is contained in:
Richard van der Hoff 2023-04-26 14:11:35 +01:00 committed by GitHub
parent 715f6a301d
commit 1f729eef60
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
12 changed files with 20 additions and 19 deletions

View file

@ -7,7 +7,7 @@ user wants to send to a room would be uploaded here, as would an avatar
the user wants to use.
Uploads are POSTed to a resource on the user's local homeserver which
returns a MXC URI which can later be used to GET the download. Content
returns an `mxc://` URI which can later be used to GET the download. Content
is downloaded from the recipient's local homeserver, which must first
transfer the content from the origin homeserver using the same API
(unless the origin and destination homeservers are the same).
@ -23,9 +23,9 @@ When serving content, the server SHOULD provide a
interacting with the media repository.
{{% /boxes/added-in-paragraph %}}
#### Matrix Content (MXC) URIs
#### Matrix Content (`mxc://`) URIs
Content locations are represented as Matrix Content (MXC) URIs. They
Content locations are represented as Matrix Content (`mxc://`) URIs. They
look like:
mxc://<server-name>/<media-id>
@ -88,10 +88,10 @@ The HTTP GET endpoint does not require any authentication. Knowing the
URL of the content is sufficient to retrieve the content, even if the
entity isn't in the room.
MXC URIs are vulnerable to directory traversal attacks such as
`mxc://` URIs are vulnerable to directory traversal attacks such as
`mxc://127.0.0.1/../../../some_service/etc/passwd`. This would cause the
target homeserver to try to access and return this file. As such,
homeservers MUST sanitise MXC URIs by allowing only alphanumeric
homeservers MUST sanitise `mxc://` URIs by allowing only alphanumeric
(`A-Za-z0-9`), `_` and `-` characters in the `server-name` and
`media-id` values. This set of whitelisted characters allows URL-safe
base64 encodings specified in RFC 4648. Applying this character

View file

@ -53,7 +53,7 @@ the tag.
| `font` | `data-mx-bg-color`, `data-mx-color`, `color` |
| `span` | `data-mx-bg-color`, `data-mx-color`, `data-mx-spoiler` (see [spoiler messages](#spoiler-messages)) |
| `a` | `name`, `target`, `href` (provided the value is not relative and has a scheme matching one of: `https`, `http`, `ftp`, `mailto`, `magnet`) |
| `img` | `width`, `height`, `alt`, `title`, `src` (provided it is a [Matrix Content (MXC) URI](#matrix-content-mxc-uris)) |
| `img` | `width`, `height`, `alt`, `title`, `src` (provided it is a [Matrix Content (`mxc://`) URI](#matrix-content-mxc-uris)) |
| `ol` | `start` |
| `code` | `class` (only classes which start with `language-` for syntax highlighting) |
@ -315,7 +315,7 @@ When sending a spoiler, clients SHOULD provide the fallback in the `body` as sho
(including the reason). The fallback SHOULD NOT include the text containing spoilers since
`body` might show up in text-only clients or in notifications. To prevent spoilers showing up in
such situations, clients are strongly encouraged to first upload the text containing spoilers
to the media repository, then reference the MXC URI in a markdown-style link, as shown above.
to the media repository, then reference the `mxc://` URI in a markdown-style link, as shown above.
Clients SHOULD render spoilers differently with some sort of disclosure. For example, the
client could blur the actual text and ask the user to click on it for it to be revealed.