- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 10 Jun 2011 10:07:18 +1000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: httpbis Group <ietf-http-wg@w3.org>
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 UTC