HTTP/1.1 specifies that a response sent as Transfer-Encoding: chunked
can include optional trailers (ie. what would normally be sent as headers, but for whatever reason can't be calculated before the content, so they can be appended to the end), for example:
Request:
GET /trailers.html HTTP/1.1 TE: chunked, trailers
Response:
HTTP/1.1 200 OK Transfer-Encoding: chunked Trailer: My-Test-Trailer D\r\n All your base\r\n B\r\n; are belong\r\n 6\r\n to us\r\n 0\r\n My-Test-Trailer: something\r\n \r\n
This request specifies in the TE
header that it's expecting a chunked
response, and will be looking for trailers
after the final chunk.
The response specifies in the Trailer
header the list of trailers it will be sending (in this case, just one: My-Test-Trailer
)
Each of the chunks are sent as:
D
= 13), followed by a CRLF
All your base
), followed by a CRLF
A zero size chunk (0\r\n
) indicates the end of the body.
Then the trailer(s) are specified (My-Test-Trailer: something\r\n
), followed by a final CRLF
.
Now, from everything I've read so far, trailers are rarely (if ever) used. Most discussions here and elsewhere concerning trailers typically start with "but why do you want to use trailers anyway?".
Putting aside the question of why, out of curiosity I've been trying to simulate a HTTP request/response exchange that uses trailers; but so far I have not yet been able to get it to work, and I'm not sure if it's something wrong with response I'm generating, or whether (as some have suggested) there are simply no clients that look for trailing headers.
Clients I've tried include: curl, wfetch, Chrome + jQuery.
In all cases, the client receives and correctly reconstructs the chunked response (All your base are belong to us
); and I can see in the response headers that Trailer: My-Test-Trailer
is being sent; but I'm not seeing My-Test-Trailier: something
returned either in the response headers, or anywhere. It's unclear whether a trailing header like this should appear in the client as a normal response header, after the entire response has been received and the connection closed?
Interestingly, the curl change logs appear to suggest that curl does support optional trailers, and that curl will process any trailers it finds into the normal header stream.
So does anybody know:
To enable chunked transfer encoding, set the value for AspEnableChunkedEncoding to True in the metabase for the site, the server, or the virtual directory that you want to enable chunked transfer encoding for. By default, the value is True, and it is set at the Web service level.
The Trailer response header allows the sender to include additional fields at the end of chunked messages in order to supply metadata that might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing status.
Use the WEB SEND command to send the first chunk of the message. Specify CHUNKING(CHUNKYES) to tell CICS that it is a chunk of a message. Use the FROM option to specify the first chunk of data from the body of the message. Use the FROMLENGTH option to specify the length of the chunk.
Chunked encoding allows the sender to send additional header fields after the message body. This is important in cases where values of a field cannot be known until the content has been produced, such as when the content of the message must be digitally signed.
Chunked encoding, which is provided under the HTTP 1.1 specification, involves dividing (cutting) data into smaller "blocks." Crucially, chunks are sent independently of one another, usually through a single persistent connection. The type is specified in the Transfer-Encoding header (in the first block).
For a chunked message, CICS supplies the proper headers for chunked transfer-coding, including the Transfer-Encoding: chunked header. If any additional headers are required at the beginning of the message, the application can write them before the first WEB SEND command. Any headers to be sent in the trailer at the end of the message.
So, to notify the browser about the chunked response, you need to omit the ' Content-Length ' header, and add the header ' Transfer-Encoding: chunked '. Giving this information to the browser, the browser will now expect to receive the chunks in a very specific format.
For a chunked message, CICS supplies the proper headers for chunked transfer-coding, including the Transfer-Encoding: chunked header. If any additional headers are required at the beginning of the message, the application can write them before the first WEB SEND command.
No common browsers support HTTP/1.1 trailers. Look at the column "Headers in trailer" in the "Network" tab of browserscope.
As you've discovered, a number of non-browser clients support it.
Over 5 years since asking this question, I can now definitively answer it myself.
Mozilla just announced that they will be supporting the new Server-Timing
field as a HTTP trailing header (their first ever support for trailers).
https://bugzilla.mozilla.org/show_bug.cgi?id=1413999
However, more importantly, they confirm that it will be whitelisted so that Server-Timing
is the only support value (emphasis mine):
Server-Timing is an HTTP trailer, not a header. :mcmanus tells me we currently parse trailers, but then silently throw them away. We don't want to change that behavior in general (we don't want to encourage trailers), so we'll want to whitelist the Server-Timing trailer, store it somewhere (probably even just a mServerTiming header will work for now, since it's the only trailer we support) and then make it available via some new channel.getTrailers() call.
So I guess that confirms it once and for all: trailing headers are not supported (and never likely to be in a general sense) by Moz, and presumably the same stance is taken by all other browser vendors.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With