- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 09 Jun 2011 20:18:26 +1200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- 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>
OK, my response to that would be that since most actual proxy deployments would not meet the requirements of "transparency", why not jump the other way? I'm still not convinced it's even possible to create a 100% "transparent" (in the common english sense of the word) proxy that complies with the RFC. The Via header and mandated Connection header processing puts paid to that. Is transparent supposed to mean invisible in this context? It might be a lot less work to treat the "transparent" proxy as the exception, instead of the non-transparent proxy. Certainly for implementors, since by and large they will be implementing non-transparent proxies. Attempting to deprecate the term proxy in the non-transparent case I think will meet a lot of resistance. Adrien On 9/06/2011 8:05 p.m., Poul-Henning Kamp wrote: > 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. > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Thursday, 9 June 2011 08:19:01 UTC