Re: The use of trailers

tis 2007-05-29 klockan 22:30 +1200 skrev Adrien de Croy:

> A proxy needs to understand the TE header to strip it.

Well, it's a MUST requirement in HTTP/1.1 to strip this. TE is a
hop-by-hop transport header. A HTTP/1.1 proxy not getting the
transport/message or hop-by-hop/end-to-end distinctions is not worthy to
advertise itself as a HTTP/1.1 proxy.

> Users don't even want to know about let alone think about trailers.  Any 
> incursion of trailers onto their reality is seen by most to be an 
> annoyance.  So, it's really hard to justify providing GUI in a product 
> to deal with how to cope with trailers.

Then don't support them. It's a thing the proxy must take an active
decision to support, not something which should get proxied by accident.

> I'd be interested if you can point me to any docs on real-life uses of 
> option b.  I still haven't seen a server return any trailers, few 
> clients advertise support for them.  Is there a restriction on what 
> headers may appear in trailers?  A site to test against would also be 
> useful.

Of course there is restrictions. Transport headers is not allowed in the
trailer. See 14.40 Trailer.

> the problem is that when trying to figure out what to do about trailers, 
> and policy enforcement, when putting together a request for upstream, 
> it's all to easy to decide to simply strip out any TE header from any 
> request received before passing it on.  This has the same effect as if 
> trailers didn't exist.  It's a simple way to deal with the problem.  But 
> what does it break?

It shouldn't break anything, but may result in either

a) Somewhat heavier processing demands on the server to produce the
header before the content.

or

b) Some headers not available

or

c) Some header values not as accurate as they might be if the server
could place them in the trailer.

> the arguably more correct way to deal with it is to allow the user to 
> configure what to do if and when headers arrive attached to chunks.  

chunks?

headers is only allowed in two places. The message-headers, and in the
final trailer header section in the "eof" chunk.


> 1. user education. If I don't even understand the true user benefits of 
> trailers, how can I educate my users.  Even if I did, it would be 
> non-trivial.  Providing an understandable user interface that doesn't 
> just put people off the product... etc etc.

Trailers is meant to be used for things which can not be evaluated
before the response. In RFC2616 this is mainly Vary for a dynamic
varying page, and Content-MD5, and maybe ETag if the server wishes to
provide a very strong ETag. Cache-Control and Last-Modified might also
be candidates.

Note: Placing ETag and Last-Modified in the trailer isn't very wise as
it makes it harder to cache partial responses.

> 2. performance.  Need to evaluate policy on headers possibly many more 
> times - whenever a trailer arrives. 

Yes, but you'll know beforehand if this may be required from the Trailer
message-header.

> 3. A subsequent trailer can potentially invalidate previous policy 
> considerations.  Policy logic may not lend itself to correct evaluation 
> when  matching is piecemeal.  This is the clincher for me.
> 
> So for the moment, I have chosen to deprecate trailers, which leaves me 
> uncomfortable that some day, someone will require them to work and I'll 
> be faced with this problem again.

For now the use of trailers is an optional extension.

> It seems to me that implementation of trailers in a server would 
> generally be thought by developers to be more trouble than they are 
> worth.  If they have to support the non-trailer case anyway.  Is support 
> for trailers optional?  I didn't think it was.

Support for trailers is optional, only used if supported by both client
and server, and the server is having an interest in making use of it...

> hmmm, maybe I need to re-read the section on trailers.  I remember the 
> bit about advertising which headers will be in trailers, but I don't 
> recall it covering things like how many times a trailer may appear, 
> whether there are any headers that cannot appear in a trailer (and must 
> be in the response) etc.  Obviously the Trailer header must not appear 
> in the trailer I guess.  But what about headers like Content-Type

There is only at most one trailer, in the final "eof" chunk.

       Chunked-Body   = *chunk
                        last-chunk
                        trailer
                        CRLF

       last-chunk     = 1*("0") [ chunk-extension ] CRLF

Are you maybe mixing up trailers and chunk-extensions?

> Still, I'm having fun trying to figure out how for instance a server can 
> provide an API to a CGI/ISAPI/NSAPI/etc so that the module can emit 
> trailers.  unless the module does the chunking itself as well.  Maybe 
> that's why I've never seen one.

The standard CGI doesn't support trailers.

Not sure about ISAPI.

Regards
Henrik