- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 2 Dec 2011 08:27:31 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, ietf-http-wg@w3.org
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 anything. 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. Regards, Willy
Received on Friday, 2 December 2011 07:28:14 UTC