Re: i28 proposed replacement text

Adrien de Croy wrote:
> There are major side-effects, not the least interop with HTTP/1.0 agents 
> in the request chain, so I can see why people would take this route 
> (although they then can't use chunking). 

Connection: close is used instead with HTTP/1.0 agents, if it's worth
compressing.

> I guess another fundamental difference, is it's legal for a proxy to 
> convert a stream to Transfer-Encoded, but not to do so for 
> Content-Encoded, since it breaks the entity tag for caching.

Yes.  Though some do it anyway.  Maybe they change the entity tag to
something unlikely to match a server generated tag (like map server's
"0405232430" to "proxy-generated-gzip-0405232430").  Or maybe they are
just broken.

> >Imho, RFC 2616 section 4.4 rule 3 (Content-Length is not allowed with
> >transfer-coding) is illogical and inconsistent with Content-Length
> >being an entity header.  The rule is there only for compatibility, and
> >might be safe to relax in some cases where the receiver is known to
> >implement HTTP/1.1.
> >  
> Actually I agree.  I've posted before about using Content-Length + 
> chunking for instance to communicate at the start what the entity length 
> (after removing any transfer-encoding) should be.  This is in many cases 
> VERY important information, and precluding the possibility of 
> transmitting that information when it may actually be available simply 
> because of a T-E in use seems unnecessary and wasteful.
> 
> But that would break many HTTP/1.0 intermediaries, so I think we're 
> stuck with using another header, or an extension to a T-E header.

Why would it break HTTP/1.0 intermediaries?  Transfer-Encoding should
never be sent to HTTP/1.0 intermediaries.

It seems to me it's only to protect against buggy HTTP/1.1 receivers.
That sort of thing is normally left out of the RFC, and put into
documents like "Apache's list of necessary workarounds for deployed
buggy implementations".

-- Jamie

Received on Wednesday, 14 May 2008 00:02:40 UTC