Changeset 1107 for draft-ietf-httpbis

Timestamp:

09/02/11 00:23:14 (10 years ago)

Author:

fielding@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.xml (modified) (8 diffs)
• p3-payload.xml (modified) (1 diff)
• p4-conditional.xml (modified) (2 diffs)
• p7-auth.xml (modified) (1 diff)

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

@@ -688 +688 @@
    sake of security, annotation services, or shared caching.
 </t>
+<t>
+<iref primary="true" item="transforming proxy"/>
+<iref primary="true" item="non-transforming proxy"/>
+   An HTTP-to-HTTP proxy is called a "transforming proxy" if it designed
+   or configured to modify request or response messages in a semantically
+   meaningful way (i.e., modifications, beyond those required by normal
+   HTTP processing, that change the message in a way that would be
+   significant to the original sender or potentially significant to
+   downstream recipients).  For example, a transforming proxy might be
+   acting as a shared annotation server (modifying responses to include
+   references to a local annotation database), a malware filter, a
+   format transcoder, or an intranet-to-Internet privacy filter.  Such
+   transformations are presumed to be desired by the client (or client
+   organization) that selected the proxy and are beyond the scope of
+   this specification.  However, when a proxy is not intended to transform
+   a given message, we use the term "non-transforming proxy" to target
+   requirements that preserve HTTP message semantics.
+</t>
 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
@@ -714 +732 @@
    through a shared firewall proxy.
 </t>
+<t><iref primary="true" item="intercept"/><iref primary="true" item="transparent proxy"/>
+   In addition, there may exist network intermediaries that are not
+   considered part of the HTTP communication but nevertheless act as
+   filters or redirecting agents (usually violating HTTP semantics,
+   causing security problems, and otherwise making a mess of things).
+   These network intermediaries are often referred to as "intercepts"
+   or "transparent proxies", and are commonly found on public network
+   access points as a means of enforcing account subscription prior to
+   allowing use of non-local Internet services.
+</t>
 </section>
 
@@ -1135 +1163 @@
    HTTP allows the set of defined header fields to be extended without
    changing the protocol version (see <xref target="header.field.registration"/>).
-   However, such fields might not be recognized by a downstream recipient
-   and might be stripped by non-transparent intermediaries.
-   Unrecognized header fields &MUST; be forwarded by transparent proxies
-   and &SHOULD; be ignored by a recipient.
+   Unrecognized header fields &MUST; be forwarded by a proxy unless the
+   proxy is specifically configured to block or otherwise transform such
+   fields.  Unrecognized header fields &SHOULD; be ignored by other recipients.
 </t>
 </section>
@@ -1591 +1618 @@
 </t>
 <t>
-   A transparent proxy &MUST-NOT; rewrite the "path-absolute" part of the
+   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" part of the
    received request-target when forwarding it to the next inbound server,
    except as noted above to replace a null path-absolute with "/" or "*".
@@ -2490 +2517 @@
 <t>
    Some features of HTTP/1.1, such as Digest Authentication, depend on the
-   value of certain end-to-end header fields. A transparent proxy &SHOULD-NOT;
+   value of certain end-to-end header fields. A non-transforming proxy &SHOULD-NOT;
    modify an end-to-end header field unless the definition of that header field requires
    or specifically allows that.
 </t>
 <t>
-   A transparent proxy &MUST-NOT; modify any of the following fields in a
+   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    request or response, and it &MUST-NOT; add any of these fields if not
    already present:
@@ -2506 +2533 @@
 </t>
 <t>
-   A transparent proxy &MUST-NOT; modify any of the following fields in a
+   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    response:
   <list style="symbols">
@@ -2528 +2555 @@
 </t>
 <t>
-   A non-transparent proxy &MAY; modify or add these fields to a message
+   A transforming proxy &MAY; modify or add these fields to a message
    that does not include no-transform, but if it does so, it &MUST; add a
    Warning 214 (Transformation applied) if one does not already appear
@@ -2543 +2570 @@
 </x:note>
 <t>
-   A transparent proxy &MUST; preserve the message payload (&payload;),
+   A non-transforming proxy &MUST; preserve the message payload (&payload;),
    though it &MAY; change the message-body through application or removal
    of a transfer-coding (<xref target="transfer.codings"/>).

draft-ietf-httpbis/latest/p3-payload.xml

@@ -1329 +1329 @@
    Typically, the representation 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
+   However, a transforming 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.

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -646 +646 @@
 </t>
 <t>
-   In order to be legal, a strong entity-tag &MUST; change whenever the
+   In order to be legitimate, a strong entity-tag &MUST; change whenever the
    associated representation changes in any way. A weak entity-tag &SHOULD;
    change whenever the associated representation changes in a semantically
@@ -707 +707 @@
       conservative assumptions about the validators they receive.
   </t><t>
-      HTTP/1.0 clients and caches will ignore entity-tags. Generally,
+      HTTP/1.0 clients and caches might ignore entity-tags. Generally,
       last-modified values received or used by these systems will
       support transparent and efficient caching, and so HTTP/1.1 origin

draft-ietf-httpbis/latest/p7-auth.xml

@@ -394 +394 @@
    mechanisms &MAY; be used, such as encryption at the transport level or
    via message encapsulation, and with additional header fields
-   specifying authentication information. However, these additional
+   specifying authentication information. However, such additional
    mechanisms are not defined by this specification.
 </t>
 <t>
-   Proxies &MUST; be completely transparent regarding user agent
-   authentication by origin servers. That is, they &MUST; forward the
-   WWW-Authenticate and Authorization headers untouched, and follow the
-   rules found in <xref target="header.authorization"/>. Both the Proxy-Authenticate and
-   the Proxy-Authorization header fields are hop-by-hop headers (see
-   &end-to-end.and-hop-by-hop;).
+   Proxies &MUST; forward the WWW-Authenticate and Authorization headers
+   unmodified and follow the rules found in <xref target="header.authorization"/>.
 </t>