Do any browsers support trailers sent in chunked encoding responses?

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:

• size of chunk in hex (D = 13), followed by a CRLF
• chunk data (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:

• of a valid URL that I could ping, which sends trailers in a chunked response? (so that I can confirm whether it's just my test response that's not working); and
• which clients are known to support (and access/display) trailers sent by the server?

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.