Re: clarify some MUST requirements in HTTPbis part 1 section 3.3

Hi Adrien,

On Fri, Dec 02, 2011 at 02:40:28PM +1300, Adrien de Croy wrote:
> we're talking here about the specification for HTTP and Content-Length
> I don't see how we can write prose into HTTP that permits any agent to 
> send more than one Content-Length header under any circumstances and 
> still be compliant with the spec, no matter what you call the software 
> that does it or how it operates.

The ambiguity raised by Alex is that the spec talks about how headers
should be constructed and interpreted, while in his case he's also
forwarding some data which happen to be headers, without constructing
them. That's typically the case for transparent proxies ("does not modify
the request or response beyond what is required for proxy auth").

I don't see either how we could add text to cover those specific cases
for gateways or proxies which don't know all headers and their associated
rules. Once again, it's not about how to correctly write a header you're
building from scratch, but how to spot anomalies in headers you don't
necessarily care about and how to perform the cleanup without breaking

Perhaps we should try to spot a few essential guidelines for transparent
proxy authors. I think it is reasonable to emit a few MUST and a few
SHOULD which are compatible with the software/hardware capabilities
(for instance: SHOULD fix XXX and MUST reject a few dangerous patterns
if unable to fix). But we really cannot expect some proxies to know and
apply all the complex rules which clients must respect, that's irrealistic
when you consider they're forwarding headers they don't understand, and
sometimes just bytes. Or we can create a new category ("dumb gateways" or
"dumb proxies"). But in my understanding, that's already what transparent
proxies are supposed to be.


Received on Friday, 2 December 2011 07:28:14 UTC