Mar 12, 2011, 1:31:37 PM (9 years ago)

editorial: introduce more common proxy/gateway terms and
simplify wording of some versioning descriptions.

1 edited


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

    r1165 r1170  
    706706<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
     707<iref primary="true" item="accelerator"/>
    707708   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
    708709   as a layer above some other server(s) and translates the received
    709710   requests to the underlying server's protocol.  Gateways are often
    710    used for load balancing or partitioning HTTP services across
    711    multiple machines.
     711   used for load balancing, "accelerator" caching, or partitioning
     712   HTTP services across multiple machines.
    712713   Unlike a proxy, a gateway receives requests as if it were the
    713714   origin server for the target resource; the requesting client
    732733<t><iref primary="true" item="interception proxy"/><iref primary="true" item="transparent proxy"/>
     734<iref primary="true" item="captive portal"/>
    733735   In addition, there may exist network intermediaries that are not
    734736   considered part of the HTTP communication but nevertheless act as
    735737   filters or redirecting agents (usually violating HTTP semantics,
    736738   causing security problems, and otherwise making a mess of things).
    737    Such a network intermediary, referred to as an "interception proxy"
    738    <xref target="RFC3040"/> or "transparent proxy" <xref target="RFC1919"/>,
     739   Such a network intermediary, often referred to as an "interception proxy"
     740   <xref target="RFC3040"/>, "transparent proxy" <xref target="RFC1919"/>,
     741   or "captive portal",
    739742   differs from an HTTP proxy because it has not been selected by the client.
    740743   Instead, the network intermediary redirects outgoing TCP port 80 packets
    741744   (and occasionally other common port traffic) to an internal HTTP server.
    742    Interception proxies are commonly found on public network access points
     745   Interception proxies are commonly found on public network access points,
    743746   as a means of enforcing account subscription prior to allowing use of
    744    non-local Internet services.  They are indistinguishable from a
    745    man-in-the-middle attack.
     747   non-local Internet services, and within corporate firewalls to enforce
     748   network usage policies.
     749   They are indistinguishable from a man-in-the-middle attack.
    827831   When an HTTP/1.1 message is sent to an HTTP/1.0 recipient
    828    (or a recipient whose version is unknown), the HTTP/1.1 message is
    829    constructed such that it will be interpreted as a valid HTTP/1.0
    830    message even if all of the provided header fields not defined in
    831    the HTTP/1.0 specification <xref target="RFC1945"/> are ignored.
    832    This specification excludes incompatible message constructions by
    833    imposing recipient-version requirements on new HTTP/1.1 features
    834    that are not safely interpreted by earlier HTTP/1.0 recipients.
    835 </t>
    836 <t>
    837    The interpretation of an HTTP message header field does not change
     832   <xref target="RFC1945"/> or a recipient whose version is unknown,
     833   the HTTP/1.1 message is constructed such that it can be interpreted
     834   as a valid HTTP/1.0 message if all of the newer features are ignored.
     835   This specification places recipient-version requirements on some
     836   new features so that a compliant sender will only use compatible
     837   features until it has determined, through configuration or the
     838   receipt of a message, that the recipient supports HTTP/1.1.
     841   The interpretation of an HTTP header field does not change
    838842   between minor versions of the same major version, though the default
    839843   behavior of a recipient in the absence of such a field can change.
    840844   Unless specified otherwise, header fields defined in HTTP/1.1 are
    841    defined for all versions of HTTP/1.x.  The most popular example of
    842    this is the Host header field, which was introduced during the
    843    standardization process of HTTP/1.1 and widely deployed for HTTP/1.0
    844    requests out of necessity.
    845 </t>
    846 <t>
    847    Likewise, new header fields can be defined such that, when they are
     845   defined for all versions of HTTP/1.x.  In particular, the Host and
     846   Connection header fields ought to be implemented by all HTTP/1.x
     847   implementations whether or not they advertise compliance with HTTP/1.1.
     850   New header fields can be defined such that, when they are
    848851   understood by a recipient, they might override or enhance the
    849852   interpretation of previously defined header fields.  When an
    910913   changes made to the protocol have the effect of adding to the message
    911914   semantics or implying additional capabilities of the sender.  However,
    912    the minor version was not incremented for the changes introduced in
    913    <xref target="RFC2616"/>, and this revision is specifically avoiding
    914    any such changes to the protocol.
     915   the minor version was not incremented for the changes introduced between
     916   <xref target="RFC2068"/> and <xref target="RFC2616"/>, and this revision
     917   is specifically avoiding any such changes to the protocol.
Note: See TracChangeset for help on using the changeset viewer.