- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Thu, 09 Jun 2011 08:05:27 +0000
- To: Adrien de Croy <adrien@qbik.com>
- cc: Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, Julian Reschke <julian.reschke@gmx.de>, httpbis Group <ietf-http-wg@w3.org>
In message <4DF07B83.3080902@qbik.com>, Adrien de Croy writes: >So, my question is, what do you hope to achieve with this argument? That we will not have to explode the spec to twice the size with text that for every detail says "Of course, if this is a non-transparent proxy, anything could happen here really". We should write that any HTTP gadget which changes the semantics of the stuff going through it, should be viewed as HTTP client and a HTTP origin server connected by a unspecified processing step, rather than as a proxy, a term we (in this specification) reserve for semantically transparent HTTP gadgets. That way, we don't have to waste text trying to define what these gadgets might do to headers, or for that matter how they should interpret header fields differently from clients or origin servers. The people implementing these gadgets, get full freedom to perform any processing step they care for, header or body, without worrying about loosing the "RFC-compliant" sticker. And the people implementing transparent proxies get a non-confusing text to read to make sure they are doing it right. I don't particularly care what vendors and salesmen call them (they seem to favour "gateway" and "firewall" these days btw.) I care about the spec being readable and usable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Thursday, 9 June 2011 08:05:52 UTC