W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [XHR2] HTTP Trailers

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 26 Oct 2010 12:12:59 +0200
To: public-webapps@w3.org, "Mark Nottingham" <mnot@mnot.net>
Message-ID: <op.vk6hbwxl64w2qv@anne-van-kesterens-macbook-pro.local>
On Thu, 21 Oct 2010 03:12:36 +0200, Mark Nottingham <mnot@mnot.net> wrote:
> 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.

What the browser exposes to developer tools is not really up to this API.  
They could expose all kinds of nifty features there far beyond the  
XMLHttpRequest API. So this is not really an argument either way. However,  
if tools such as Firebug did expose it we might learn more about whether  
it is useful to expose it to web pages in general.

> 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().

If they were exposed via getResponseHeader() you would have the potential  
for clashes so that does not seem like a good idea.

Anne van Kesteren
Received on Tuesday, 26 October 2010 10:13:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC