Changeset 1519 for draft-ietf-httpbis/latest
- Timestamp:
- 30/01/12 01:49:16 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1517 r1519 358 358 } 359 359 @bottom-center { 360 content: "Expires July 29, 2012";360 content: "Expires August 1, 2012"; 361 361 } 362 362 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 6">410 <meta name="dct.issued" scheme="ISO8601" content="2012-01-29"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: July 29, 2012</td>442 <td class="left">Expires: August 1, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">January 2 6, 2012</td>495 <td class="right">January 29, 2012</td> 496 496 </tr> 497 497 </tbody> … … 526 526 in progress”. 527 527 </p> 528 <p>This Internet-Draft will expire on July 29, 2012.</p>528 <p>This Internet-Draft will expire on August 1, 2012.</p> 529 529 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 530 530 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 545 545 <ul class="toc"> 546 546 <li>1. <a href="#introduction">Introduction</a><ul> 547 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 548 <li>1.2 <a href="#notation">Syntax Notation</a><ul> 549 <li>1.2.1 <a href="#notation.abnf">ABNF Extension: #rule</a></li> 550 <li>1.2.2 <a href="#basic.rules">Basic Rules</a></li> 551 </ul> 552 </li> 547 <li>1.1 <a href="#intro.requirements">Requirement Notation</a></li> 548 <li>1.2 <a href="#notation">Syntax Notation</a></li> 553 549 </ul> 554 550 </li> 555 551 <li>2. <a href="#architecture">Architecture</a><ul> 556 552 <li>2.1 <a href="#operation">Client/Server Messaging</a></li> 557 <li>2.2 <a href="# message-orientation-and-buffering">Message Orientation and Buffering</a></li>558 <li>2.3 <a href="# transport-independence">Connections and Transport Independence</a></li>559 <li>2.4 <a href="# intermediaries">Intermediaries</a></li>560 <li>2.5 <a href="# caches">Caches</a></li>553 <li>2.2 <a href="#transport-independence">Connections and Transport Independence</a></li> 554 <li>2.3 <a href="#intermediaries">Intermediaries</a></li> 555 <li>2.4 <a href="#caches">Caches</a></li> 556 <li>2.5 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 561 557 <li>2.6 <a href="#http.version">Protocol Versioning</a></li> 562 558 <li>2.7 <a href="#uri">Uniform Resource Identifiers</a><ul> … … 583 579 </li> 584 580 <li>3.2 <a href="#header.fields">Header Fields</a><ul> 585 <li>3.2.1 <a href="#field.parsing">Field Parsing</a></li> 586 <li>3.2.2 <a href="#field.length">Field Length</a></li> 587 <li>3.2.3 <a href="#field.rules">Common Field ABNF Rules</a></li> 581 <li>3.2.1 <a href="#whitespace">Whitespace</a></li> 582 <li>3.2.2 <a href="#field.parsing">Field Parsing</a></li> 583 <li>3.2.3 <a href="#field.length">Field Length</a></li> 584 <li>3.2.4 <a href="#field.components">Field value components</a></li> 585 <li>3.2.5 <a href="#abnf.extension">ABNF list extension: #rule</a></li> 588 586 </ul> 589 587 </li> … … 753 751 thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. 754 752 </p> 755 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>753 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirement Notation</a></h2> 756 754 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 757 755 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 758 </p>759 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,760 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="#architecture" title="Architecture">Section 2</a> for definitions of these terms.761 </p>762 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that763 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.764 </p>765 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.766 </p>767 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling768 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require769 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the770 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of771 error recovery could lead to dangerous consequences.772 756 </p> 773 757 <div id="rfc.iref.g.1"></div> … … 784 768 <div id="rfc.iref.g.12"></div> 785 769 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 786 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> .770 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 787 771 </p> 788 772 <div id="core.rules"> … … 792 776 </p> 793 777 </div> 794 <p id="rfc.section.1.2.p.3">As a syntactic convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical 795 reasons. 796 </p> 797 <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="notation.abnf" href="#notation.abnf">ABNF Extension: #rule</a></h3> 798 <p id="rfc.section.1.2.1.p.1">The #rule extension to the ABNF rules of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> is used to improve readability. 799 </p> 800 <p id="rfc.section.1.2.1.p.2">A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "<n>#<m>element" 801 indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS, <a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>). 802 </p> 803 <div id="rfc.figure.u.1"></div> 804 <p>Thus,</p><pre class="text"> 1#element => element *( OWS "," OWS element ) 805 </pre><div id="rfc.figure.u.2"></div> 806 <p>and:</p><pre class="text"> #element => [ 1#element ] 807 </pre><div id="rfc.figure.u.3"></div> 808 <p>and for n >= 1 and m > 1:</p><pre class="text"> <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 809 </pre><p id="rfc.section.1.2.1.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions: 810 </p> 811 <div id="rfc.figure.u.4"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 812 813 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 814 </pre><p id="rfc.section.1.2.1.p.8">Note that empty elements do not contribute to the count of elements present, though.</p> 815 <p id="rfc.section.1.2.1.p.9">For example, given these ABNF productions:</p> 816 <div id="rfc.figure.u.5"></div><pre class="text"> example-list = 1#example-list-elmt 817 example-list-elmt = token ; see <a href="#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> 818 </pre><p id="rfc.section.1.2.1.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p> 819 <div id="rfc.figure.u.6"></div><pre class="text"> "foo,bar" 820 "foo ,bar," 821 "foo , ,bar,charlie " 822 </pre><p id="rfc.section.1.2.1.p.13">But these values would be invalid, as at least one non-empty element is required:</p> 823 <div id="rfc.figure.u.7"></div><pre class="text"> "" 824 "," 825 ", ," 826 </pre><p id="rfc.section.1.2.1.p.15"> <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rules expanded as explained above. 827 </p> 828 <h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h3> 829 <div id="rule.LWS"> 830 <p id="rfc.section.1.2.2.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), 831 and BWS ("bad" whitespace). 832 </p> 833 </div> 834 <div id="rule.OWS"> 835 <p id="rfc.section.1.2.2.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting 836 the field value or forwarding the message downstream. 837 </p> 838 </div> 839 <div id="rule.RWS"> 840 <p id="rfc.section.1.2.2.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the 841 message downstream. 842 </p> 843 </div> 844 <div id="rule.BWS"> 845 <p id="rfc.section.1.2.2.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. 846 </p> 847 </div> 848 <div id="rule.whitespace"> 849 <p id="rfc.section.1.2.2.p.5"> </p> 850 </div> 851 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold ) 852 ; "optional" whitespace 853 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold ) 854 ; "required" whitespace 855 <a href="#rule.whitespace" class="smpl">BWS</a> = <a href="#rule.whitespace" class="smpl">OWS</a> 856 ; "bad" whitespace 857 <a href="#rule.whitespace" class="smpl">obs-fold</a> = <a href="#core.rules" class="smpl">CRLF</a> ( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) 858 ; obsolete line folding 859 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.1</a> 860 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">Architecture</a></h1> 778 <p id="rfc.section.1.2.p.3">As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.</p> 779 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">Architecture</a></h1> 861 780 <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide 862 781 hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP. … … 889 808 the origin server (O). 890 809 </p> 891 <div id="rfc.figure.u. 9"></div><pre class="drawing"> request >810 <div id="rfc.figure.u.1"></div><pre class="drawing"> request > 892 811 UA ======================================= O 893 812 < response … … 904 823 </p> 905 824 <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 906 <div id="rfc.figure.u. 10"></div>825 <div id="rfc.figure.u.2"></div> 907 826 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 908 827 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 … … 910 829 Accept: */* 911 830 912 </pre><div id="rfc.figure.u. 11"></div>831 </pre><div id="rfc.figure.u.3"></div> 913 832 <p>server response:</p><pre class="text">HTTP/1.1 200 OK 914 833 Date: Mon, 27 Jul 2009 12:28:53 GMT … … 922 841 923 842 <span id="exbody">Hello World! 924 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="message-orientation-and-buffering" href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2> 925 <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations 926 only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some 927 amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide 928 other services. 929 </p> 930 <p id="rfc.section.2.2.p.2">Therefore, extensions to and uses of HTTP cannot rely on the availability of a partial message, or assume that messages will 931 not be buffered. There are strategies that can be used to test for buffering in a given connection, but it should be understood 932 that behaviors can differ across connections, and between requests and responses. 933 </p> 934 <p id="rfc.section.2.2.p.3">Recipients <em class="bcp14">MUST</em> consider every message in a connection in isolation; because HTTP is a stateless protocol, it cannot be assumed that two requests 935 on the same connection are from the same client or share any other common attributes. In particular, intermediaries might 936 mix requests from different clients into a single server connection. Note that some existing HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) violate this requirement, thereby potentially causing interoperability and security problems. 937 </p> 938 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2> 939 <p id="rfc.section.2.3.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable 843 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2> 844 <p id="rfc.section.2.2.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable 940 845 transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request 941 846 and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. 942 847 </p> 943 <p id="rfc.section.2. 3.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's848 <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's 944 849 URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use 945 850 a proxy via some other connection port or protocol instead of using the defaults. 946 851 </p> 947 <p id="rfc.section.2. 3.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>.852 <p id="rfc.section.2.2.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>. 948 853 </p> 949 854 <div id="rfc.iref.i.1"></div> 950 <h2 id="rfc.section.2. 4"><a href="#rfc.section.2.4">2.4</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>951 <p id="rfc.section.2. 4.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of855 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 856 <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of 952 857 HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, 953 858 switching behavior based on the nature of each request. 954 859 </p> 955 <div id="rfc.figure.u. 12"></div><pre class="drawing"> > > > >860 <div id="rfc.figure.u.4"></div><pre class="drawing"> > > > > 956 861 <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b> 957 862 < < < < 958 </pre><p id="rfc.section.2. 4.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response863 </pre><p id="rfc.section.2.3.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response 959 864 message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply 960 865 only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along … … 963 868 at the same time that it is handling A's request. 964 869 </p> 965 <p id="rfc.section.2. 4.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream.870 <p id="rfc.section.2.3.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream. 966 871 Likewise, we use the terms inbound and outbound to refer to directions in relation to the request path: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent. 967 872 </p> 968 <p id="rfc.section.2. 4.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests873 <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests 969 874 for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations 970 875 are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely … … 972 877 for the sake of security, annotation services, or shared caching. 973 878 </p> 974 <p id="rfc.section.2. 4.p.6"> <span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications,879 <p id="rfc.section.2.3.p.6"> <span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications, 975 880 beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original 976 881 sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared … … 980 885 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 981 886 </p> 982 <p id="rfc.section.2. 4.p.7"><span id="rfc.iref.g.16"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying887 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying 983 888 server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance 984 889 through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. 985 890 </p> 986 <p id="rfc.section.2. 4.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements891 <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements 987 892 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 988 893 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 989 894 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.8</a>) header fields for both connections. 990 895 </p> 991 <p id="rfc.section.2. 4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party896 <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party 992 897 to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both 993 898 ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 994 899 when transport-layer security is used to establish private communication through a shared firewall proxy. 995 900 </p> 996 <p id="rfc.section.2. 4.p.10"><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 nevertheless901 <p id="rfc.section.2.3.p.10"><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 997 902 act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a 998 903 mess of things). Such a network intermediary, often referred to as an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "<dfn>captive portal</dfn>", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects … … 1002 907 from a man-in-the-middle attack. 1003 908 </p> 909 <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations 910 depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple 911 servers. Hence, servers <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific 912 to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems. 913 </p> 1004 914 <div id="rfc.iref.c.4"></div> 1005 <h2 id="rfc.section.2. 5"><a href="#rfc.section.2.5">2.5</a> <a id="caches" href="#caches">Caches</a></h2>1006 <p id="rfc.section.2. 5.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.915 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="caches" href="#caches">Caches</a></h2> 916 <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. 1007 917 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 1008 918 requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel. 1009 919 </p> 1010 <p id="rfc.section.2. 5.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached920 <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached 1011 921 response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response 1012 922 from O (via C) for a request which has not been cached by UA or A. 1013 923 </p> 1014 <div id="rfc.figure.u. 13"></div><pre class="drawing"> > >924 <div id="rfc.figure.u.5"></div><pre class="drawing"> > > 1015 925 UA =========== A =========== B - - - - - - C - - - - - - O 1016 926 < < 1017 </pre><p id="rfc.section.2. 5.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response927 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 1018 928 is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 1019 929 can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1020 930 </p> 1021 <p id="rfc.section.2. 5.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and931 <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and 1022 932 inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems 1023 933 that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so 1024 934 on. 935 </p> 936 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 937 <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 938 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 939 or caches, depending on what behavior is being constrained by the requirement. 940 </p> 941 <p id="rfc.section.2.5.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 942 in HTTP. 943 </p> 944 <p id="rfc.section.2.5.p.3">Senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements. 945 </p> 946 <p id="rfc.section.2.5.p.4">Unless otherwise noted, recipients <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 947 except when they have a direct impact on security, since different applications of the protocol require different error handling 948 strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field 949 doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous. 1025 950 </p> 1026 951 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="http.version" href="#http.version">Protocol Versioning</a></h2> … … 1030 955 </p> 1031 956 <p id="rfc.section.2.6.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 1032 <div id="rfc.figure.u. 14"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>957 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a> 1033 958 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 1034 959 </pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major … … 1089 1014 "path-absolute", "query", and "authority" from the URI generic syntax <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI but not a fragment. 1090 1015 </p> 1091 <div id="rfc.figure.u. 15"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>>1016 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>> 1092 1017 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> 1093 1018 <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>> … … 1111 1036 namespace governed by a potential HTTP origin server listening for TCP connections on a given port. 1112 1037 </p> 1113 <div id="rfc.figure.u. 16"></div><pre class="inline"><span id="rfc.iref.g.26"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]1038 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1114 1039 </pre><p id="rfc.section.2.7.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an 1115 1040 identifier for a potential resource within that origin server's name space. … … 1150 1075 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request. 1151 1076 </p> 1152 <div id="rfc.figure.u. 17"></div><pre class="inline"><span id="rfc.iref.g.27"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]1077 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1153 1078 </pre><p id="rfc.section.2.7.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 1154 1079 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). … … 1171 1096 </p> 1172 1097 <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p> 1173 <div id="rfc.figure.u.1 8"></div><pre class="text"> http://example.com:80/~smith/home.html1098 <div id="rfc.figure.u.10"></div><pre class="text"> http://example.com:80/~smith/home.html 1174 1099 http://EXAMPLE.com/%7Esmith/home.html 1175 1100 http://EXAMPLE.com:/%7esmith/home.html … … 1182 1107 the end of the header section, and an optional message-body. 1183 1108 </p> 1184 <div id="rfc.figure.u.1 9"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a>1109 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a> 1185 1110 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1186 1111 <a href="#core.rules" class="smpl">CRLF</a> … … 1196 1121 the message, such as within a header field-value after message parsing has delineated the individual fields. 1197 1122 </p> 1123 <p id="rfc.section.3.p.5">An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, recipients cannot 1124 rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the 1125 sake of network efficiency, security checks, or payload transformations. 1126 </p> 1198 1127 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="start.line" href="#start.line">Start Line</a></h2> 1199 1128 <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two … … 1203 1132 or invalid request method) and clients are implemented to only expect a response. 1204 1133 </p> 1205 <div id="rfc.figure.u. 20"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request.line" class="smpl">Request-Line</a> / <a href="#status.line" class="smpl">Status-Line</a>1134 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.26"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request.line" class="smpl">Request-Line</a> / <a href="#status.line" class="smpl">Status-Line</a> 1206 1135 </pre><p id="rfc.section.3.1.p.4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an 1207 1136 attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might … … 1213 1142 the protocol version, and ending with CRLF. 1214 1143 </p> 1215 <div id="rfc.figure.u. 21"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#request.line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>1144 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.27"></span> <a href="#request.line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a> 1216 1145 </pre><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a> <a id="method" href="#method">Method</a></h4> 1217 1146 <p id="rfc.section.3.1.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1218 <div id="rfc.figure.u. 22"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a>1147 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1219 1148 </pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations 1220 1149 for new methods. … … 1224 1153 described in <a href="#request-target-types" title="Types of Request Target">Section 4.1</a>. 1225 1154 </p> 1226 <div id="rfc.figure.u. 23"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#request-target" class="smpl">request-target</a> = "*"1155 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1227 1156 / <a href="#uri" class="smpl">absolute-URI</a> 1228 1157 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) … … 1241 1170 another space, a possibly-empty textual phrase describing the status code, and ending with CRLF. 1242 1171 </p> 1243 <div id="rfc.figure.u. 24"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#status.line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1172 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status.line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1244 1173 </pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a> <a id="status.code" href="#status.code">Status Code</a></h4> 1245 1174 <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1246 1175 for new status codes. 1247 1176 </p> 1248 <div id="rfc.figure.u. 25"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#status.code" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1177 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#status.code" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1249 1178 </pre><h4 id="rfc.section.3.1.2.2"><a href="#rfc.section.3.1.2.2">3.1.2.2</a> <a id="reason.phrase" href="#reason.phrase">Reason Phrase</a></h4> 1250 1179 <p id="rfc.section.3.1.2.2.p.1">The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, … … 1252 1181 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. 1253 1182 </p> 1254 <div id="rfc.figure.u. 26"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )1183 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1255 1184 </pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.fields" href="#header.fields">Header Fields</a></h2> 1256 1185 <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field 1257 1186 value. 1258 1187 </p> 1259 <div id="rfc.figure.u. 27"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">BWS</a>1188 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#header.fields" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">BWS</a> 1260 1189 <a href="#header.fields" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1261 1190 <a href="#header.fields" class="smpl">field-value</a> = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">obs-fold</a> ) … … 1288 1217 </p> 1289 1218 </div> 1290 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3> 1291 <p id="rfc.section.3.2.1.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace 1219 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="whitespace" href="#whitespace">Whitespace</a></h3> 1220 <div id="rule.LWS"> 1221 <p id="rfc.section.3.2.1.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), 1222 and BWS ("bad" whitespace). 1223 </p> 1224 </div> 1225 <div id="rule.OWS"> 1226 <p id="rfc.section.3.2.1.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting 1227 the field value or forwarding the message downstream. 1228 </p> 1229 </div> 1230 <div id="rule.RWS"> 1231 <p id="rfc.section.3.2.1.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the 1232 message downstream. 1233 </p> 1234 </div> 1235 <div id="rule.BWS"> 1236 <p id="rfc.section.3.2.1.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. 1237 </p> 1238 </div> 1239 <div id="rule.whitespace"> 1240 <p id="rfc.section.3.2.1.p.5"> </p> 1241 </div> 1242 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#header.fields" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold ) 1243 ; "optional" whitespace 1244 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> / obs-fold ) 1245 ; "required" whitespace 1246 <a href="#rule.whitespace" class="smpl">BWS</a> = <a href="#header.fields" class="smpl">OWS</a> 1247 ; "bad" whitespace 1248 <a href="#rule.whitespace" class="smpl">obs-fold</a> = <a href="#core.rules" class="smpl">CRLF</a> ( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) 1249 ; obsolete line folding 1250 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1251 </pre><h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3> 1252 <p id="rfc.section.3.2.2.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace 1292 1253 have led to security vulnerabilities in request routing and response handling. Any received request message that contains 1293 1254 whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. 1294 1255 </p> 1295 <p id="rfc.section.3.2. 1.p.2">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing1256 <p id="rfc.section.3.2.2.p.2">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing 1296 1257 white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet 1297 1258 of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field). 1298 1259 </p> 1299 <p id="rfc.section.3.2. 1.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one1260 <p id="rfc.section.3.2.2.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1300 1261 space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type 1301 1262 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the … … 1303 1264 (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream. 1304 1265 </p> 1305 <p id="rfc.section.3.2. 1.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data.1306 </p> 1307 <h3 id="rfc.section.3.2. 2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.length" href="#field.length">Field Length</a></h3>1308 <p id="rfc.section.3.2. 2.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header1266 <p id="rfc.section.3.2.2.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data. 1267 </p> 1268 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="field.length" href="#field.length">Field Length</a></h3> 1269 <p id="rfc.section.3.2.3.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header 1309 1270 field(s) would be longer than the server wishes to handle. 1310 1271 </p> 1311 <p id="rfc.section.3.2. 2.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p>1312 <p id="rfc.section.3.2. 2.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.1313 </p> 1314 <h3 id="rfc.section.3.2. 3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="field.rules" href="#field.rules">Common Field ABNF Rules</a></h3>1272 <p id="rfc.section.3.2.3.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p> 1273 <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets. 1274 </p> 1275 <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="field.components" href="#field.components">Field value components</a></h3> 1315 1276 <div id="rule.token.separators"> 1316 <p id="rfc.section.3.2. 3.p.1"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.1277 <p id="rfc.section.3.2.4.p.1"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. 1317 1278 These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). 1318 1279 </p> 1319 1280 </div> 1320 <div id="rfc.figure.u.2 8"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span> <a href="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>1281 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span> <a href="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> 1321 1282 1322 1283 <a href="#rule.token.separators" class="smpl">token</a> = 1*<a href="#rule.token.separators" class="smpl">tchar</a> … … 1331 1292 / "]" / "?" / "=" / "{" / "}" 1332 1293 </pre><div id="rule.quoted-string"> 1333 <p id="rfc.section.3.2. 3.p.3"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p>1294 <p id="rfc.section.3.2.4.p.3"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 1334 1295 </div> 1335 <div id="rfc.figure.u.2 9"></div><pre class="inline"><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span> <a href="#rule.quoted-string" class="smpl">quoted-string</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>1336 <a href="#rule.quoted-string" class="smpl">qdtext</a> = <a href="# rule.whitespace" class="smpl">OWS</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>1296 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span> <a href="#rule.quoted-string" class="smpl">quoted-string</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> 1297 <a href="#rule.quoted-string" class="smpl">qdtext</a> = <a href="#header.fields" class="smpl">OWS</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1337 1298 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF 1338 1299 </pre><div id="rule.quoted-pair"> 1339 <p id="rfc.section.3.2. 3.p.5"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p>1300 <p id="rfc.section.3.2.4.p.5"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p> 1340 1301 </div> 1341 <div id="rfc.figure.u. 30"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )1342 </pre><p id="rfc.section.3.2. 3.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.1343 </p> 1344 <p id="rfc.section.3.2. 3.p.8">Senders <em class="bcp14">SHOULD NOT</em> escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet).1302 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1303 </pre><p id="rfc.section.3.2.4.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 1304 </p> 1305 <p id="rfc.section.3.2.4.p.8">Senders <em class="bcp14">SHOULD NOT</em> escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet). 1345 1306 </p> 1346 1307 <div id="rule.comment"> 1347 <p id="rfc.section.3.2. 3.p.9"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed1308 <p id="rfc.section.3.2.4.p.9"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed 1348 1309 in fields containing "comment" as part of their field value definition. 1349 1310 </p> 1350 1311 </div> 1351 <div id="rfc.figure.u. 31"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"1352 <a href="#rule.comment" class="smpl">ctext</a> = <a href="# rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>1312 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1313 <a href="#rule.comment" class="smpl">ctext</a> = <a href="#header.fields" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1353 1314 </pre><div id="rule.quoted-cpair"> 1354 <p id="rfc.section.3.2. 3.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p>1315 <p id="rfc.section.3.2.4.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> 1355 1316 </div> 1356 <div id="rfc.figure.u. 32"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )1357 </pre><p id="rfc.section.3.2. 3.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and1317 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1318 </pre><p id="rfc.section.3.2.4.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and 1358 1319 ")"). 1320 </p> 1321 <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a id="abnf.extension" href="#abnf.extension">ABNF list extension: #rule</a></h3> 1322 <p id="rfc.section.3.2.5.p.1">A #rule extension to the ABNF rules of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> is used to improve readability in the definitions of some header field values. 1323 </p> 1324 <p id="rfc.section.3.2.5.p.2">A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "<n>#<m>element" 1325 indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS). 1326 </p> 1327 <div id="rfc.figure.u.26"></div> 1328 <p>Thus,</p><pre class="text"> 1#element => element *( OWS "," OWS element ) 1329 </pre><div id="rfc.figure.u.27"></div> 1330 <p>and:</p><pre class="text"> #element => [ 1#element ] 1331 </pre><div id="rfc.figure.u.28"></div> 1332 <p>and for n >= 1 and m > 1:</p><pre class="text"> <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 1333 </pre><p id="rfc.section.3.2.5.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions: 1334 </p> 1335 <div id="rfc.figure.u.29"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 1336 1337 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 1338 </pre><p id="rfc.section.3.2.5.p.8">Note that empty elements do not contribute to the count of elements present, though.</p> 1339 <p id="rfc.section.3.2.5.p.9">For example, given these ABNF productions:</p> 1340 <div id="rfc.figure.u.30"></div><pre class="text"> example-list = 1#example-list-elmt 1341 example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section 3.2.4</a> 1342 </pre><p id="rfc.section.3.2.5.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p> 1343 <div id="rfc.figure.u.31"></div><pre class="text"> "foo,bar" 1344 "foo ,bar," 1345 "foo , ,bar,charlie " 1346 </pre><p id="rfc.section.3.2.5.p.13">But these values would be invalid, as at least one non-empty element is required:</p> 1347 <div id="rfc.figure.u.32"></div><pre class="text"> "" 1348 "," 1349 ", ," 1350 </pre><p id="rfc.section.3.2.5.p.15"> <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rules expanded as explained above. 1359 1351 </p> 1360 1352 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> … … 1480 1472 </p> 1481 1473 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2> 1482 <p id="rfc.section.4.1.p.1">The four options for request-target are dependent on the nature of the request.</p> 1483 <div id="asterix-form"> 1484 <p id="rfc.section.4.1.p.2"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening 1474 <p id="rfc.section.4.1.p.1">The proper format choice of the four options available to request-target depends on the method being requested and if the 1475 request is being made to a proxy. 1476 </p> 1477 <div id="origin-form"> 1478 <p id="rfc.section.4.1.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a 1479 resource identified by an "http" (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) URI. In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target and the authority component (excluding any userinfo) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource identified 1480 as 1481 </p> 1482 </div> 1483 <div id="rfc.figure.u.34"></div><pre>http://www.example.org/where?q=now 1484 </pre><p id="rfc.section.4.1.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the 1485 lines: 1486 </p> 1487 <div id="rfc.figure.u.35"></div><pre class="text2">GET /where?q=now HTTP/1.1 1488 Host: www.example.org 1489 </pre><p id="rfc.section.4.1.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path. 1490 If the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target. 1491 </p> 1492 <p id="rfc.section.4.1.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1493 </p> 1494 <div id="absolute-URI-form"> 1495 <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid 1496 cache, and then 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 1497 loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses. 1498 An example Request-Line would be: 1499 </p> 1500 </div> 1501 <div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1502 </pre><p id="rfc.section.4.1.p.10">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. 1503 </p> 1504 <p id="rfc.section.4.1.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1505 </p> 1506 <div id="authority-form"> 1507 <p id="rfc.section.4.1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example, 1508 </p> 1509 </div> 1510 <div id="rfc.figure.u.37"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1511 </pre><div id="asterix-form"> 1512 <p id="rfc.section.4.1.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening 1485 1513 process) rather than to a specific named resource at that server. For example, 1486 1514 </p> 1487 1515 </div> 1488 <div id="rfc.figure.u.34"></div><pre class="text2">OPTIONS * HTTP/1.1 1489 </pre><div id="absolute-URI-form"> 1490 <p id="rfc.section.4.1.p.4"><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 either forward the request or service it from a valid 1491 cache, and then 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 1492 loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, and the numeric IP 1493 address. An example Request-Line would be: 1494 </p> 1495 </div> 1496 <div id="rfc.figure.u.35"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1497 </pre><p id="rfc.section.4.1.p.6">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. 1498 </p> 1499 <p id="rfc.section.4.1.p.7">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1500 </p> 1501 <div id="authority-form"> 1502 <p id="rfc.section.4.1.p.8"><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 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1503 </p> 1504 </div> 1505 <div id="origin-form"> 1506 <p id="rfc.section.4.1.p.9"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case, 1507 the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified 1508 above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and 1509 send the lines: 1510 </p> 1511 </div> 1512 <div id="rfc.figure.u.36"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1 1513 Host: www.example.org 1514 </pre><p id="rfc.section.4.1.p.11">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path; 1515 if the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target. 1516 </p> 1517 <p id="rfc.section.4.1.p.12">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and 1516 <div id="rfc.figure.u.38"></div><pre class="text2">OPTIONS * HTTP/1.1 1517 </pre><p id="rfc.section.4.1.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and 1518 1518 no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server. 1519 1519 </p> 1520 <div id="rfc.figure.u.3 7"></div>1520 <div id="rfc.figure.u.39"></div> 1521 1521 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1522 </pre><div id="rfc.figure.u. 38"></div>1522 </pre><div id="rfc.figure.u.40"></div> 1523 1523 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1524 1524 Host: www.example.org:8001 1525 1525 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> 1526 <p id="rfc.section.4.1.p.15">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1527 </p> 1528 <p id="rfc.section.4.1.p.16">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1526 <p id="rfc.section.4.1.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1529 1527 except as noted above to replace a null path-absolute with "/" or "*". 1530 1528 </p> 1531 <div class="note" id="rfc.section.4.1.p.17">1532 <p> <b>Note:</b> The "no rewrite" rule above prevents the proxy from changing the meaning of the request when the origin server is improperly1533 using a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have1534 been known to rewrite the request-target.1535 </p>1536 </div>1537 1529 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> 1538 1530 <p id="rfc.section.4.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header … … 1581 1573 </p> 1582 1574 <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 1583 <div id="rfc.figure.u. 39"></div>1575 <div id="rfc.figure.u.41"></div> 1584 1576 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1585 1577 Host: www.example.org:8080 … … 1587 1579 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 1588 1580 </p> 1589 <div id="rfc.figure.u.4 0"></div>1581 <div id="rfc.figure.u.42"></div> 1590 1582 <p>Example 2: the effective request URI for the message</p> <pre class="text">OPTIONS * HTTP/1.1 1591 1583 Host: www.example.org … … 1601 1593 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1602 1594 </p> 1603 <div id="rfc.figure.u.4 1"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>1595 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> 1604 1596 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 5.1.2.1</a> 1605 1597 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> 1606 1598 / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> 1607 1599 / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1608 <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="# rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> )1600 <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> ) 1609 1601 </pre><div id="rule.parameter"> 1610 1602 <p id="rfc.section.5.1.p.3"> Parameters are in the form of attribute/value pairs.</p> 1611 1603 </div> 1612 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1604 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1613 1605 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1614 1606 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> … … 1628 1620 for the recipient to verify that it has received the full message. 1629 1621 </p> 1630 <div id="rfc.figure.u.4 3"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1622 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1631 1623 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1632 1624 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1671 1663 </p> 1672 1664 <p id="rfc.section.5.1.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1673 <div id="rfc.figure.u.4 4"></div><pre class="text"> length := 01665 <div id="rfc.figure.u.46"></div><pre class="text"> length := 0 1674 1666 read chunk-size, chunk-ext (if any) and CRLF 1675 1667 while (chunk-size > 0) { … … 1743 1735 By convention, the products are listed in order of their significance for identifying the application. 1744 1736 </p> 1745 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1737 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1746 1738 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1747 1739 </pre><p id="rfc.section.5.2.p.3">Examples:</p> 1748 <div id="rfc.figure.u.4 6"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31740 <div id="rfc.figure.u.48"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1749 1741 Server: Apache/0.8.4 1750 1742 </pre><p id="rfc.section.5.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). … … 1755 1747 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 1756 1748 </p> 1757 <div id="rfc.figure.u.4 7"></div><pre class="inline"><span id="rfc.iref.g.73"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1749 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.73"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1758 1750 / ( "1" [ "." 0*3("0") ] ) 1759 1751 </pre><div class="note" id="rfc.section.5.3.p.3"> … … 2056 2048 </p> 2057 2049 <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p> 2058 <div id="rfc.figure.u. 48"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a>2050 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2059 2051 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 2060 2052 </pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove … … 2079 2071 of the response. For example, 2080 2072 </p> 2081 <div id="rfc.figure.u. 49"></div><pre class="text"> Connection: close2073 <div id="rfc.figure.u.51"></div><pre class="text"> Connection: close 2082 2074 </pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>) after the current request/response is complete. 2083 2075 </p> … … 2095 2087 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 2096 2088 </p> 2097 <div id="rfc.figure.u.5 0"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>2089 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 2098 2090 </pre><p id="rfc.section.8.2.p.3">An example is</p> 2099 <div id="rfc.figure.u.5 1"></div><pre class="text"> Content-Length: 34952091 <div id="rfc.figure.u.53"></div><pre class="text"> Content-Length: 3495 2100 2092 </pre><p id="rfc.section.8.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length 2101 2093 can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section 3.3</a> describes how recipients determine the length of a message-body. … … 2112 2104 Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line. 2113 2105 </p> 2114 <div id="rfc.figure.u.5 2"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>2106 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a> 2115 2107 </pre><p id="rfc.section.8.3.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then 2116 2108 the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 2117 2109 </p> 2118 2110 <p id="rfc.section.8.3.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 2119 <div id="rfc.figure.u.5 3"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12111 <div id="rfc.figure.u.55"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2120 2112 Host: www.example.org 2121 2113 </pre><p id="rfc.section.8.3.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information … … 2144 2136 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). 2145 2137 </p> 2146 <div id="rfc.figure.u.5 4"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>2138 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 2147 2139 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) 2148 <a href="#header.te" class="smpl">te-params</a> = <a href="# rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )2149 <a href="#header.te" class="smpl">te-ext</a> = <a href="# rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]2140 <a href="#header.te" class="smpl">te-params</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> ) 2141 <a href="#header.te" class="smpl">te-ext</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ] 2150 2142 </pre><p id="rfc.section.8.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, 2151 2143 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding. 2152 2144 </p> 2153 2145 <p id="rfc.section.8.4.p.5">Examples of its use are:</p> 2154 <div id="rfc.figure.u.5 5"></div><pre class="text"> TE: deflate2146 <div id="rfc.figure.u.57"></div><pre class="text"> TE: deflate 2155 2147 TE: 2156 2148 TE: trailers, deflate;q=0.5 … … 2189 2181 chunked transfer-coding. 2190 2182 </p> 2191 <div id="rfc.figure.u.5 6"></div><pre class="inline"><span id="rfc.iref.g.82"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>2183 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.82"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 2192 2184 </pre><p id="rfc.section.8.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 2193 2185 to know which header fields to expect in the trailer. … … 2209 2201 are not. 2210 2202 </p> 2211 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.83"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>2203 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.83"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 2212 2204 </pre><p id="rfc.section.8.6.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>. An example is: 2213 2205 </p> 2214 <div id="rfc.figure.u. 58"></div><pre class="text"> Transfer-Encoding: chunked2206 <div id="rfc.figure.u.60"></div><pre class="text"> Transfer-Encoding: chunked 2215 2207 </pre><p id="rfc.section.8.6.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 2216 2208 </p> … … 2222 2214 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2223 2215 </p> 2224 <div id="rfc.figure.u. 59"></div><pre class="inline"><span id="rfc.iref.g.84"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>2216 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.84"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a> 2225 2217 </pre><p id="rfc.section.8.7.p.3">For example,</p> 2226 <div id="rfc.figure.u.6 0"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112218 <div id="rfc.figure.u.62"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2227 2219 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2228 2220 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2279 2271 of all senders along the request/response chain. 2280 2272 </p> 2281 <div id="rfc.figure.u.6 1"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>2273 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 2282 2274 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2283 2275 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a> … … 2303 2295 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2304 2296 </p> 2305 <div id="rfc.figure.u.6 2"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2297 <div id="rfc.figure.u.64"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2306 2298 </pre><p id="rfc.section.8.8.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, 2307 2299 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. … … 2310 2302 For example, 2311 2303 </p> 2312 <div id="rfc.figure.u.6 3"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2304 <div id="rfc.figure.u.65"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2313 2305 </pre><p id="rfc.section.8.8.p.12">could be collapsed to</p> 2314 <div id="rfc.figure.u.6 4"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2306 <div id="rfc.figure.u.66"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2315 2307 </pre><p id="rfc.section.8.8.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 2316 2308 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2956 2948 </p> 2957 2949 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 2958 <p id="rfc.section.A.2.p.1">Empty list elements in list productions have been deprecated. (<a href="# notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a>)2959 </p> 2960 <p id="rfc.section.A.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically2961 pointed out in the ABNF. (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>)2950 <p id="rfc.section.A.2.p.1">Empty list elements in list productions have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a>) 2951 </p> 2952 <p id="rfc.section.A.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed 2953 where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section 3.2.1</a>) 2962 2954 </p> 2963 2955 <p id="rfc.section.A.2.p.3">Clarify that the string "HTTP" in the HTTP-Version ABFN production is case sensitive. Restrict the version numbers to be single … … 2968 2960 <p id="rfc.section.A.2.p.5">The NUL octet is no longer allowed in comment and quoted-string text. The quoted-pair rule no longer allows escaping control 2969 2961 characters other than HTAB. Non-ASCII content in header fields and reason phrase has been obsoleted and made opaque (the TEXT 2970 rule was removed). (<a href="#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>)2962 rule was removed). (<a href="#field.components" title="Field value components">Section 3.2.4</a>) 2971 2963 </p> 2972 2964 <p id="rfc.section.A.2.p.6">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>) … … 2992 2984 </p> 2993 2985 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 2994 <div id="rfc.figure.u.6 5"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS2986 <div id="rfc.figure.u.67"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 2995 2987 2996 2988 <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF … … 3007 2999 <a href="#method" class="smpl">Method</a> = token 3008 3000 3009 <a href="# rule.whitespace" class="smpl">OWS</a> = *( SP / HTAB / obs-fold )3001 <a href="#header.fields" class="smpl">OWS</a> = *( SP / HTAB / obs-fold ) 3010 3002 3011 3003 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( SP / HTAB / obs-fold ) … … 3110 3102 3111 3103 <a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string 3112 </pre> <div id="rfc.figure.u.6 6"></div>3104 </pre> <div id="rfc.figure.u.68"></div> 3113 3105 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3114 3106 ; Connection defined but not used … … 3506 3498 <ul class="ind"> 3507 3499 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3508 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a. 3">4.1</a></li>3509 <li>accelerator <a href="#rfc.iref.a.1"><b>2. 4</b></a></li>3500 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.2">4.1</a></li> 3501 <li>accelerator <a href="#rfc.iref.a.1"><b>2.3</b></a></li> 3510 3502 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>9.3.2</b></a></li> 3511 <li>asterisk form (of request-target) <a href="#rfc.iref.a. 2">4.1</a></li>3512 <li>authority form (of request-target) <a href="#rfc.iref.a. 4">4.1</a></li>3503 <li>asterisk form (of request-target) <a href="#rfc.iref.a.4">4.1</a></li> 3504 <li>authority form (of request-target) <a href="#rfc.iref.a.3">4.1</a></li> 3513 3505 </ul> 3514 3506 </li> … … 3518 3510 </li> 3519 3511 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3520 <li>cache <a href="#rfc.iref.c.4"><b>2. 5</b></a></li>3521 <li>cacheable <a href="#rfc.iref.c.5"><b>2. 5</b></a></li>3522 <li>captive portal <a href="#rfc.iref.c.3"><b>2. 4</b></a></li>3512 <li>cache <a href="#rfc.iref.c.4"><b>2.4</b></a></li> 3513 <li>cacheable <a href="#rfc.iref.c.5"><b>2.4</b></a></li> 3514 <li>captive portal <a href="#rfc.iref.c.3"><b>2.3</b></a></li> 3523 3515 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">5.1.1</a></li> 3524 3516 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> … … 3533 3525 <li>compress (Coding Format) <a href="#rfc.iref.c.8">5.1.2.1</a></li> 3534 3526 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3535 <li>Connection header field <a href="#rfc.xref.header.connection.1">2. 4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>3527 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3536 3528 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3537 3529 </ul> … … 3539 3531 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3540 3532 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">5.1.2.2</a></li> 3541 <li>downstream <a href="#rfc.iref.d.1"><b>2. 4</b></a></li>3533 <li>downstream <a href="#rfc.iref.d.1"><b>2.3</b></a></li> 3542 3534 </ul> 3543 3535 </li> … … 3547 3539 </li> 3548 3540 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3549 <li>gateway <a href="#rfc.iref.g.1 6"><b>2.4</b></a></li>3541 <li>gateway <a href="#rfc.iref.g.13"><b>2.3</b></a></li> 3550 3542 <li><tt>Grammar</tt> 3551 3543 <ul> 3552 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g. 20"><b>2.7</b></a></li>3544 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.7</b></a></li> 3553 3545 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3554 3546 <li><tt>attribute</tt> <a href="#rfc.iref.g.55"><b>5.1</b></a></li> 3555 <li><tt>authority</tt> <a href="#rfc.iref.g. 21"><b>2.7</b></a></li>3556 <li><tt>BWS</tt> <a href="#rfc.iref.g. 15"><b>1.2.2</b></a></li>3547 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3548 <li><tt>BWS</tt> <a href="#rfc.iref.g.39"><b>3.2.1</b></a></li> 3557 3549 <li><tt>chunk</tt> <a href="#rfc.iref.g.60"><b>5.1.1</b></a></li> 3558 3550 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.66"><b>5.1.1</b></a></li> … … 3562 3554 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.61"><b>5.1.1</b></a></li> 3563 3555 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g.59"><b>5.1.1</b></a></li> 3564 <li><tt>comment</tt> <a href="#rfc.iref.g.48"><b>3.2. 3</b></a></li>3556 <li><tt>comment</tt> <a href="#rfc.iref.g.48"><b>3.2.4</b></a></li> 3565 3557 <li><tt>Connection</tt> <a href="#rfc.iref.g.74"><b>8.1</b></a></li> 3566 3558 <li><tt>connection-token</tt> <a href="#rfc.iref.g.75"><b>8.1</b></a></li> … … 3568 3560 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3569 3561 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3570 <li><tt>ctext</tt> <a href="#rfc.iref.g.49"><b>3.2. 3</b></a></li>3562 <li><tt>ctext</tt> <a href="#rfc.iref.g.49"><b>3.2.4</b></a></li> 3571 3563 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3572 3564 <li><tt>date2</tt> <a href="#rfc.iref.g.57"><b>5.1</b></a></li> … … 3574 3566 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3575 3567 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> 3576 <li><tt>field-content</tt> <a href="#rfc.iref.g.3 9"><b>3.2</b></a></li>3577 <li><tt>field-name</tt> <a href="#rfc.iref.g.3 7"><b>3.2</b></a></li>3578 <li><tt>field-value</tt> <a href="#rfc.iref.g.3 8"><b>3.2</b></a></li>3579 <li><tt>header-field</tt> <a href="#rfc.iref.g.3 6"><b>3.2</b></a></li>3568 <li><tt>field-content</tt> <a href="#rfc.iref.g.36"><b>3.2</b></a></li> 3569 <li><tt>field-name</tt> <a href="#rfc.iref.g.34"><b>3.2</b></a></li> 3570 <li><tt>field-value</tt> <a href="#rfc.iref.g.35"><b>3.2</b></a></li> 3571 <li><tt>header-field</tt> <a href="#rfc.iref.g.33"><b>3.2</b></a></li> 3580 3572 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3581 3573 <li><tt>Host</tt> <a href="#rfc.iref.g.77"><b>8.3</b></a></li> 3582 3574 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3583 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.2 8"><b>3</b></a></li>3584 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g.1 8"><b>2.6</b></a></li>3585 <li><tt>http-URI</tt> <a href="#rfc.iref.g.2 6"><b>2.7.1</b></a></li>3586 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.1 7"><b>2.6</b></a></li>3587 <li><tt>https-URI</tt> <a href="#rfc.iref.g.2 7"><b>2.7.2</b></a></li>3575 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.25"><b>3</b></a></li> 3576 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g.15"><b>2.6</b></a></li> 3577 <li><tt>http-URI</tt> <a href="#rfc.iref.g.23"><b>2.7.1</b></a></li> 3578 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.14"><b>2.6</b></a></li> 3579 <li><tt>https-URI</tt> <a href="#rfc.iref.g.24"><b>2.7.2</b></a></li> 3588 3580 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.62"><b>5.1.1</b></a></li> 3589 3581 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3590 3582 <li><tt>message-body</tt> <a href="#rfc.iref.g.51"><b>3.3</b></a></li> 3591 <li><tt>Method</tt> <a href="#rfc.iref.g. 31"><b>3.1.1.1</b></a></li>3592 <li><tt>obs-text</tt> <a href="#rfc.iref.g.46"><b>3.2. 3</b></a></li>3583 <li><tt>Method</tt> <a href="#rfc.iref.g.28"><b>3.1.1.1</b></a></li> 3584 <li><tt>obs-text</tt> <a href="#rfc.iref.g.46"><b>3.2.4</b></a></li> 3593 3585 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3594 <li><tt>OWS</tt> <a href="#rfc.iref.g. 13"><b>1.2.2</b></a></li>3595 <li><tt>path-absolute</tt> <a href="#rfc.iref.g. 22"><b>2.7</b></a></li>3596 <li><tt>port</tt> <a href="#rfc.iref.g.2 3"><b>2.7</b></a></li>3586 <li><tt>OWS</tt> <a href="#rfc.iref.g.37"><b>3.2.1</b></a></li> 3587 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3588 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3597 3589 <li><tt>product</tt> <a href="#rfc.iref.g.71"><b>5.2</b></a></li> 3598 3590 <li><tt>product-version</tt> <a href="#rfc.iref.g.72"><b>5.2</b></a></li> … … 3600 3592 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>8.8</b></a></li> 3601 3593 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.90"><b>8.8</b></a></li> 3602 <li><tt>qdtext</tt> <a href="#rfc.iref.g.45"><b>3.2. 3</b></a></li>3594 <li><tt>qdtext</tt> <a href="#rfc.iref.g.45"><b>3.2.4</b></a></li> 3603 3595 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.69"><b>5.1.1</b></a></li> 3604 <li><tt>query</tt> <a href="#rfc.iref.g.2 4"><b>2.7</b></a></li>3605 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.50"><b>3.2. 3</b></a></li>3606 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.47"><b>3.2. 3</b></a></li>3596 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3597 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.50"><b>3.2.4</b></a></li> 3598 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.47"><b>3.2.4</b></a></li> 3607 3599 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.68"><b>5.1.1</b></a></li> 3608 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.44"><b>3.2. 3</b></a></li>3600 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.44"><b>3.2.4</b></a></li> 3609 3601 <li><tt>qvalue</tt> <a href="#rfc.iref.g.73"><b>5.3</b></a></li> 3610 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.3 5"><b>3.1.2.2</b></a></li>3602 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li> 3611 3603 <li><tt>received-by</tt> <a href="#rfc.iref.g.89"><b>8.8</b></a></li> 3612 3604 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.86"><b>8.8</b></a></li> 3613 <li><tt>Request-Line</tt> <a href="#rfc.iref.g. 30"><b>3.1.1</b></a></li>3614 <li><tt>request-target</tt> <a href="#rfc.iref.g. 32"><b>3.1.1.2</b></a></li>3615 <li><tt>RWS</tt> <a href="#rfc.iref.g. 14"><b>1.2.2</b></a></li>3605 <li><tt>Request-Line</tt> <a href="#rfc.iref.g.27"><b>3.1.1</b></a></li> 3606 <li><tt>request-target</tt> <a href="#rfc.iref.g.29"><b>3.1.1.2</b></a></li> 3607 <li><tt>RWS</tt> <a href="#rfc.iref.g.38"><b>3.2.1</b></a></li> 3616 3608 <li>SP <a href="#rfc.iref.g.11"><b>1.2</b></a></li> 3617 <li><tt>special</tt> <a href="#rfc.iref.g.43"><b>3.2. 3</b></a></li>3618 <li><tt>start-line</tt> <a href="#rfc.iref.g.2 9"><b>3.1</b></a></li>3619 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.3 4"><b>3.1.2.1</b></a></li>3620 <li><tt>Status-Line</tt> <a href="#rfc.iref.g.3 3"><b>3.1.2</b></a></li>3609 <li><tt>special</tt> <a href="#rfc.iref.g.43"><b>3.2.4</b></a></li> 3610 <li><tt>start-line</tt> <a href="#rfc.iref.g.26"><b>3.1</b></a></li> 3611 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.31"><b>3.1.2.1</b></a></li> 3612 <li><tt>Status-Line</tt> <a href="#rfc.iref.g.30"><b>3.1.2</b></a></li> 3621 3613 <li><tt>t-codings</tt> <a href="#rfc.iref.g.79"><b>8.4</b></a></li> 3622 <li><tt>tchar</tt> <a href="#rfc.iref.g.42"><b>3.2. 3</b></a></li>3614 <li><tt>tchar</tt> <a href="#rfc.iref.g.42"><b>3.2.4</b></a></li> 3623 3615 <li><tt>TE</tt> <a href="#rfc.iref.g.78"><b>8.4</b></a></li> 3624 3616 <li><tt>te-ext</tt> <a href="#rfc.iref.g.81"><b>8.4</b></a></li> 3625 3617 <li><tt>te-params</tt> <a href="#rfc.iref.g.80"><b>8.4</b></a></li> 3626 <li><tt>token</tt> <a href="#rfc.iref.g.41"><b>3.2. 3</b></a></li>3618 <li><tt>token</tt> <a href="#rfc.iref.g.41"><b>3.2.4</b></a></li> 3627 3619 <li><tt>Trailer</tt> <a href="#rfc.iref.g.82"><b>8.5</b></a></li> 3628 3620 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.67"><b>5.1.1</b></a></li> … … 3632 3624 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.54"><b>5.1</b></a></li> 3633 3625 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.84"><b>8.7</b></a></li> 3634 <li><tt>uri-host</tt> <a href="#rfc.iref.g.2 5"><b>2.7</b></a></li>3635 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.1 9"><b>2.7</b></a></li>3626 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3627 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3636 3628 <li><tt>value</tt> <a href="#rfc.iref.g.56"><b>5.1</b></a></li> 3637 3629 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3638 3630 <li><tt>Via</tt> <a href="#rfc.iref.g.85"><b>8.8</b></a></li> 3639 <li><tt>word</tt> <a href="#rfc.iref.g.40"><b>3.2. 3</b></a></li>3631 <li><tt>word</tt> <a href="#rfc.iref.g.40"><b>3.2.4</b></a></li> 3640 3632 </ul> 3641 3633 </li> … … 3647 3639 <li>Header Fields 3648 3640 <ul> 3649 <li>Connection <a href="#rfc.xref.header.connection.1">2. 4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>3641 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3650 3642 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3651 3643 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> … … 3654 3646 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3655 3647 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3656 <li>Via <a href="#rfc.xref.header.via.1">2. 4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>3648 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3657 3649 </ul> 3658 3650 </li> … … 3665 3657 </li> 3666 3658 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 3667 <li>inbound <a href="#rfc.iref.i.2"><b>2. 4</b></a></li>3668 <li>interception proxy <a href="#rfc.iref.i.3"><b>2. 4</b></a></li>3669 <li>intermediary <a href="#rfc.iref.i.1"><b>2. 4</b></a></li>3670 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2. 1</a>, <a href="#ISO-8859-1"><b>12.1</b></a></li>3659 <li>inbound <a href="#rfc.iref.i.2"><b>2.3</b></a></li> 3660 <li>interception proxy <a href="#rfc.iref.i.3"><b>2.3</b></a></li> 3661 <li>intermediary <a href="#rfc.iref.i.1"><b>2.3</b></a></li> 3662 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2.2</a>, <a href="#ISO-8859-1"><b>12.1</b></a></li> 3671 3663 </ul> 3672 3664 </li> … … 3688 3680 <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul> 3689 3681 <li><em>Nie1997</em> <a href="#rfc.xref.Nie1997.1">6.1.1</a>, <a href="#Nie1997"><b>12.2</b></a></li> 3690 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2. 4</b></a></li>3682 <li>non-transforming proxy <a href="#rfc.iref.n.1"><b>2.3</b></a></li> 3691 3683 </ul> 3692 3684 </li> … … 3694 3686 <li>origin form (of request-target) <a href="#rfc.iref.o.3">4.1</a></li> 3695 3687 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3696 <li>outbound <a href="#rfc.iref.o.2"><b>2. 4</b></a></li>3688 <li>outbound <a href="#rfc.iref.o.2"><b>2.3</b></a></li> 3697 3689 </ul> 3698 3690 </li> 3699 3691 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3700 3692 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3701 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.2">2. 4</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1.2</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">4.1</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>3693 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1.2</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">4.1</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3702 3694 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1.1</a></li> 3703 3695 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> … … 3707 3699 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li> 3708 3700 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.12">6.2.3</a></li> 3709 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.2">2. 4</a></li>3701 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.2">2.3</a></li> 3710 3702 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.16">8.7</a></li> 3711 3703 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.18">10.6</a></li> … … 3721 3713 </ul> 3722 3714 </li> 3723 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2. 4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a>, <a href="#rfc.xref.Part6.6">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>3724 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2. 5</a></li>3715 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a>, <a href="#rfc.xref.Part6.6">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul> 3716 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2.4</a></li> 3725 3717 <li><em>Section 2.1</em> <a href="#rfc.xref.Part6.4">3.4</a></li> 3726 3718 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">8.1</a></li> 3727 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1">2. 4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a></li>3719 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a></li> 3728 3720 </ul> 3729 3721 </li> 3730 <li>proxy <a href="#rfc.iref.p.1"><b>2. 4</b></a></li>3722 <li>proxy <a href="#rfc.iref.p.1"><b>2.3</b></a></li> 3731 3723 </ul> 3732 3724 </li> … … 3736 3728 <li>resource <a href="#rfc.iref.r.5"><b>2.7</b></a></li> 3737 3729 <li>response <a href="#rfc.iref.r.3"><b>2.1</b></a></li> 3738 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2. 4</b></a></li>3739 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2. 4</a>, <a href="#RFC1919"><b>12.2</b></a></li>3730 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2.3</b></a></li> 3731 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>12.2</b></a></li> 3740 3732 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li> 3741 3733 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li> … … 3746 3738 </ul> 3747 3739 </li> 3748 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2. 1</a>, <a href="#RFC2047"><b>12.2</b></a></li>3740 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>12.2</b></a></li> 3749 3741 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.1.3</a>, <a href="#rfc.xref.RFC2068.4">6.2.3</a>, <a href="#RFC2068"><b>12.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul> 3750 3742 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.1.3</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li> … … 3763 3755 <li><em>RFC2818</em> <a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>12.2</b></a></li> 3764 3756 <li><em>RFC2965</em> <a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>12.2</b></a></li> 3765 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2. 4</a>, <a href="#RFC3040"><b>12.2</b></a></li>3757 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li> 3766 3758 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li> 3767 3759 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>12.1</b></a><ul> … … 3783 3775 <li><em>RFC4288</em> <a href="#rfc.xref.RFC4288.1">9.3</a>, <a href="#RFC4288"><b>12.2</b></a></li> 3784 3776 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li> 3785 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2. 2</a>, <a href="#RFC4559"><b>12.2</b></a></li>3777 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li> 3786 3778 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul> 3787 3779 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a></li> 3788 3780 </ul> 3789 3781 </li> 3790 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3"> 1.2.1</a>, <a href="#RFC5234"><b>12.1</b></a><ul>3782 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.2.5</a>, <a href="#RFC5234"><b>12.1</b></a><ul> 3791 3783 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> 3792 3784 </ul> … … 3812 3804 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> 3813 3805 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3814 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2. 4</b></a></li>3815 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2. 4</b></a></li>3816 <li>tunnel <a href="#rfc.iref.t.2"><b>2. 4</b></a></li>3806 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.3</b></a></li> 3807 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.3</b></a></li> 3808 <li>tunnel <a href="#rfc.iref.t.2"><b>2.3</b></a></li> 3817 3809 </ul> 3818 3810 </li> 3819 3811 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3820 3812 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3821 <li>upstream <a href="#rfc.iref.u.2"><b>2. 4</b></a></li>3813 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3822 3814 <li>URI scheme 3823 3815 <ul> … … 3826 3818 </ul> 3827 3819 </li> 3828 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2. 1</a>, <a href="#USASCII"><b>12.1</b></a></li>3820 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.2</a>, <a href="#USASCII"><b>12.1</b></a></li> 3829 3821 <li>user agent <a href="#rfc.iref.u.1"><b>2.1</b></a></li> 3830 3822 </ul> 3831 3823 </li> 3832 3824 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3833 <li>Via header field <a href="#rfc.xref.header.via.1">2. 4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>3825 <li>Via header field <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3834 3826 </ul> 3835 3827 </li> -
draft-ietf-httpbis/latest/p2-semantics.html
r1516 r1519 358 358 } 359 359 @bottom-center { 360 content: "Expires July 29, 2012";360 content: "Expires August 1, 2012"; 361 361 } 362 362 @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-p2-semantics-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 6">412 <meta name="dct.issued" scheme="ISO8601" content="2012-01-29"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 414 414 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 441 441 </tr> 442 442 <tr> 443 <td class="left">Expires: July 29, 2012</td>443 <td class="left">Expires: August 1, 2012</td> 444 444 <td class="right">HP</td> 445 445 </tr> … … 494 494 <tr> 495 495 <td class="left"></td> 496 <td class="right">January 2 6, 2012</td>496 <td class="right">January 29, 2012</td> 497 497 </tr> 498 498 </tbody> … … 524 524 in progress”. 525 525 </p> 526 <p>This Internet-Draft will expire on July 29, 2012.</p>526 <p>This Internet-Draft will expire on August 1, 2012.</p> 527 527 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 528 528 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 748 748 </p> 749 749 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 750 <p id="rfc.section.1.2.p.1">This specification uses the A BNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF,with the list rule expanded.750 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 751 751 </p> 752 752 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 757 757 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 758 758 </p> 759 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>760 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>761 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>762 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>763 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>764 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>759 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 760 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 761 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 762 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 763 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 764 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 765 765 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 766 766 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 767 767 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 768 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>768 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 769 769 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 770 770 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>> … … 867 867 with "X-" if they are to be registered (either immediately or in the future). 868 868 </p> 869 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension s defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters869 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 870 870 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 871 871 </p> 872 872 <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 873 873 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 874 quoted-string ABNF production (<a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).874 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 875 875 </p> 876 876 <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 1707 1707 <div id="rfc.iref.s.7"></div> 1708 1708 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1709 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2. 4</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1709 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1710 1710 </p> 1711 1711 <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code … … 3624 3624 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">1.2.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.28">5.1</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.8</a>, <a href="#rfc.xref.Part1.31">6.9</a>, <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.2.4</a>, <a href="#rfc.xref.Part1.35">7.2.6</a>, <a href="#rfc.xref.Part1.36">7.4.19</a>, <a href="#rfc.xref.Part1.37">7.5.6</a>, <a href="#rfc.xref.Part1.38">9.3</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">9.10</a>, <a href="#rfc.xref.Part1.44">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.45">A</a><ul> 3625 3625 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3626 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.19">3.1</a></li>3627 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a></li>3628 3626 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3629 <li><em>Section 2. 4</em> <a href="#rfc.xref.Part1.34">7.2.4</a></li>3627 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.34">7.2.4</a></li> 3630 3628 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.37">7.5.6</a></li> 3631 3629 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.15">1.2.2</a></li> 3632 3630 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.31">6.9</a></li> 3631 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 3633 3632 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.43">9.10</a></li> 3634 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.20">3.1</a></li> 3633 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.20">3.1</a></li> 3634 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.19">3.1</a></li> 3635 3635 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</a></li> 3636 3636 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.28">5.1</a></li> -
draft-ietf-httpbis/latest/p3-payload.html
r1514 r1519 358 358 } 359 359 @bottom-center { 360 content: "Expires July 29, 2012";360 content: "Expires August 1, 2012"; 361 361 } 362 362 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 6">411 <meta name="dct.issued" scheme="ISO8601" content="2012-01-29"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: July 29, 2012</td>437 <td class="left">Expires: August 1, 2012</td> 438 438 <td class="right">J. Mogul</td> 439 439 </tr> … … 492 492 <tr> 493 493 <td class="left"></td> 494 <td class="right">January 2 6, 2012</td>494 <td class="right">January 29, 2012</td> 495 495 </tr> 496 496 </tbody> … … 520 520 in progress”. 521 521 </p> 522 <p>This Internet-Draft will expire on July 29, 2012.</p>522 <p>This Internet-Draft will expire on August 1, 2012.</p> 523 523 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 524 524 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 681 681 </p> 682 682 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 683 <p id="rfc.section.1.3.p.1">This specification uses the A BNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix D</a> shows the collected ABNF,with the list rule expanded.683 <p id="rfc.section.1.3.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix D</a> shows the collected ABNF with the list rule expanded. 684 684 </p> 685 685 <p id="rfc.section.1.3.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 690 690 <p id="rfc.section.1.3.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 691 691 </p> 692 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>693 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>694 <a href="#core.rules" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>692 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 693 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 694 <a href="#core.rules" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 695 695 </pre><h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 696 696 <p id="rfc.section.1.3.2.p.1">The ABNF rules below are defined in other parts:</p> … … 2139 2139 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.3</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">2.2.1</a>, <a href="#rfc.xref.Part1.15">3.1</a>, <a href="#rfc.xref.Part1.16">3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a>, <a href="#rfc.xref.Part1.20">6.7</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">7.2</a>, <a href="#rfc.xref.Part1.24">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.25">A.6</a><ul> 2140 2140 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.3</a></li> 2141 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.3.1</a></li>2142 2141 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 2143 2142 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a></li> 2144 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a></li> 2143 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.3.1</a></li> 2144 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a></li> 2145 2145 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">3.2</a></li> 2146 2146 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">6.7</a></li> -
draft-ietf-httpbis/latest/p4-conditional.html
r1514 r1519 358 358 } 359 359 @bottom-center { 360 content: "Expires July 29, 2012";360 content: "Expires August 1, 2012"; 361 361 } 362 362 @bottom-right { … … 405 405 <meta name="dct.creator" content="Reschke, J. F."> 406 406 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 407 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 6">407 <meta name="dct.issued" scheme="ISO8601" content="2012-01-29"> 408 408 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 409 409 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 431 431 </tr> 432 432 <tr> 433 <td class="left">Expires: July 29, 2012</td>433 <td class="left">Expires: August 1, 2012</td> 434 434 <td class="right">J. Mogul</td> 435 435 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">January 2 6, 2012</td>490 <td class="right">January 29, 2012</td> 491 491 </tr> 492 492 </tbody> … … 518 518 in progress”. 519 519 </p> 520 <p>This Internet-Draft will expire on July 29, 2012.</p>520 <p>This Internet-Draft will expire on August 1, 2012.</p> 521 521 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 522 522 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 647 647 </p> 648 648 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 649 <p id="rfc.section.1.2.p.1">This specification uses the A BNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF,with the list rule expanded.649 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 650 650 </p> 651 651 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 655 655 <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 656 656 </p> 657 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>658 <a href="#notation" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>657 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 658 <a href="#notation" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 659 659 <a href="#notation" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>> 660 660 </pre><div id="rfc.iref.m.1"></div> … … 1521 1521 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">1.2</a>, <a href="#rfc.xref.Part1.6">2.3.3</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1522 1522 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 1523 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2</a></li>1524 1523 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 1525 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.2</a></li> 1524 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.2</a></li> 1525 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.2</a></li> 1526 1526 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.6">2.3.3</a></li> 1527 1527 <li><em>Section 11</em> <a href="#rfc.xref.Part1.8">7</a></li> -
draft-ietf-httpbis/latest/p5-range.html
r1504 r1519 358 358 } 359 359 @bottom-center { 360 content: "Expires July 7, 2012";360 content: "Expires August 1, 2012"; 361 361 } 362 362 @bottom-right { … … 407 407 <meta name="dct.creator" content="Reschke, J. F."> 408 408 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 409 <meta name="dct.issued" scheme="ISO8601" content="2012-01- 04">409 <meta name="dct.issued" scheme="ISO8601" content="2012-01-29"> 410 410 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 411 411 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 433 433 </tr> 434 434 <tr> 435 <td class="left">Expires: July 7, 2012</td>435 <td class="left">Expires: August 1, 2012</td> 436 436 <td class="right">J. Mogul</td> 437 437 </tr> … … 490 490 <tr> 491 491 <td class="left"></td> 492 <td class="right">January 4, 2012</td>492 <td class="right">January 29, 2012</td> 493 493 </tr> 494 494 </tbody> … … 518 518 in progress”. 519 519 </p> 520 <p>This Internet-Draft will expire on July 7, 2012.</p>520 <p>This Internet-Draft will expire on August 1, 2012.</p> 521 521 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 522 522 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 648 648 </p> 649 649 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 650 <p id="rfc.section.1.2.p.1">This specification uses the A BNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF,with the list rule expanded.650 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF with the list rule expanded. 651 651 </p> 652 652 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 659 659 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 660 660 </p> 661 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>662 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>661 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 662 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 663 663 <a href="#core.rules" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>> 664 664 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> … … 1515 1515 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">8</a>, <a href="#Part1"><b>9.1</b></a><ul> 1516 1516 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 1517 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2.1</a></li>1518 1517 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 1519 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.2.1</a></li> 1518 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.2.1</a></li> 1519 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.2.1</a></li> 1520 1520 <li><em>Section 11</em> <a href="#rfc.xref.Part1.6">8</a></li> 1521 1521 </ul> -
draft-ietf-httpbis/latest/p6-cache.html
r1514 r1519 361 361 } 362 362 @bottom-center { 363 content: "Expires July 29, 2012";363 content: "Expires August 1, 2012"; 364 364 } 365 365 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 6">411 <meta name="dct.issued" scheme="ISO8601" content="2012-01-29"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: July 29, 2012</td>437 <td class="left">Expires: August 1, 2012</td> 438 438 <td class="right">J. Mogul</td> 439 439 </tr> … … 500 500 <tr> 501 501 <td class="left"></td> 502 <td class="right">January 2 6, 2012</td>502 <td class="right">January 29, 2012</td> 503 503 </tr> 504 504 </tbody> … … 530 530 in progress”. 531 531 </p> 532 <p>This Internet-Draft will expire on July 29, 2012.</p>532 <p>This Internet-Draft will expire on August 1, 2012.</p> 533 533 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 534 534 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 760 760 </p> 761 761 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 762 <p id="rfc.section.1.4.p.1">This specification uses the A BNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF,with the list rule expanded.762 <p id="rfc.section.1.4.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 763 763 </p> 764 764 <p id="rfc.section.1.4.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 769 769 <p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 770 770 </p> 771 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>772 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>773 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>771 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 772 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 773 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 774 774 </pre><h3 id="rfc.section.1.4.2"><a href="#rfc.section.1.4.2">1.4.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 775 775 <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p> … … 2343 2343 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.7</a>, <a href="#rfc.xref.Part1.17">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 2344 2344 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.4</a></li> 2345 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.4.1</a></li>2346 2345 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.3</a></li> 2347 2346 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a></li> 2347 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.4.1</a></li> 2348 2348 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.16">2.7</a></li> 2349 <li><em>Section 3.2. 3</em> <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a></li>2349 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a></li> 2350 2350 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li> 2351 2351 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.9">1.4.2</a></li> -
draft-ietf-httpbis/latest/p7-auth.html
r1504 r1519 358 358 } 359 359 @bottom-center { 360 content: "Expires July 7, 2012";360 content: "Expires August 1, 2012"; 361 361 } 362 362 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2012-01- 04">406 <meta name="dct.issued" scheme="ISO8601" content="2012-01-29"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: July 7, 2012</td>437 <td class="left">Expires: August 1, 2012</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">January 4, 2012</td>490 <td class="right">January 29, 2012</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on July 7, 2012.</p>518 <p>This Internet-Draft will expire on August 1, 2012.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 633 633 </p> 634 634 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 635 <p id="rfc.section.1.2.p.1">This specification uses the A BNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF,with the list rule expanded.635 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 636 636 </p> 637 637 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 642 642 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 643 643 </p> 644 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>645 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# basic.rules" title="Basic Rules">Section 1.2.2</a>>646 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>647 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field. rules" title="Common Field ABNF Rules">Section 3.2.3</a>>644 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 645 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 646 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 647 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 648 648 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="access.authentication.framework" href="#access.authentication.framework">Access Authentication Framework</a></h1> 649 649 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="challenge.and.response" href="#challenge.and.response">Challenge and Response</a></h2> … … 739 739 <ul> 740 740 <li> 741 <p> Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep742 their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over743 which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).741 <p>HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request <em class="bcp14">MUST</em> be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or 742 bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken 743 to ensure that the connection cannot be used by any party other than the authenticated user (see <a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 744 744 </p> 745 745 </li> … … 1272 1272 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">2.2</a>, <a href="#rfc.xref.Part1.9">2.3.1</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a>, <a href="#rfc.xref.Part1.12">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1273 1273 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 1274 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a></li>1275 1274 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 1276 <li><em>Section 2.2</em> <a href="#rfc.xref.Part1.9">2.3.1</a></li> 1277 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 1275 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.9">2.3.1</a></li> 1276 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a></li> 1277 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 1278 1278 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.8">2.2</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a></li> 1279 1279 <li><em>Section 11</em> <a href="#rfc.xref.Part1.12">7</a></li>
Note: See TracChangeset
for help on using the changeset viewer.