|
| 1 | +# MSC3860: Media Download Redirects |
| 2 | + |
| 3 | +Currently the media download endpoints must return either a 200 with content or error responses. This |
| 4 | +means the media server instance must stream the data from wherever it is stored, which is likely not |
| 5 | +local to itself. Allowing redirects on these endpoints would make it possible for the media repo to |
| 6 | +tell clients/servers to pull data direct from the source, e.g. a CDN. |
| 7 | + |
| 8 | +Additionally redirects could be used to avoid downloading media from untrusted homeservers. Currently |
| 9 | +users can make their homeserver download, cache and proxy any matrix mid that I want, including |
| 10 | +bad/illegal content. Allowing for a 307 redirect would permit cautious server operators to not |
| 11 | +store and provide any media that floats in the matrixverse, but just refer to the "original" media. |
| 12 | + |
| 13 | +## Proposal |
| 14 | + |
| 15 | +This MSC proposes that a 307 or 308 redirect code is allowed and followed according to the `Location` |
| 16 | +header. It is possible some clients would already follow these which needs to be confirmed. Specific |
| 17 | +endpoints in question ([current spec link for these](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3downloadservernamemediaid)): |
| 18 | + |
| 19 | ++ `/_matrix/media/v3/download/{serverName}/{mediaId}` |
| 20 | ++ `/_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}` |
| 21 | ++ `/_matrix/media/v3/thumbnail/{serverName}/{mediaId}` |
| 22 | + |
| 23 | +To prevent breaking clients that don't properly follow the redirect response this functionality will |
| 24 | +be enabled by a query string flag `allow_redirect=true`. So specifically in the above cases if a |
| 25 | +client respects redirect responses it can make requests like so to the media endpoints: |
| 26 | + |
| 27 | ++ `/_matrix/media/v3/download/{serverName}/{mediaId}?allow_redirect=true` |
| 28 | ++ `/_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}?allow_redirect=true` |
| 29 | ++ `/_matrix/media/v3/thumbnail/{serverName}/{mediaId}?allow_redirect=true` |
| 30 | + |
| 31 | +In the case where a client wishes not to redirect (either implicitly with no parameter or explicitly |
| 32 | +providing `allow_redirect=false`) the server must continue to serve media directly with no redirect. |
| 33 | + |
| 34 | +## Potential Issues |
| 35 | + |
| 36 | +None for clients, as opt-in functionality this change is 100% backwards compatible. |
| 37 | + |
| 38 | +With redirects it becomes easier to force another homeserver to be your CDN, which isn't great |
| 39 | +(clients could already do that, but not without recompiling). |
| 40 | + |
| 41 | +Redirects also potentially allow changing of media underneath the users as different redirects could |
| 42 | +be returned over time. It is worth noting that a badly behaving media server can already just return |
| 43 | +different content as well. |
| 44 | + |
| 45 | +## Alternatives |
| 46 | + |
| 47 | +None at this time. |
| 48 | + |
| 49 | +## Security Considerations |
| 50 | + |
| 51 | +A media repo could redirect requests to a bad actor, although this would make the primary media |
| 52 | +repo itself a bad actor, thus this does not present any increased security issues. |
| 53 | + |
| 54 | +## Unstable Prefix |
| 55 | + |
| 56 | +Until this functionality has landed in the spec, the `allow_redirect` query |
| 57 | +parameter should be prefixed with `com.beeper.msc3860.`: |
| 58 | + |
| 59 | +``` |
| 60 | +?com.beeper.msc3860.allow_redirect=true |
| 61 | +``` |
0 commit comments