Difference between Content-Range and Range headers?

Question

What is the difference between HTTP headers Content-Range and Range? When should each be used?

I am trying to stream an audio file from a particular byte offset. Should I use Content-Range or Range header?

Limitless

Answer 1

Range is used in the request, to ask for a particular range (or ranges) of bytes. Content-Range is used in the response, to indicate which bytes the server is giving you (which may be different than the range you requested), as well as how long the entire content is (if known).

Ajmer

@BrunoMartinez While you can use Content-Range in the request, it was pretty clear from the question that the OP was asking about downloading content with a particular range. I was answering based on what the OP was asking, not trying to give a comprehensive description of every case in which Content-Range could be used. – Ajmer

@BrianCampbell you are of course correct. I just wanted to record my findings for posterity's sake. I edited my answer to make sure it does not give the impression that your answer is in any way wrong. – Leffen

@Leffen Not a problem! Thank you for giving a more complete explanation; it is always useful if you find the page from a Google search. – Ajmer

Answer 2

Actually, the accepted answer is not complete. Content-Range is not only used in responses. It is also legal in requests that provide an entity body.

For example, an HTTP PUT provides an entity body, it might provide only a portion of an entity. Thus the PUT request can include a Content-Range header indicating to the server where the partial entity body should be merged into the entity.

For example, let's first create and then append to a file using HTTP:

Request 1:

PUT /file HTTP/1.1
Host: server
Content-Length: 1

a

Request 2:

PUT /file HTTP/1.1
Host: server
Content-Range: bytes 1-2/*
Content-Length: 1

a

How, let's see the file's contents...

Request 3:

GET /file HTTP/1.1
Host: server

HTTP/1.1 200 OK
Content-Length: 2

aa

This allows random file access, both READING and WRITING over HTTP. I just wanted to clarify, as I was researching the use of Content-Range in a WebDAV client I am developing, so perhaps this expanded information will prove useful to somebody else.

Leffen

Content-Range isn't legal in requests. – Tanta

That comment is incorrect. RFC2616 (w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16) does not limit the Content-Range header to requests, but binds it to a "partial entity-body". It's actually very common to use the feature to facilitate upload resume or chunked upload. – Weiser

Mark's comment is correct. See: tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23, section 4.3.4. – Cuspidor

I think Content-Range can be used in requests. See the section on PUT method: w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 - The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases. - A request might contain the Content-Range header and the server SHOULD take it into account. – Siliqua

@Siliqua Sure, but that's not the same as saying it actually works as the answerer describes -- I mean, it's a guaranteed 501. – Daisie

@Cuspidor that sections says "An origin server SHOULD reject any PUT request that contains a Content-Range header field", not "MUST reject". Anyway lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/0033.html while old has good explanations why partial PUT is unwise. The right way to do it is PATCH but it describes what is to be patched in body, not in Content-Range headers. – Agglutinin

Seems, like it's not possible to use PUT with Content-Range header. Is there any way to use PATCH with Content-Range? – Who

Based on my brief reading, content-range should not be used with PUT because PUT implies an idempotent operation where the entire resource is replaced. It wouldn't make sense then for a resource to be partially uploaded - which is exactly why PATCH exists. This is the current state of things anyway, I didn't look into when PATCH was available nor edits since the answer was written. – Galeiform

@BeniCherniavsky-Paskin Looking at tools.ietf.org/html/rfc7231 rather than a draft version in section 4.3.4 I see "An origin server that allows PUT on a given target resource MUST send a 400 (Bad Request) response to a PUT request that contains a Content-Range header field (...)". Surely authors of RFCs are only humans and they do make mistakes and RFCs do evolve in pain, yet clearly the Content-Range header was not meant to be used in requests nor does it make much sense. – Suprarenal

Looking at tools.ietf.org/html/rfc7233#section-4.2 the byte range is inclusive, so request 2 should have the header Content-Range: 1-1/* for appending a single byte. – Phillipp

How does this answers OP question? He is asking for the difference between the two headers. Thanks for the info anyway. – Amelia

OneDrive uses Content-Range for requests. learn.microsoft.com/en-us/onedrive/developer/rest-api/api/… – Motet

@Motet Probably because the biggest disadvantage of allowing it -- proxies messing up your PUT requests back/forth due to ignoring Content-* they don't understand -- is negated by Microsoft employing exclusively their own infrastructure, which may or may not be using HTTP proxies altogether, for OneDrive, at least. Meaning they've got a single HTTP server entity that is responsible to duly respond to PUT requests with Content-Range headers, correctly. – Dineen

Microsoft's Graph API for Outlook also uses Content-Range with PUT for file uploads >= 3MB, see Attach large files to Outlook messages or events. – Unparliamentary