"Range" vs. "Content-Range"

[awendt]

"Range" is a request header for GET requests in section 14.35 of the HTTP/1.1 spec:

HTTP retrieval requests using conditional or unconditional GET methods
MAY request one or more sub-ranges of the entity

On the other hand, "Content-Range" in section 14.16 of the spec is a response header field:

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

Why do you use "Range" for the response and "Content-Range" for the request?

[felixge]

@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?

[felixge]

More thoughts on this here: https://news.ycombinator.com/reply?id=5564024&whence=item%3fid%3d5563569

[j4james]

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.

[felixge]

More prior art and discussion here: http://www.tus.io/protocols/resumable-upload.html#comment-866226341

[felixge]

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)

[kevinswiber]

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.

[felixge]

Latest status on this discussion is summarized here.

[Acconut]

The project settled with the custom Offset header since neither Range nor Content-Range fit our use case.