W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

editorial issue TRANSPARENT-PROXY.

From: Jim Gettys <jg@pa.dec.com>
Date: Wed, 18 Feb 1998 07:39:42 -0800
Message-Id: <9802181539.AA27355@pachyderm.pa.dec.com>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:13 EDT