Changeset 1107

Feb 8, 2011, 4:23:14 PM (8 years ago)

Change the undefined use of "transparent proxy" to a definition
of transforming and non-transforming proxies. Add new definitions
for "intercepts" and the other kind of "transparent proxy".
Should we add informational references to RFC1919 and RFC3040 ?

Addresses #210

4 edited


  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1106 r1107  
    688688   sake of security, annotation services, or shared caching.
     691<iref primary="true" item="transforming proxy"/>
     692<iref primary="true" item="non-transforming proxy"/>
     693   An HTTP-to-HTTP proxy is called a "transforming proxy" if it designed
     694   or configured to modify request or response messages in a semantically
     695   meaningful way (i.e., modifications, beyond those required by normal
     696   HTTP processing, that change the message in a way that would be
     697   significant to the original sender or potentially significant to
     698   downstream recipients).  For example, a transforming proxy might be
     699   acting as a shared annotation server (modifying responses to include
     700   references to a local annotation database), a malware filter, a
     701   format transcoder, or an intranet-to-Internet privacy filter.  Such
     702   transformations are presumed to be desired by the client (or client
     703   organization) that selected the proxy and are beyond the scope of
     704   this specification.  However, when a proxy is not intended to transform
     705   a given message, we use the term "non-transforming proxy" to target
     706   requirements that preserve HTTP message semantics.
    690708<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    691709   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
    714732   through a shared firewall proxy.
     734<t><iref primary="true" item="intercept"/><iref primary="true" item="transparent proxy"/>
     735   In addition, there may exist network intermediaries that are not
     736   considered part of the HTTP communication but nevertheless act as
     737   filters or redirecting agents (usually violating HTTP semantics,
     738   causing security problems, and otherwise making a mess of things).
     739   These network intermediaries are often referred to as "intercepts"
     740   or "transparent proxies", and are commonly found on public network
     741   access points as a means of enforcing account subscription prior to
     742   allowing use of non-local Internet services.
    11351163   HTTP allows the set of defined header fields to be extended without
    11361164   changing the protocol version (see <xref target="header.field.registration"/>).
    1137    However, such fields might not be recognized by a downstream recipient
    1138    and might be stripped by non-transparent intermediaries.
    1139    Unrecognized header fields &MUST; be forwarded by transparent proxies
    1140    and &SHOULD; be ignored by a recipient.
     1165   Unrecognized header fields &MUST; be forwarded by a proxy unless the
     1166   proxy is specifically configured to block or otherwise transform such
     1167   fields.  Unrecognized header fields &SHOULD; be ignored by other recipients.
    1593    A transparent proxy &MUST-NOT; rewrite the "path-absolute" part of the
     1620   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" part of the
    15941621   received request-target when forwarding it to the next inbound server,
    15951622   except as noted above to replace a null path-absolute with "/" or "*".
    24912518   Some features of HTTP/1.1, such as Digest Authentication, depend on the
    2492    value of certain end-to-end header fields. A transparent proxy &SHOULD-NOT;
     2519   value of certain end-to-end header fields. A non-transforming proxy &SHOULD-NOT;
    24932520   modify an end-to-end header field unless the definition of that header field requires
    24942521   or specifically allows that.
    2497    A transparent proxy &MUST-NOT; modify any of the following fields in a
     2524   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    24982525   request or response, and it &MUST-NOT; add any of these fields if not
    24992526   already present:
    2508    A transparent proxy &MUST-NOT; modify any of the following fields in a
     2535   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    25092536   response:
    25102537  <list style="symbols">
    2530    A non-transparent proxy &MAY; modify or add these fields to a message
     2557   A transforming proxy &MAY; modify or add these fields to a message
    25312558   that does not include no-transform, but if it does so, it &MUST; add a
    25322559   Warning 214 (Transformation applied) if one does not already appear
    2545    A transparent proxy &MUST; preserve the message payload (&payload;),
     2572   A non-transforming proxy &MUST; preserve the message payload (&payload;),
    25462573   though it &MAY; change the message-body through application or removal
    25472574   of a transfer-coding (<xref target="transfer.codings"/>).
  • draft-ietf-httpbis/latest/p3-payload.xml

    r1106 r1107  
    13291329   Typically, the representation body is stored with this
    13301330   encoding and is only decoded before rendering or analogous usage.
    1331    However, a non-transparent proxy &MAY; modify the content-coding if the
     1331   However, a transforming proxy &MAY; modify the content-coding if the
    13321332   new coding is known to be acceptable to the recipient, unless the
    13331333   "no-transform" cache-control directive is present in the message.
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1106 r1107  
    648    In order to be legal, a strong entity-tag &MUST; change whenever the
     648   In order to be legitimate, a strong entity-tag &MUST; change whenever the
    649649   associated representation changes in any way. A weak entity-tag &SHOULD;
    650650   change whenever the associated representation changes in a semantically
    707707      conservative assumptions about the validators they receive.
    708708  </t><t>
    709       HTTP/1.0 clients and caches will ignore entity-tags. Generally,
     709      HTTP/1.0 clients and caches might ignore entity-tags. Generally,
    710710      last-modified values received or used by these systems will
    711711      support transparent and efficient caching, and so HTTP/1.1 origin
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1106 r1107  
    394394   mechanisms &MAY; be used, such as encryption at the transport level or
    395395   via message encapsulation, and with additional header fields
    396    specifying authentication information. However, these additional
     396   specifying authentication information. However, such additional
    397397   mechanisms are not defined by this specification.
    400    Proxies &MUST; be completely transparent regarding user agent
    401    authentication by origin servers. That is, they &MUST; forward the
    402    WWW-Authenticate and Authorization headers untouched, and follow the
    403    rules found in <xref target="header.authorization"/>. Both the Proxy-Authenticate and
    404    the Proxy-Authorization header fields are hop-by-hop headers (see
    405    &end-to-end.and-hop-by-hop;).
     400   Proxies &MUST; forward the WWW-Authenticate and Authorization headers
     401   unmodified and follow the rules found in <xref target="header.authorization"/>.
Note: See TracChangeset for help on using the changeset viewer.