Changeset 1170 for draft-ietf-httpbis


Ignore:
Timestamp:
12/03/11 21:31:37 (11 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r1165 r1170  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 12, 2011";
     361       content: "Expires September 13, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    412       <meta name="dct.issued" scheme="ISO8601" content="2011-03-11">
     412      <meta name="dct.issued" scheme="ISO8601" content="2011-03-12">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    442442            </tr>
    443443            <tr>
    444                <td class="left">Expires: September 12, 2011</td>
     444               <td class="left">Expires: September 13, 2011</td>
    445445               <td class="right">HP</td>
    446446            </tr>
    … …  
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">March 11, 2011</td>
     497               <td class="right">March 12, 2011</td>
    498498            </tr>
    499499         </tbody>
    … …  
    523523         in progress”.
    524524      </p>
    525       <p>This Internet-Draft will expire on September 12, 2011.</p>
     525      <p>This Internet-Draft will expire on September 13, 2011.</p>
    526526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    527527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    968968         that preserve HTTP message semantics.
    969969      </p>
    970       <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
    971          the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP
    972          services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the target
    973          resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the
    974          client as if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.
    975          A gateway communicates with inbound servers using any protocol it desires, including private extensions to HTTP that are outside
    976          the scope of this specification.
     970      <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span>  <span id="rfc.iref.a.1"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
     971         the received requests to the underlying server's protocol. Gateways are often used for load balancing, "accelerator" caching,
     972         or partitioning HTTP services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin
     973         server for the target resource; the requesting client will not be aware that it is communicating with a gateway. A gateway
     974         communicates with the client as if the gateway is the origin server and thus is subject to all of the requirements on origin
     975         servers for that connection. A gateway communicates with inbound servers using any protocol it desires, including private
     976         extensions to HTTP that are outside the scope of this specification.
    977977      </p>
    978978      <p id="rfc.section.2.3.p.8"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
    … …  
    981981         such as when transport-layer security is used to establish private communication through a shared firewall proxy.
    982982      </p>
    983       <p id="rfc.section.2.3.p.9"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
     983      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
    984984         act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a
    985          mess of things). Such a network intermediary, referred to as an "interception proxy" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> or "transparent proxy" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects outgoing
    986          TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception proxies are commonly
    987          found on public network access points as a means of enforcing account subscription prior to allowing use of non-local Internet
    988          services. They are indistinguishable from a man-in-the-middle attack.
    989       </p>
    990       <div id="rfc.iref.c.3"></div>
     985         mess of things). Such a network intermediary, often referred to as an "interception proxy" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "transparent proxy" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "captive portal", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary
     986         redirects outgoing TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception
     987         proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing
     988         use of non-local Internet services, and within corporate firewalls to enforce network usage policies. They are indistinguishable
     989         from a man-in-the-middle attack.
     990      </p>
     991      <div id="rfc.iref.c.4"></div>
    991992      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    992993      <p id="rfc.section.2.4.p.1">A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and
    … …  
    10011002       UA =========== A =========== B - - - - - - C - - - - - - O
    10021003                  &lt;             &lt;
    1003 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
     1004</pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    10041005         Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when
    10051006         that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are
    … …  
    10291030         than HTTP/12.3. Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent.
    10301031      </p>
    1031       <p id="rfc.section.2.5.p.6">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient (or a recipient whose version is unknown), the HTTP/1.1 message
    1032          is constructed such that it will be interpreted as a valid HTTP/1.0 message even if all of the provided header fields not
    1033          defined in the HTTP/1.0 specification <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> are ignored. This specification excludes incompatible message constructions by imposing recipient-version requirements on
    1034          new HTTP/1.1 features that are not safely interpreted by earlier HTTP/1.0 recipients.
    1035       </p>
    1036       <p id="rfc.section.2.5.p.7">The interpretation of an HTTP message header field does not change between minor versions of the same major version, though
    1037          the default behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined
    1038          in HTTP/1.1 are defined for all versions of HTTP/1.x. The most popular example of this is the Host header field, which was
    1039          introduced during the standardization process of HTTP/1.1 and widely deployed for HTTP/1.0 requests out of necessity.
    1040       </p>
    1041       <p id="rfc.section.2.5.p.8">Likewise, new header fields can be defined such that, when they are understood by a recipient, they might override or enhance
    1042          the interpretation of previously defined header fields. When an implementation receives an unrecognized header field, the
    1043          recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
     1032      <p id="rfc.section.2.5.p.6">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
     1033         message if all of the newer features are ignored. This specification places recipient-version requirements on some new features
     1034         so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt
     1035         of a message, that the recipient supports HTTP/1.1.
     1036      </p>
     1037      <p id="rfc.section.2.5.p.7">The interpretation of an HTTP header field does not change between minor versions of the same major version, though the default
     1038         behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
     1039         are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by
     1040         all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1.
     1041      </p>
     1042      <p id="rfc.section.2.5.p.8">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
     1043         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
    10441044         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    10451045      </p>
    … …  
    10691069         is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding
    10701070         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
    1071          for the changes introduced in <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol.
     1071         for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol.
    10721072      </p>
    10731073      <div id="rfc.iref.r.4"></div>
    … …  
    14161416                 / <a href="#uri" class="smpl">authority</a>
    14171417</pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request.</p>
    1418       <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.1"></span> The asterisk "*" ("asterisk form") means that the request does not apply to a particular resource, but to the server itself.
     1418      <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.2"></span> The asterisk "*" ("asterisk form") means that the request does not apply to a particular resource, but to the server itself.
    14191419         This is only allowed for the OPTIONS request method. Thus, the only valid example is
    14201420      </p>
    14211421      <div id="rfc.figure.u.31"></div><pre class="text2">OPTIONS * HTTP/1.1
    1422 </pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.2"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
     1422</pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
    14231423         and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
    14241424         loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example
    … …  
    14281428</pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    14291429      </p>
    1430       <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1430      <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    14311431      </p>
    14321432      <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.p.2"></span> The most common form of request-target is that used to identify a resource on an origin server or gateway ("path-absolute
    … …  
    16691669      <p id="rfc.section.6.2.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
    16701670      </p>
    1671       <div id="rfc.iref.c.5"></div>
    16721671      <div id="rfc.iref.c.6"></div>
     1672      <div id="rfc.iref.c.7"></div>
    16731673      <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
    16741674      <p id="rfc.section.6.2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
    … …  
    17521752         </p>
    17531753      </div>
    1754       <div id="rfc.iref.c.7"></div>
    17551754      <div id="rfc.iref.c.8"></div>
     1755      <div id="rfc.iref.c.9"></div>
    17561756      <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h4>
    17571757      <p id="rfc.section.6.2.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
    … …  
    17591759      </p>
    17601760      <div id="rfc.iref.d.2"></div>
    1761       <div id="rfc.iref.c.9"></div>
     1761      <div id="rfc.iref.c.10"></div>
    17621762      <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>
    17631763      <p id="rfc.section.6.2.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).
    … …  
    17681768      </div>
    17691769      <div id="rfc.iref.g.87"></div>
    1770       <div id="rfc.iref.c.10"></div>
     1770      <div id="rfc.iref.c.11"></div>
    17711771      <h4 id="rfc.section.6.2.2.3"><a href="#rfc.section.6.2.2.3">6.2.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>
    17721772      <p id="rfc.section.6.2.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
    … …  
    18731873         to. Each persistent connection applies to only one transport link.
    18741874      </p>
    1875       <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
     1875      <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
    18761876      </p>
    18771877      <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4>
    … …  
    19991999         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect header field with the "100-continue" expectation,
    20002000            and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this
    2001             rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field
     2001            rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field
    20022002            with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated
    20032003            with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other
    … …  
    20742074      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    20752075      <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p>
    2076       <div id="rfc.iref.c.11"></div>
     2076      <div id="rfc.iref.c.12"></div>
    20772077      <div id="rfc.iref.h.6"></div>
    20782078      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    … …  
    21032103         connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a>.
    21042104      </p>
    2105       <div id="rfc.iref.c.12"></div>
     2105      <div id="rfc.iref.c.13"></div>
    21062106      <div id="rfc.iref.h.7"></div>
    21072107      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
    … …  
    25142514      </dl>
    25152515      <div id="rfc.iref.m.4"></div>
    2516       <div id="rfc.iref.a.4"></div>
     2516      <div id="rfc.iref.a.5"></div>
    25172517      <h3 id="rfc.section.10.3.2"><a href="#rfc.section.10.3.2">10.3.2</a>&nbsp;<a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3>
    25182518      <p id="rfc.section.10.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p>
    … …  
    27222722      </p>
    27232723      <p id="rfc.section.12.p.4">Thanks to the "cave men" of Palo Alto. You know who you are.</p>
    2724       <p id="rfc.section.12.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott
     2724      <p id="rfc.section.12.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott
    27252725         Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the
    27262726         "MUST/MAY/SHOULD" audit.
    … …  
    27592759            <td class="reference"><b id="RFC1950">[RFC1950]</b></td>
    27602760            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.<br>RFC 1950 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    2761                was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     2761               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    27622762            </td>
    27632763         </tr>
    … …  
    27652765            <td class="reference"><b id="RFC1951">[RFC1951]</b></td>
    27662766            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC&nbsp;1951, May&nbsp;1996.<br>RFC 1951 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    2767                was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     2767               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    27682768            </td>
    27692769         </tr>
    … …  
    27712771            <td class="reference"><b id="RFC1952">[RFC1952]</b></td>
    27722772            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.<br>RFC 1952 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    2773                was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     2773               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    27742774            </td>
    27752775         </tr>
    … …  
    29972997      <p id="rfc.section.B.p.5">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
    29982998         server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described
    2999          in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     2999         in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    30003000      </p>
    30013001      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
    … …  
    30383038      </p>
    30393039      <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented
    3040          in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     3040         in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    30413041      </p>
    30423042      <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    35773577         <ul class="ind">
    35783578            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    3579                   <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">4.1.2</a></li>
    3580                   <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.4"><b>10.3.2</b></a></li>
    3581                   <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.1">4.1.2</a></li>
    3582                   <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">4.1.2</a></li>
     3579                  <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">4.1.2</a></li>
     3580                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
     3581                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>10.3.2</b></a></li>
     3582                  <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">4.1.2</a></li>
     3583                  <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">4.1.2</a></li>
    35833584               </ul>
    35843585            </li>
    … …  
    35893590            </li>
    35903591            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    3591                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li>
    3592                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.4</b></a></li>
    3593                   <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.5">6.2.1</a></li>
     3592                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.4</b></a></li>
     3593                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li>
     3594                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
     3595                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.2.1</a></li>
    35943596                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    35953597                  <li>Coding Format&nbsp;&nbsp;
    35963598                     <ul>
    3597                         <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.2.1</a></li>
    3598                         <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li>
    3599                         <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.9">6.2.2.2</a></li>
    3600                         <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.10">6.2.2.3</a></li>
     3599                        <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.7">6.2.1</a></li>
     3600                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.9">6.2.2.1</a></li>
     3601                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.10">6.2.2.2</a></li>
     3602                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.11">6.2.2.3</a></li>
    36013603                     </ul>
    36023604                  </li>
    3603                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">6.2.2.1</a></li>
     3605                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li>
    36043606                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3605                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.c.11"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li>
    3606                   <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.12"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
     3607                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li>
     3608                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
    36073609               </ul>
    36083610            </li>
    … …  
    38463848                  </li>
    38473849                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li>
    3848                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.1.3</a>, <a href="#rfc.xref.RFC2068.2">7.2.3</a>, <a href="#rfc.xref.RFC2068.3">12</a>, <a href="#rfc.xref.RFC2068.4">13.1</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.7">B</a>, <a href="#rfc.xref.RFC2068.8">B.2</a><ul>
    3849                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.1.3</a>, <a href="#rfc.xref.RFC2068.7">B</a>, <a href="#rfc.xref.RFC2068.8">B.2</a></li>
     3850                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2.5</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B</a>, <a href="#rfc.xref.RFC2068.9">B.2</a><ul>
     3851                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B</a>, <a href="#rfc.xref.RFC2068.9">B.2</a></li>
    38503852                     </ul>
    38513853                  </li>

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

    r1165 r1170  
    705705</t>
    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
    … …  
    731732</t>
    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.
    746750</t>
    747751</section>
    … …  
    826830<t>
    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.
     839</t>
     840<t>
     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.
     848</t>
     849<t>
     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.
    915918</t>
    916919</section>
Note: See TracChangeset for help on using the changeset viewer.