Changeset 1170 for draft-ietf-httpbis
- Timestamp:
- 12/03/11 21:31:37 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1165 r1170 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 2, 2011";361 content: "Expires September 13, 2011"; 362 362 } 363 363 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-03-1 1">412 <meta name="dct.issued" scheme="ISO8601" content="2011-03-12"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: September 1 2, 2011</td>444 <td class="left">Expires: September 13, 2011</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">March 1 1, 2011</td>497 <td class="right">March 12, 2011</td> 498 498 </tr> 499 499 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on September 1 2, 2011.</p>525 <p>This Internet-Draft will expire on September 13, 2011.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 968 968 that preserve HTTP message semantics. 969 969 </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 translates971 the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP972 services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the target973 resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the974 c lient 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 outside976 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. 977 977 </p> 978 978 <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 … … 981 981 such as when transport-layer security is used to establish private communication through a shared firewall proxy. 982 982 </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 nevertheless983 <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 984 984 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> 991 992 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="caches" href="#caches">Caches</a></h2> 992 993 <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 … … 1001 1002 UA =========== A =========== B - - - - - - C - - - - - - O 1002 1003 < < 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. 1004 1005 Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when 1005 1006 that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are … … 1029 1030 than HTTP/12.3. Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent. 1030 1031 </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 1044 1044 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 9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 1045 1045 </p> … … 1069 1069 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1070 1070 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. 1072 1072 </p> 1073 1073 <div id="rfc.iref.r.4"></div> … … 1416 1416 / <a href="#uri" class="smpl">authority</a> 1417 1417 </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. 1419 1419 This is only allowed for the OPTIONS request method. Thus, the only valid example is 1420 1420 </p> 1421 1421 <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, 1423 1423 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 1424 1424 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 … … 1428 1428 </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. 1429 1429 </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>). 1431 1431 </p> 1432 1432 <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 … … 1669 1669 <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. 1670 1670 </p> 1671 <div id="rfc.iref.c.5"></div>1672 1671 <div id="rfc.iref.c.6"></div> 1672 <div id="rfc.iref.c.7"></div> 1673 1673 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3> 1674 1674 <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 … … 1752 1752 </p> 1753 1753 </div> 1754 <div id="rfc.iref.c.7"></div>1755 1754 <div id="rfc.iref.c.8"></div> 1755 <div id="rfc.iref.c.9"></div> 1756 1756 <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h4> 1757 1757 <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 … … 1759 1759 </p> 1760 1760 <div id="rfc.iref.d.2"></div> 1761 <div id="rfc.iref.c. 9"></div>1761 <div id="rfc.iref.c.10"></div> 1762 1762 <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4> 1763 1763 <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>). … … 1768 1768 </div> 1769 1769 <div id="rfc.iref.g.87"></div> 1770 <div id="rfc.iref.c.1 0"></div>1770 <div id="rfc.iref.c.11"></div> 1771 1771 <h4 id="rfc.section.6.2.2.3"><a href="#rfc.section.6.2.2.3">6.2.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4> 1772 1772 <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. … … 1873 1873 to. Each persistent connection applies to only one transport link. 1874 1874 </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). 1876 1876 </p> 1877 1877 <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a> <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> … … 1999 1999 <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, 2000 2000 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 field2001 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 2002 2002 with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated 2003 2003 with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other … … 2074 2074 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 2075 2075 <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.1 1"></div>2076 <div id="rfc.iref.c.12"></div> 2077 2077 <div id="rfc.iref.h.6"></div> 2078 2078 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> … … 2103 2103 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 B.2</a>. 2104 2104 </p> 2105 <div id="rfc.iref.c.1 2"></div>2105 <div id="rfc.iref.c.13"></div> 2106 2106 <div id="rfc.iref.h.7"></div> 2107 2107 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2> … … 2514 2514 </dl> 2515 2515 <div id="rfc.iref.m.4"></div> 2516 <div id="rfc.iref.a. 4"></div>2516 <div id="rfc.iref.a.5"></div> 2517 2517 <h3 id="rfc.section.10.3.2"><a href="#rfc.section.10.3.2">10.3.2</a> <a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3> 2518 2518 <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> … … 2722 2722 </p> 2723 2723 <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, Scott2724 <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 2725 2725 Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the 2726 2726 "MUST/MAY/SHOULD" audit. … … 2759 2759 <td class="reference"><b id="RFC1950">[RFC1950]</b></td> 2760 2760 <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 1950, May 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>. 2762 2762 </td> 2763 2763 </tr> … … 2765 2765 <td class="reference"><b id="RFC1951">[RFC1951]</b></td> 2766 2766 <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 1951, May 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>. 2768 2768 </td> 2769 2769 </tr> … … 2771 2771 <td class="reference"><b id="RFC1952">[RFC1952]</b></td> 2772 2772 <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 1952, May 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>. 2774 2774 </td> 2775 2775 </tr> … … 2997 2997 <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 2998 2998 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>. 3000 3000 </p> 3001 3001 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> … … 3038 3038 </p> 3039 3039 <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>. 3041 3041 </p> 3042 3042 <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 3577 3577 <ul class="ind"> 3578 3578 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3579 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.2">4.1.2</a></li> 3580 <li>application/http Media Type <a href="#rfc.iref.a.4"><b>10.3.2</b></a></li> 3581 <li>asterisk form (of request-target) <a href="#rfc.iref.a.1">4.1.2</a></li> 3582 <li>authority form (of request-target) <a href="#rfc.iref.a.3">4.1.2</a></li> 3579 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.3">4.1.2</a></li> 3580 <li>accelerator <a href="#rfc.iref.a.1"><b>2.3</b></a></li> 3581 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>10.3.2</b></a></li> 3582 <li>asterisk form (of request-target) <a href="#rfc.iref.a.2">4.1.2</a></li> 3583 <li>authority form (of request-target) <a href="#rfc.iref.a.4">4.1.2</a></li> 3583 3584 </ul> 3584 3585 </li> … … 3589 3590 </li> 3590 3591 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3591 <li>cache <a href="#rfc.iref.c.3"><b>2.4</b></a></li> 3592 <li>cacheable <a href="#rfc.iref.c.4"><b>2.4</b></a></li> 3593 <li>chunked (Coding Format) <a href="#rfc.iref.c.5">6.2.1</a></li> 3592 <li>cache <a href="#rfc.iref.c.4"><b>2.4</b></a></li> 3593 <li>cacheable <a href="#rfc.iref.c.5"><b>2.4</b></a></li> 3594 <li>captive portal <a href="#rfc.iref.c.3"><b>2.3</b></a></li> 3595 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">6.2.1</a></li> 3594 3596 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3595 3597 <li>Coding Format 3596 3598 <ul> 3597 <li>chunked <a href="#rfc.iref.c. 6">6.2.1</a></li>3598 <li>compress <a href="#rfc.iref.c. 8">6.2.2.1</a></li>3599 <li>deflate <a href="#rfc.iref.c. 9">6.2.2.2</a></li>3600 <li>gzip <a href="#rfc.iref.c.1 0">6.2.2.3</a></li>3599 <li>chunked <a href="#rfc.iref.c.7">6.2.1</a></li> 3600 <li>compress <a href="#rfc.iref.c.9">6.2.2.1</a></li> 3601 <li>deflate <a href="#rfc.iref.c.10">6.2.2.2</a></li> 3602 <li>gzip <a href="#rfc.iref.c.11">6.2.2.3</a></li> 3601 3603 </ul> 3602 3604 </li> 3603 <li>compress (Coding Format) <a href="#rfc.iref.c. 7">6.2.2.1</a></li>3605 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3604 3606 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3605 <li>Connection header field <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.1 1"><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 <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.1 2"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>3607 <li>Connection header field <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 <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> 3607 3609 </ul> 3608 3610 </li> … … 3846 3848 </li> 3847 3849 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li> 3848 <li><em>RFC2068</em> <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> <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> <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> <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> 3850 3852 </ul> 3851 3853 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1165 r1170 705 705 </t> 706 706 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/> 707 <iref primary="true" item="accelerator"/> 707 708 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 708 709 as a layer above some other server(s) and translates the received 709 710 requests to the underlying server's protocol. Gateways are often 710 used for load balancing or partitioning HTTP services across711 multiple machines.711 used for load balancing, "accelerator" caching, or partitioning 712 HTTP services across multiple machines. 712 713 Unlike a proxy, a gateway receives requests as if it were the 713 714 origin server for the target resource; the requesting client … … 731 732 </t> 732 733 <t><iref primary="true" item="interception proxy"/><iref primary="true" item="transparent proxy"/> 734 <iref primary="true" item="captive portal"/> 733 735 In addition, there may exist network intermediaries that are not 734 736 considered part of the HTTP communication but nevertheless act as 735 737 filters or redirecting agents (usually violating HTTP semantics, 736 738 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", 739 742 differs from an HTTP proxy because it has not been selected by the client. 740 743 Instead, the network intermediary redirects outgoing TCP port 80 packets 741 744 (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, 743 746 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. 746 750 </t> 747 751 </section> … … 826 830 <t> 827 831 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 is829 constructed such that it will be interpreted as a valid HTTP/1.0830 message even if all of the provided header fields not defined in831 the HTTP/1.0 specification <xref target="RFC1945"/> are ignored.832 This specification excludes incompatible message constructions by833 imposing recipient-version requirements on new HTTP/1.1 features834 that are not safely interpreted by earlier HTTP/1.0 recipients.835 </t> 836 <t> 837 The interpretation of an HTTP messageheader field does not change832 <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 838 842 between minor versions of the same major version, though the default 839 843 behavior of a recipient in the absence of such a field can change. 840 844 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 848 851 understood by a recipient, they might override or enhance the 849 852 interpretation of previously defined header fields. When an … … 910 913 changes made to the protocol have the effect of adding to the message 911 914 semantics or implying additional capabilities of the sender. However, 912 the minor version was not incremented for the changes introduced in913 <xref target="RFC2 616"/>, and this revision is specifically avoiding914 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. 915 918 </t> 916 919 </section>
Note: See TracChangeset
for help on using the changeset viewer.