W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: #296: 203 Non-Authoritative Information: deprecate?

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 09 Jun 2011 20:18:26 +1200
Message-ID: <4DF081D2.10600@qbik.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:41 GMT