Re: The use of trailers

I must have my wires crossed sorry.

Chunk extensions aren't problematic, as they aren't headers.

I must have just mis-read where trailers could occur.  It's clear from a 
closer look that they can only occur after the last-chunk.

I can still forsee some issues if headers like Content-Type are 
permitted in a trailer though.

Adrien


Henrik Nordstrom wrote:
> 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
>

Received on Tuesday, 29 May 2007 21:07:36 UTC