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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 10 Jun 2011 10:07:18 +1000
Cc: httpbis Group <ietf-http-wg@w3.org>
Message-Id: <F7ED4597-7733-4A35-A3ED-0B1BD369D44B@mnot.net>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

On 10/06/2011, at 2:50 AM, Poul-Henning Kamp wrote:
> 
> My cheat sheet:
> 
> 	Does it receives HTTP requests and generate responses:
> 		Name: HTTP Server
> 		RFC treatment: as HTTP origin server

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


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

Yes.


> 	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


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,

--
Mark Nottingham   http://www.mnot.net/
Received on Friday, 10 June 2011 00:07:45 GMT

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