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

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

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>
Message-ID: <95534.1307606727@critter.freebsd.dk>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC