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

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Jun 2011 14:04:23 +0200

On 2011-05-31 10:08, Mark Nottingham wrote:
> Agreed on both counts. Now #296:
>    http://trac.tools.ietf.org/wg/httpbis/trac/ticket/296

OK, proposed patch at 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/296/296.diff>.

The new text would be:

8.2.4.  203 Non-Authoritative Information

    The representation in the response has been transformed or otherwise
    modified by a transforming proxy (Section 2.3 of [Part1]).  Note that
    the behaviour of transforming intermediaries is controlled by the no-
    transform Cache-Control directive (Section 3.2 of [Part6]).

    This status code is only appropriate when the response status code
    would have been 200 (OK) otherwise.  When the status code before
    transformation would have been different, the 214 Transformation
    Applied warn-code (Section 3.6 of [Part6]) is appropriate.

    Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
    determine freshness for 203 responses.

...and the Changes section would state:

    Broadened the definition of 203 (Non-Authoritative Information) to
    include cases of payload transformations as well.  (Section 8.2.4)

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Jun 2011 22:14:23 +1000

+1 from me.

At some point it would be nice if the section on transforming intermediaries referred to it and the warn code as well.

Cheers,

On 07/06/2011, at 10:04 PM, Julian Reschke wrote:

> OK, proposed patch at <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/296/296.diff>.
> 
> The new text would be:
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Jun 2011 13:25:11 +0200

On 2011-06-07 14:14, Mark Nottingham wrote:
> ...

Like this...?

    An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
    designed or configured to modify request or response messages in a
    semantically meaningful way (i.e., modifications, beyond those
    required by normal HTTP processing, that change the message in a way
    that would be significant to the original sender or potentially
    significant to downstream recipients).  For example, a transforming
    proxy might be acting as a shared annotation server (modifying
    responses to include references to a local annotation database), a
    malware filter, a format transcoder, or an intranet-to-Internet
    privacy filter.  Such transformations are presumed to be desired by
    the client (or client organization) that selected the proxy and are
    beyond the scope of this specification.  However, when a proxy is not
    intended to transform a given message, we use the term "non-
    transforming proxy" to target requirements that preserve HTTP message
    semantics.  See Section 8.2.4 of [Part2] and Section 3.6 of [Part6]
    for status and warning codes related to transformations.

(last sentence added: see also 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/296/296.diff>).

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 Jun 2011 11:57:18 +0000

In message <[email-masked]>, Julian Reschke writes:

>    semantically meaningful way 

One of the important legal principles is that when you act "by
proxy", the proxy is not involved in substance, but merely act as
a trusted relayer of messages.

If the proxy is involved in substance, he is "agent of" or
has "power of attorney".

A good example is the proxy at an art auction, who relays the bids
a non-present bidder communicates via telephone or fax.

I am convinced that John.D.Nobody would be surprised if heard his
proxy bid being "modified in a semantically meaningful way", just
as the poor auction-clerk would be suprised to be forced to pay
for the picture, should John.D.Nobody fail to.

If John.D.Nobody instead sent his good friend to the auction with
a mandate to buy the picture, this friend is not a proxy:  He is
an agent, because he decides when to bid and how much to bid, and
he is personally responsible for paying for the bid he makes.

If your "proxy service" modifies the content, you are not delivering
a "proxy service", but a "translation service", "filtering service",
"ad injection service" or "censorship service", and it should be
treated just like any other service being delivered with the HTTP
protocol:  As a HTTP server.

The fact that some HTTP servers acesses data necessary for their
responses using the HTTP protocol, does not make them proxies.

A "transforming HTTP proxy" is a HTTP server, and we should
not even think about mentioning them.

203 should just be dropped.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Jun 2011 14:13:21 +0200

> 203 should just be dropped.

Well, we just came to the conclusion a few days ago that we can't drop it.

If you to argue against that, please have a look at Roy's mail from May 
30 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0280.html>).

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 Jun 2011 12:23:18 +0000

>Well, we just came to the conclusion a few days ago that we can't drop it.

Then keep it, and give it a sensible definition, without inventing
a new class of unnecessary HTTP mangling beasts.

Suggestion:

	203 Non-Authoritative Information

	For reasons not specified, the response is not authoritative,
	but expected to be sufficiently indicative of what the
	authoritative response would have been, that it merits
	attention.  Users should be alerted to this fact if the
	client decides to present the response.  One example use
	could be proxies returning expired copies when the origin
	server is unreachable.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 8 Jun 2011 13:35:26 -0700

> 	could be proxies returning expired copies when the origin

No, these beasts have been with us since 1994. They are part of the design
of HTTP.  They are chosen by the client that use them.  For all of those
reasons, your suggestions for 203 are simply unfounded.

Cache-control is not a substitute because it only applies to caches.
Warning might have been a substitute but recipients ignore it.
A status code other than 203 was originally chosen, IIRC, because
caches would treat them differently than 200 responses even if they
did not understand the semantics of 203.  I have no idea how extensive
that is in practice today, and I have no desire to change the semantics
of HTTP right now just to find out what breaks later.

....Roy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 Jun 2011 21:05:12 +0000

In message <[email-masked]>, "Roy T. Fielding" w

>of HTTP.  They are chosen by the client that use them. 

That does not mean that we have to rewrite the entire text to
accomodate them, when it would be much simpler and clear for everybody
to say that they should be treated as and behave as origin servers.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Jun 2011 08:10:59 +1000

> to say that they should be treated as and behave as origin servers.

We're rewriting the text to clarify them; they've always been there, just badly documented (mostly in the caching section, of all places) as "non-transparent proxies," a term which eventually got a different meaning in common usage.

Cheers,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 09 Jun 2011 07:19:15 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>We're rewriting the text to clarify them; they've always been there, 
>just badly documented (mostly in the caching section, of all places) as 
>"non-transparent proxies," a term which eventually got a different 
>meaning in common usage.

I don't quarrel with their existence, but I disagree that a service
which translates contents from english to french (a "semantically
meaningful transformation" if I ever saw one) is a "proxy" of any
kind.

In RFC-2616 non-transparent proxies are quite clearly devices which
aid transmission but do not disturb the content as presented:

      A "non-transparent proxy" is a proxy that modifies
      the request or response in order to provide some added service to
      the user agent, such as group annotation services, media type
      transformation, protocol reduction, or anonymity filtering.

Notice that it says: "service to the user agent", not "service to the user".

We are talking about converting PNG to GIF to cope with old browsers, 
not translation of languages, insertation of advertisements and similar.

The reason why I think the distinction is important, is that the
transformations covered by the RFC2616 text can be done without
a lawyer, no matter what origin server you are talking to:  There
is no change in artists control over their images, there is no
change in authors control of their texts.  The proxy simply does
not in any way change the users perception of the web-object she
is being presented.

But once you start translating works to different languages, remove
bits that are offensive to taste and so on, the term "proxy" simply
does not cover your activity, no matter how you qualify it, and
therefore I think allowing "semantically meaningful" translations
for proxys should not be allowed.

Such transformations can also result in non-trivial HTTP header
rewrites, for instance "Content-Language", a field which is not
approved for non-transparent proxy modification in RFC2616.

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 09 Jun 2011 19:51:31 +1200

I think that like it or not, the meaning of the term "proxy" in the 
context of HTTP has been somewhat relaxed from a legally-based definition.

Apart from translating content, agents called proxies tend to do all 
sorts of things without the express agency of their client.

Like challenging for authentication, or returning an access denied 
message, or a page stating the content contained a virus, as well as the 
features you mention.

It is of course completely unrealistic to expect either

a) vendors to desist from providing such features which are demanded by 
customers; or
b) vendors to abandon the term "proxy" in relation to their product.

Therefore a semantic argument about the use of the term is of little 
purpose.   Educating the entire world to a new term which may more 
appropriately describe the behaviour of the "proxy" is an expensive 
thing to do, and I'm not aware of a compelling need (user confusion).

History is full of cases where an original meaning for a term is changed 
(even radically) over time or by passage between languages.

So, my question is, what do you hope to achieve with this argument?

Regards

Adrien de Croy

On 9/06/2011 7:19 p.m., Poul-Henning Kamp wrote:
> In message<[email-masked]>, Mark Nottingham wri
> tes:
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 09 Jun 2011 08:05:27 +0000

>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.

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 09 Jun 2011 20:18:26 +1200

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<[email-masked]>, Adrien de Croy writes:
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 09 Jun 2011 08:26:24 +0000

In message <[email-masked]>, Adrien de Croy writes:

>complies with the RFC.

I have always understood the "transparent" to pertain to the contents
being undamaged and unchanged, and not to the details of how it was
transmitted (Via, Transfer-Encoding etc) ?

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 09 Jun 2011 07:50:50 -0700

On 06/09/2011 01:26 AM, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Adrien de Croy writes:
>
>    

Yet we also speak of proxies that transform the protocol and scheme and 
try not to change the semantic content. That may seem transparent to the 
semantic web.

Probably easier to think of that in how we move out of the complexities 
of multi-headed clients that each had a single connection to the server, 
and now they use one single proxy in-between to stream the server 
connection. The proxy directs resources to-and-from the appropriate 
client, and in this simplified case the proxy is almost the reverse of 
the web-server. On that point, use of semantic client/server terminology 
in description makes less sense.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 09 Jun 2011 16:50:17 +0000

>try not to change the semantic content. That may seem transparent to the 

That is what I consider a proper proxy:  A gadget which facilitates
communication without disturbing the message content.

It certainly seems to me that we should make sure we all agree what
the existing words mean, before we expect the rest of the world to
understand what we are talking about.

My cheat sheet:

	Does it receives HTTP requests and generate responses:
		Name: HTTP Server
		RFC treatment: as HTTP origin server

	Does it send HTTP request and expects responses:
		Name: HTTP Client
		RFC treatment: as HTTP Client

	Does it facilitate or optimize communication between
	server and client, without disturbing content availability,
	meaning or semantics:
		Name: HTTP Proxy
		RFC treatment: as HTTP Proxy
		Example acceptabletransformations:
			PNG->GIF conversion
			gzip compression,
			caching according to RFC rules
			HTTP/1.1 -> HTTP/0.9 conversion

	Anything else:
		Name: HTTP Gateway
		RFC treatment: as unrelated HTTP Client and HTTP origin
		server, connected by unspecified processing step.
		Example processing steps:
			Malware scanning
			Censorship
			Insertion of advertisements
			Translation from Chinese to French
			Rendering to safe bitmap form

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 09 Jun 2011 10:39:06 -0700

On 06/09/2011 09:50 AM, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Dzonatas Sol writes:
>    

Yes except we (at the proxy level) think in content by types rather then 
content of the entire message while gateways worry more about content by 
message length and less about types at depth.

> understand what we are talking about.

That is why we determine strict types, and how we continue on with 
business until another question of context (i.e. 203). To add to the 
"proper proxy" think of that as the user-agent. Now some want that 
user-agent local and some want that remote. In this sense, we can raise 
203 in intentionally stateful context that falls short of that for "no 
known cause".

--

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Jun 2011 10:07:18 +1000

> 		RFC treatment: as HTTP origin server

Proxies and and gateways (collectively, intermediaries) also do this.

> 		RFC treatment: as HTTP Client

Yes.

> 			Rendering to safe bitmap form

You're changing the meaning of the terms from common usage in the HTTP community and the specs.

A proxy is something that the services requests to a potentially unbounded, unconfigured set of origins; it has to be either configured in the client, or the client's access network has to interpose it (which is controversial, but that's a different topic). It operates on behalf of the user-agent (the terminal client), and/or the intervening network operators.

A gateway is effectively an origin server that hands requests to other back-end services; it needs no configuration in the client, because it looks like an origin server.  It operates on behalf of the origin server, and with its authority, so by definition it can't impose services that are unauthorised.

In RFC2616, the term you're looking for is "non-transparent proxy"; the current proposal to clarify that is "transforming proxy," since "transparent proxy" has another common use (more correctly, "intercepting proxy").

I understand that you have concerns about the use of the term 'proxy' because it has certain meaning in other contexts. However, in the context of the HTTP specification, it has always meant a very specific thing.

I also think we need to keep the definition as grounded in testable, on-the-wire behaviour as possible. Although the definition of transforming is currently spread across the spec, we currently have in p6:

   no-transform

      The no-transform response directive indicates that an intermediary
      (regardless of whether it implements a cache) MUST NOT change the
      Content-Encoding, Content-Range or Content-Type response header
      fields, nor the response representation.

I think that needs some tweaking ("response representation" is quite broad), but it is concrete.

Cheers,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 10 Jun 2011 06:52:51 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>In RFC2616, the term you're looking for is "non-transparent proxy"; the 
>current proposal to clarify that is "transforming proxy," since 
>"transparent proxy" has another common use (more correctly, 
>"intercepting proxy").

I don't see how the current text can support a "transforming proxy"
which translates content from english to french, where the
Accept-Language header must be modified.

Trying to make space for this in the spec, will basically amount
to adding "God knows what a transforming proxy might do to this
header."  all over the spec, to nobodys gain.

That is why I propose that we describe "transforming proxys",
(if that is what we want to call them) as a HTTP client and an
HTTP origin server connected by an unspecified processing step.

That way we decouple what headers go in one end from what goes
out the other end in one single place in the spec, rather than
having to repeat over and over the same disclaimer.

I am not trying to ban these kind of devices, I am trying to
describe the accurately and textually efficiently.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 10 Jun 2011 06:49:27 -0700

> Accept-Language header must be modified.

That is where mime-parts help avoid the need to retouch the first 
header-set of each query, otherwise there is net cost, especially to 
untangle services from proxies.

The only argument that exists about that is rather to add new parts (to 
the end) or wrap the entire query (i.e. "top posting"). Persistent 
connections offer one way to make that argument null and void.

--

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 10 Jun 2011 14:18:00 +0000

>connections offer one way to make that argument null and void.

I'm sorry, none of that makes any kind of sense to me.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 10 Jun 2011 08:20:01 -0700

Anotherwords, the queue is in an 1:1 ratio of atomic state to quantum 
state. That is the best the analog signal can transliterate from or to 
the digital signal. Any analysis of such is noise.

Whereas, people argue if the noise is "transparent" or not, or if 
adjectives "transform" the truth. Whereas, in that sense, we could 
rename HTTP-status code 203 to "Hyperbolic state", yet people would 
think they need to signal that in order to enable hypermedia. To solve 
that we could rename that again to "Unreal hyperbolic state", yet then 
that would lead to the rewrite of the book of judges even when 
HTTP-status code 200 is OK. Therefore, the title "203 Non-Authoritative 
Information" is optimal enough.

This is du Lys D`... French.

On 06/10/2011 07:18 AM, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Dzonatas Sol writes:
>    

--

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Jun 2011 17:40:17 +0200

> include cases of payload transformations as well. (Section 8.2.4)

OK, can we go back discussing this concrete change?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Jun 2011 10:37:07 +1000

I haven't heard any objection to the change in the status code itself, so I think we can go ahead and incorporate this; discussion about the term "transforming proxy" and the exact constraints on transformation can be separate issues.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Jun 2011 08:51:24 +0200

> I haven't heard any objection to the change in the status code itself, so I think we can go ahead and incorporate this; discussion about the term "transforming proxy" and the exact constraints on t…

Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1309>.

Best regards, Julian