I'm sure I've got more feedback for the XHR2 draft, but one big thing is 
support for HTTP trailers.

HTTP trailers are essentially headers that occur after the body; they are only 
present when chunking is in use.

Historically, HTTP trailers haven't been used much, but I'm seeing an 
increasing number of use cases for them recently, along with corresponding 
interest in them from various communities:

1. It's often necessary to collect debug and trace information about how a 
request was processed (possibly including information from other, upstream 
sources), but putting this information in the response body makes it awkward to 
get to (as it's dependent upon the format of the response), and putting it in 
headers means buffering the entire response. Trailers allow debug and trace 
information to be appended to responses in an easily accessible form with low 
overhead.

For example, a response trailer could contain information about how much CPU it 
took to service a request, and/or information about database latency, etc. If 
XHR2 supported trailers, it would be possible to incorporate this information 
into tools like Firebug, so that they could not only show client-visible 
performance metrics, but also an end-to-end view.

2. Trailers can also be useful for denoting problems that occur after the 
response status code is sent, so that the client knows a response is incomplete 
or otherwise incorrect. E.g., if XHR2 supported trailers, client code could 
check for any error messages in trailers and take that into account when 
processing a response.

Trailers are supported by most deployed intermediaries, in the sense that 
they're passed through. Servers have varying levels of support; there's 
recently been discussion on the Apache mailing list about adding support, and 
node.js's HEAD has support for them as well.

In XHR2, supporting trailers probably means just making it possible to read 
trailers on the response when they're present, rather than discarding them. 
This could either be done by making them available from getResponseHeader() 
after the message is complete, or using a separate property or method if it's 
felt that keeping them distinct from the "normal" headers is desirable. E.g., 
getResponseTrailer().

Cheers,

--
Mark Nottingham   http://www.mnot.net/




Reply via email to