-
Notifications
You must be signed in to change notification settings - Fork 103
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
clarify Content-Type / Content-Encoding / Content-Language handling #160
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -45,6 +45,7 @@ Kleidl](https://twitter.com/Acconut_)<br> | |
[J. Ryan Stinnett](https://convolv.es), | ||
[Ifedapo Olarewaju](https://github.com/ifedapoolarewaju) | ||
[Robert Nagy](https://github.com/ronag) | ||
[Nils Goroll](https://github.com/nigoroll) | ||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | ||
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | ||
|
@@ -299,7 +300,7 @@ Host: tus.example.org | |
Content-Length: 0 | ||
Upload-Length: 100 | ||
Tus-Resumable: 1.0.0 | ||
Upload-Metadata: filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==,is_confidential | ||
Upload-Metadata: filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==,filetype YXBwbGljYXRpb24vcGRm,is_confidential | ||
``` | ||
|
||
**Response:** | ||
|
@@ -334,6 +335,34 @@ Since metadata can contain arbitrary binary values, Servers SHOULD | |
carefully validate metadata values or sanitize them before using them | ||
as header values to avoid header smuggling. | ||
|
||
Clients and servers SHOULD implement the metadata key ``filetype`` | ||
with the value containing the actual ``Content-Type`` of the Upload | ||
(because the ``Content-Type`` header is formally required to be set to | ||
``application/offset+octet-stream`` for [Creation with | ||
Upload](#creation-with-upload)). | ||
|
||
Clients and servers MAY support additional well known metadata keys: | ||
|
||
* ``filename`` for a common file name | ||
|
||
The specific metadata keys documented herein are reserved for the | ||
respective use and MUST NOT be used for other purposes. | ||
|
||
##### [Content-Encoding](https://httpwg.org/specs/rfc7231.html#header.content-encoding) | ||
|
||
Clients MUST set the ``Content-Encoding`` header correctly IFF a | ||
content encoding is used. | ||
|
||
As per RFC7231, Servers MUST respond with status 415 if they can not | ||
accept the ``Content-Encoding`` chosen by the client. | ||
|
||
Servers MUST either store the ``Content-Encoding`` and deliver it with | ||
subsequent requests, or properly decode the content before storing it. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Does this mean that the Content-Encoding header must be present in the response for every PATCH, DELETE and HEAD request? |
||
|
||
##### [Content-Language](https://httpwg.org/specs/rfc7231.html#header.content-language) | ||
|
||
Clients and Servers SHOULD support the ``Content-Language`` header. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you elaborate more what "supporting the Content-Language header" means? To be concrete: Can you say what behavior a typical tus server (e.g. tusd) must have to support this header? |
||
|
||
#### Requests | ||
|
||
##### POST | ||
|
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 agree with @smatsson that this sentence is too restrictive. It would be a breaking change and there are no plans to make a major release for tus. I don't think this would serve the ecosystem well.
That being said, I am happy to recommend (not force) the usage of the filename and filetype metadata keys for the purposes as laid out here.