Is using the HTTP Content-Range header appropriate when sending a file in chunks using the POST method?

Question

I am working on an existing Silverlight file uploader that breaks files into multiple chunks and transmits the file using multiple HTTP requests.

Currently, it sends the start and total byte information on the querystring, but as learning exercise, I'd like to use a more standards-based approach.

I've previously used the HTTP Content-Range header when implementing an endpoint that serves content. Is this header also appropriate to use when posting content from a client to the server?

Rusel

Answer 1

Yes.

RFC 2616 (HTTP 1.1), Section 14 begins by stating:

For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.

Other than that, Section 14.16, which defines the Content-Range header, does not appear to contain any language limiting its use to either the request or response.

Rusel

And could one also use the range' header when uploading pieces of a file in chunks? I don't see anything in the rfc about this as well – Snowonthemountain

That's what the original question was about - my conclusion was that it is appropriate, but you'll have to make sure that it is supported by the server. If you're also writing the server code it's not an issue, but I think it's unlikely that many servers will support chunked uploads in this fashion. – Rusel

The question referred to 'content-range'. I'm referring to 'Range'. The server I'm making myself and I need some kind of chunked upload mechanism. So I was wondering if 'range' would do just was well as 'content-range'. In the spec 'range' seems to refer to requests, and 'content-range' seems to refer to responses. – Snowonthemountain

Sorry for the delay - "Range" does seem like it could be appropriate, though now I'm confused as to the distinction between "Range" and "Content-Range", as "Range" seems to apply to both requests and responses - only the following section "14.35.2 Range Retrieval Requests", seems to apply only to requests, and only GET requests at that. – Rusel

For comparison, here's the language for "Content-Range": 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 – Rusel

The "Range" language is even more generic: 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. (However, not all clients and servers need to support byte- range operations.) Byte range specifications in HTTP apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body). – Rusel

To me, it seems like Content-Range is more appropriate for referring to the content sent in the body of the entity. That entity could be a response to a GET request (which could be made using the Range header), or it could be a POST or PUT request with partial content. While the spec doesn't seem to be explicit about it, I think Range is generally used for making partial content GET requests, as described in 14.35.2 – Rusel

+danielschaffer thanks for your insights. I noticed with .Net WebAPI that the range header is actually parsed and available, while the content-range header is stripped out of the request. I still can't figure out why it does this. I'll create a separate SO question about this and link to it from here. – Snowonthemountain

for people interested. Here is the follow-up question posted: #13129981 – Snowonthemountain

Answer 2

Probably not, at least as of 2014 (the original answer is from 2011).

The updated HTTP 1.1 specification, rfc7231 (4.3.3), says the following about valid POST responses:

An origin server indicates response semantics by choosing an appropriate status code depending on the result of processing the POST request; almost all of the status codes defined by this specification might be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).

Given that this language was explicitly added to the updated spec, I doubt the authors intended that the Content-Range header be used with the POST method.

Toxicity