- From: Jim Gettys <jg@pa.dec.com>
- Date: Wed, 18 Feb 1998 07:39:42 -0800
- To: http-wg@cuckoo.hpl.hp.com
Here are some clarifications around proxies that Roy was kind enough to draft up, to clarify when requirements apply to transparent proxies vs. proxies performing other actions (e.g. annotation). - Jim View: Browse HTML Browse Raw Text From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu> Date: Tue, 17 Feb 1998 15:34:23 -0800 To: jg@w3.org Cc: masinter@parc.xerox.com, lawrence@agranat.com, dmk@research.bell-labs.com, joshco@microsoft.com Subject: transparent proxy changes As per our discussion this morning, I wrote up a definition for transparent and non-transparent proxies. I also went through the rev-01 spec and found all places where there is any difference between transparent and non-transparent behavior. Changes are below. ....Roy *** draft-ietf-http-v11-spec-rev-01.txt Thu Feb 12 15:17:03 1998 --- tproxy.txt Tue Feb 17 15:27:15 1998 *************** *** 609,614 **** --- 609,622 ---- are serviced internally or by passing them on, with possible translation, to other servers. A proxy must implement both the client and server requirements of this specification. + A "transparent proxy" is a proxy that does not modify the request or + response beyond what is required for proxy authentication and + identification. 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. Except where either + transparent or non-transparent behavior is explicitly stated, the + HTTP proxy requirements apply to both types of proxies. gateway A server which acts as an intermediary for some other server. Unlike *************** *** 1023,1029 **** Proxy and gateway applications must be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a ! proxy/gateway MUST never send a message with a version indicator which is greater than its actual version. If a higher version request is received, the proxy/gateway MUST either downgrade the request version, or respond with an error, or switch to tunnel behavior. --- 1031,1037 ---- Proxy and gateway applications must be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a ! proxy/gateway MUST NOT send a message with a version indicator which is greater than its actual version. If a higher version request is received, the proxy/gateway MUST either downgrade the request version, or respond with an error, or switch to tunnel behavior. *************** *** 1964,1970 **** interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code. ! In requests that they forward, proxies MUST NOT rewrite the "abs_path" part of a Request-URI in any way except as noted above to replace a null abs_path with "*", no matter what the proxy does in its internal implementation. --- 1972,1979 ---- interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code. ! In requests that they forward, transparent proxies MUST NOT rewrite the ! "abs_path" part of a Request-URI in any way except as noted above to replace a null abs_path with "*", no matter what the proxy does in its internal implementation. *************** *** 2245,2251 **** The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields ! SHOULD be ignored by the recipient and MUST be forwarded by proxies. 7.2 Entity Body --- 2254,2261 ---- The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields ! SHOULD be ignored by the recipient and MUST be forwarded by transparent ! proxies. 7.2 Entity Body *************** *** 5029,5039 **** 13.5.2 Non-modifiable Headers Some features of the HTTP/1.1 protocol, such as Digest Authentication, ! depend on the value of certain end-to-end headers. A cache or non- ! caching proxy SHOULD NOT modify an end-to-end header unless the definition of that header requires or specifically allows that. ! A cache or non-caching proxy MUST NOT modify any of the following fields in a request or response, nor may it add any of these fields if not already present: --- 5039,5049 ---- 13.5.2 Non-modifiable Headers Some features of the HTTP/1.1 protocol, such as Digest Authentication, ! depend on the value of certain end-to-end headers. A transparent proxy ! SHOULD NOT modify an end-to-end header unless the definition of that header requires or specifically allows that. ! A transparent proxy MUST NOT modify any of the following fields in a request or response, nor may it add any of these fields if not already present: *************** *** 5049,5055 **** INTERNET-DRAFT HTTP/1.1 Friday, November 21, 1997 ! A cache or non-caching proxy MUST NOT modify any of the following fields in a response: . Expires --- 5059,5065 ---- INTERNET-DRAFT HTTP/1.1 Friday, November 21, 1997 ! A transparent proxy MUST NOT modify any of the following fields in a response: . Expires *************** *** 5063,5069 **** Note: a typical reason for adding the Content-Length header is that the origin server sent the content chunked encoded. ! A cache or non-caching proxy MUST NOT modify or add any of the following fields in a response that contains the no-transform Cache-Control directive, or in any request: --- 5073,5079 ---- Note: a typical reason for adding the Content-Length header is that the origin server sent the content chunked encoded. ! A proxy MUST NOT modify or add any of the following fields in a response that contains the no-transform Cache-Control directive, or in any request: *************** *** 5071,5077 **** . . Content-Range . Content-Type ! A cache or non-caching proxy MAY modify or add these fields in a response that does not include no-transform, but if it does so, it MUST add a Warning 114 (Transformation applied) if one does not already appear in the response. --- 5081,5088 ---- . . Content-Range . Content-Type ! ! A non-transparent proxy MAY modify or add these fields in a response that does not include no-transform, but if it does so, it MUST add a Warning 114 (Transformation applied) if one does not already appear in the response. *************** *** 6201,6207 **** 14.9.5 No-Transform Directive Implementers of intermediate caches (proxies) have found it useful to ! convert the media type of certain entity bodies. A proxy might, for Fielding, et al [Page 107] --- 6212,6219 ---- 14.9.5 No-Transform Directive Implementers of intermediate caches (proxies) have found it useful to ! convert the media type of certain entity bodies. A non-transparent proxy ! might, for Fielding, et al [Page 107] *************** *** 6210,6220 **** example, convert between image formats in order to save cache space or ! to reduce the amount of traffic on a slow link. HTTP has to date been ! silent on these transformations. ! Serious operational problems have already occurred, however, when these ! transformations have been applied to entity bodies intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication, all depend on receiving an entity body that is bit for bit identical to the --- 6222,6231 ---- example, convert between image formats in order to save cache space or ! to reduce the amount of traffic on a slow link. ! Serious operational problems might occur, however, when these ! transformations are applied to entity bodies intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication, all depend on receiving an entity body that is bit for bit identical to the *************** *** 6354,6363 **** Content-Encoding: gzip The Content-Encoding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with this encoding and ! is only decoded before rendering or analogous usage. However, a proxy ! MAY modify the content-coding if the new coding is known to be ! acceptable to the recipient, unless the "no-transform" Cache-Control ! directive is present in the message. If the content-coding of an entity is not "identity", then the response MUST including a Content-Encoding entity-header (section 14.12) that --- 6365,6374 ---- Content-Encoding: gzip The Content-Encoding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with this encoding and ! is only decoded before rendering or analogous usage. However, a ! non-transparent proxy MAY modify the content-coding if the new coding is ! known to be acceptable to the recipient and the "no-transform" ! Cache-Control directive is not present in the message. If the content-coding of an entity is not "identity", then the response MUST including a Content-Encoding entity-header (section 14.12) that *************** *** 6838,6844 **** Internet host which issued the request. For example, when a request is passed through a proxy the original issuer's address SHOULD be used. ! Note: The client SHOULD not send the From header field without the user's approval, as it may conflict with the user's privacy Fielding, et al [Page 118] --- 6849,6855 ---- Internet host which issued the request. For example, when a request is passed through a proxy the original issuer's address SHOULD be used. ! Note: The client SHOULD NOT send the From header field without the user's approval, as it may conflict with the user's privacy Fielding, et al [Page 118]
Received on Wednesday, 18 February 1998 07:43:58 UTC