Payload Semantics

Last week during the HTTP Spec Reading Group, @georgebrock, @joelq, and I wrapped up a discussion about Content-Location and moved on to Section 3.2 (Representation Data) and Section 3.3 (Payload Semantics). I found the first paragraph of Section 3.3 pretty interesting.

Some HTTP messages transfer a complete or partial representation as
the message “payload”. In some cases, a payload might contain only
the associated representation’s header fields (e.g., responses to
HEAD) or only some part(s) of the representation data (e.g., the 206
(Partial Content) status code).

None of us have ever used a 206 status code in any of our projects. We wondered if it had to do anything with pagination or chunked requests, but didn’t find any examples of it. After our meeting ended, I stumbled across a use of 206 status from responses on Vimeo, after a video starts playing and gets loaded in chunks (example). You can also see Content-Range and Content-Length, headers mentioned later on in the section, being used in the same responses to send blocks of video data.

The Trailer header was mentioned in the bottom of Section 3.3, but we weren’t too sure how or when it’s used. Has anyone ever encountered it?

The example of Trailer I’ve seen in a couple of places (like this libcurl feature request and this Stack Overflow question) is the Content-MD5 header, which can’t be calculated until the whole of the content has been generated. In that case the response would look something like this:

Trailer: Content-MD5

(body)

Content-MD5: d2d677c0ccbe7e8c9d763fa3d3d07086

This doesn’t sound like it was used much in practice, though. RFC 7231 removed Content-MD5 from the spec because it wasn’t usually implemented properly with partial content:

The Content-MD5 header field has been removed because it was
inconsistently implemented with respect to partial responses.