Comments (8)
@awendt thank you so much for this feedback, these are good points indeed!
Regarding the Range
header, section 14.35 starts out by saying:
Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity.
This makes me think that the Range
header is also allowed for responses. At least I could not find anything in the spec that says it's forbidden. Using Range
for the responses is mainly desirable as it allows for multiple ranges to be returned, giving clients the ability to upload parts of a file in parallel as well as out of order (not part of the protocol yet, but will be added soon). Additionally the YouTube API serves as prior art for using the Range
header this way and gives me reason to believe this will work well with existing http clients and libraries.
Why do you use "Range" for the response and "Content-Range" for the request?
It's a simular situation as for the Range
header, the http spec has no example of using it for a request, but it seems to be the right choice given the Content-Range
header definition:
The Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. Range units are defined in section 3.12.
I actually think that the http specification generally does not distinguish between request/response headers, and many headers make sense for both (e.g. Content-Length
).
What do you think?
from tus-resumable-upload-protocol.
More thoughts on this here: https://news.ycombinator.com/reply?id=5564024&whence=item%3fid%3d5563569
from tus-resumable-upload-protocol.
Regarding the Range header, section 14.35 starts out by saying:
Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity.
I believe this statement is referring to the different types of entities (say a text entity vs a binary image entity), all of which can be meaningfully sampled with a range of bytes. It's not saying the range header can apply to both message types (request messages and response messages). An entity is the payload of a message - they're not the same thing.
If you look at the ABNF grammar for a response, you'll see that request-headers are clearly not permitted there. If Range was meant to be applicable to both request and response messages, it would have been included in the entity-header set.
I actually think that the http specification generally does not distinguish between request/response headers, and many headers make sense for both (e.g. Content-Length).
The headers that apply to both are either general-headers or entity-headers.
from tus-resumable-upload-protocol.
More prior art and discussion here: http://www.tus.io/protocols/resumable-upload.html#comment-866226341
from tus-resumable-upload-protocol.
I think we have to figure out PUT vs PATCH first, as that may have an impact on the headers to use. Also see: #14 (comment)
from tus-resumable-upload-protocol.
I think the HTTPbis edits have clarified this a bit.
Range: http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-22#section-3.1
Content-Range: http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-22#section-4.2
Per this document, Range should be used for GET requests and Content-Range should be used for partial responses.
It also states that a server MUST ignore the Range header for requests other than GET. (Going against this will BREAK THE WHOLE INTERNET or something.)
This means it would be up to this group to define a custom header for writing partial byte ranges to the server OR language that repurposes Content-Range as a request header. The latter might be a-okay.
from tus-resumable-upload-protocol.
Latest status on this discussion is summarized here.
from tus-resumable-upload-protocol.
The project settled with the custom Offset
header since neither Range
nor Content-Range
fit our use case.
from tus-resumable-upload-protocol.
Related Issues (20)
- Future definition of the Tus-Resumable header HOT 10
- Spam: Nutt
- Spam: Nutt
- Request: Swagger / OpenAPI documentation of the API HOT 8
- Byte-range support for iOS compatibility HOT 2
- > net::ERR_UPLOAD_FILE_CHANGED HOT 2
- Body is not specified in OpenAPI HOT 1
- MIME-type Extension HOT 4
- Unable to resume uploads, Upload-Offset is always 0 HOT 1
- support http/3 HOT 1
- OWASP Considerations HOT 4
- > net::ERR_UPLOAD_FILE_CHANGED HOT 1
- Protocol version confusion HOT 2
- Upload Post-Processing HOT 12
- Ambiguous Tus-Concatenation specifications HOT 4
- Which StatusCode of response must server return, if server want to indicate a success HEAD request HOT 5
- How Can I learn about Tus V2? HOT 3
- Add extension to allow for discovery of existing upload URL HOT 4
- Upload-Metadata could be Structured Field Values (RFC 8941) HOT 3
- Support zero length uploads HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tus-resumable-upload-protocol.