Re: The use of trailers

mån 2007-05-28 klockan 14:30 +1200 skrev Adrien de Croy:

> It seems there are a few features in HTTP that primarily consider agents 
> and servers, but not proxies, or specifically administrative 
> requirements for proxies.

Well, there is considerably more focus on the endpoint, but I am not
sure I agree in this case.

> It makes it very difficult to make decisions based on header values, 
> when the header itself may arrive a long time after the main headers of 
> a response in some chunk down the line.

Sure, but in most cases you don't need to, and it's easy to indicate you
don't support trailers by simply not sending a TE: trailers header.

> And it added a lot of complexity to header processing.

Not really, just that you need to be able to add headers. Quite the same
requirement as the need to be able to rewrite headers on a 304..

> the options available to an administrator don't lend themselves to good 
> user experiences.

Not sure I get the point here. The alternatives is

a) Not emit the header at all if it's value can't be realistically
determined before the body has been sent.

b) Emit the header in a trailer for those who can handle it.

and I prefer having the 'b' option available than only having 'a'.

> For instance a proxy administrator wishing to strictly enforce actions 
> based on response header values has a big problem with trailers.  
> Stripping any TE header in requests, or blocking responses from servers 
> that indicate there will be trailers are about the only decent options.

Sure, and where is the problem? Such setups gets restricted to 'a' or
requires the server to handle the request in a more complex manner, just
as they would be if trailers did not exists.

> The overall structure of a message seems to have been muddied with the 
> addition of trailers - from a clear delineation between headers and 
> resource, separated by 2 CRLF, we now no longer enjoy this clarity.

Yes.

> Processing of "content" now has to be able to encounter and deal with 
> new "headers".  This affects all resource processing, e.g caching, 
> scanning etc.

Well, it's still clearly separated at the transport level (not message
level).

> It would be nice if the concept could be deprecated or re-thought before 
> someone goes ahead and implements it, but I'm dreaming there I guess.

Don't think that's a good alternative. trailers is a good thing when
they can be used.

But there should be a note that servers should if possible try to send
the headers in the message-header when possible, and only use the
trailer if it can't compute the header value before the response.

It's also worth noting that the server MUST know it's going to emit the
header. It's not allowed to add random headers to the trailer without
advertising them in the message-header. So for a server to emit Vary in
the trailer the following conditions must all be true

a) The request had a "TE: trailer"

b) The server realized the content varies, and emits a "Trailer: Vary"
in the message-header telling the recipient that the response varies but
that it's not yet known on which details..


Regards
Henrik