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

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


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


      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.


Mark Nottingham

Received on Friday, 10 June 2011 00:07:45 UTC