Changeset 395
- Timestamp:
- 15/11/08 07:49:55 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r392 r395 476 476 <tr> 477 477 <td class="header left"></td> 478 <td class="header right">November 1 5, 2008</td>478 <td class="header right">November 14, 2008</td> 479 479 </tr> 480 480 </table> … … 707 707 <div id="rfc.iref.g.11"></div> 708 708 <div id="rfc.iref.g.12"></div> 709 <div id="rfc.iref.g.13"></div>710 709 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 711 710 <div id="core.rules"> 712 <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>. 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#section-B.1">Appendix B.1</a>: ALPHA (letters), CHAR (any <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character, excluding NUL), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 713 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space) and 714 WSP (white space). 711 <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>. 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#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG 712 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character), and WSP (white space). 715 713 </p> 716 714 </div> … … 737 735 </div> 738 736 <div id="rule.LWS"> 739 <p id="rfc.section.1.2.2.p.2">All linear white space (LWS) in header field-values has the same semantics as SP. A recipient <em class="bcp14">MAY</em> replace any such linear white space with a single SP before interpreting the field value or forwarding the message downstream. 737 <p id="rfc.section.1.2.2.p.2">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), 738 and BWS ("bad" whitespace). 740 739 </p> 741 740 </div> 742 <p id="rfc.section.1.2.2.p.3">Historically, HTTP/1.1 header field values allow linear white space folding across multiple lines. However, this specification 743 deprecates its use; senders <em class="bcp14">MUST NOT</em> produce messages that include LWS folding (i.e., use the obs-fold rule), except within the message/http media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a>). Receivers <em class="bcp14">SHOULD</em> still parse folded linear white space. 744 </p> 745 <p id="rfc.section.1.2.2.p.4">This specification uses three rules to denote the use of linear white space; BWS ("Bad" White Space), OWS (Optional White 746 Space), and RWS (Required White Space). 747 </p> 748 <p id="rfc.section.1.2.2.p.5">"Bad" white space is allowed by the BNF, but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. Receivers <em class="bcp14">MUST</em> accept it in incoming messages. 749 </p> 750 <p id="rfc.section.1.2.2.p.6">Required white space is used when at least one linear white space character is required to separate field tokens. In all such 751 cases, a single SP character <em class="bcp14">SHOULD</em> be used. 741 <p id="rfc.section.1.2.2.p.3">The OWS rule is used where zero or more linear white space characters may appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP character. Multiple OWS characters that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream. 742 </p> 743 <p id="rfc.section.1.2.2.p.4">RWS is used when at least one linear white space character is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP character. Multiple RWS characters that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream. 744 </p> 745 <p id="rfc.section.1.2.2.p.5">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. 752 746 </p> 753 747 <div id="rule.whitespace"> 754 <p id="rfc.section.1.2.2.p. 7"> </p>748 <p id="rfc.section.1.2.2.p.6"> </p> 755 749 </div> 756 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1 4"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> )750 <div id="rfc.figure.u.3"></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> = *( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> ) 757 751 ; "optional" white space 758 752 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> ) … … 761 755 ; "bad" white space 762 756 <a href="#rule.whitespace" class="smpl">obs-fold</a> = <a href="#core.rules" class="smpl">CRLF</a> 763 </pre><div id="rule.TEXT"> 764 <p id="rfc.section.1.2.2.p.9"> The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message 765 parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than 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> only when encoded according to the rules 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>. 757 </pre><div id="rule.token.separators"> 758 <p id="rfc.section.1.2.2.p.8"> Many HTTP/1.1 header field values consist of words separated by whitespace or special characters. 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 3.3</a>). 766 759 </p> 767 760 </div> 768 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.17"></span> <a href="#rule.TEXT" class="smpl">TEXT</a> = %x20-7E / %x80-FF / <a href="#rule.whitespace" class="smpl">OWS</a> 769 ; any <a href="#core.rules" class="smpl">OCTET</a> except <a href="#core.rules" class="smpl">CTL</a>s, but including <a href="#rule.whitespace" class="smpl">OWS</a> 770 </pre><p id="rfc.section.1.2.2.p.11">A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS 771 will be replaced with a single SP before interpretation of the TEXT value. 772 </p> 773 <div id="rule.token.separators"> 774 <p id="rfc.section.1.2.2.p.12"> Many HTTP/1.1 header field values consist of words separated by LWS or special characters. 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 3.3</a>). 775 </p> 776 </div> 777 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#rule.token.separators" class="smpl">tchar</a> = "!" / "#" / "$" / "%" / "&" / "'" / "*" 761 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#rule.token.separators" class="smpl">tchar</a> = "!" / "#" / "$" / "%" / "&" / "'" / "*" 778 762 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 779 763 / <a href="#core.rules" class="smpl">DIGIT</a> / <a href="#core.rules" class="smpl">ALPHA</a> 780 764 781 765 <a href="#rule.token.separators" class="smpl">token</a> = 1*<a href="#rule.token.separators" class="smpl">tchar</a> 782 </pre><div id="rule.comment"> 783 <p id="rfc.section.1.2.2.p.14"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed 784 in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part 785 of the field value. 766 </pre><div id="rule.quoted-string"> 767 <p id="rfc.section.1.2.2.p.10"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 768 </div> 769 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></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> 770 <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> ) 771 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF 772 </pre><div id="rule.quoted-pair"> 773 <p id="rfc.section.1.2.2.p.12"> The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs. 786 774 </p> 787 775 </div> 788 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 789 <a href="#rule.comment" class="smpl">ctext</a> = <any <a href="#rule.TEXT" class="smpl">TEXT</a> excluding "(" and ")"> 790 </pre><div id="rule.quoted-string"> 791 <p id="rfc.section.1.2.2.p.16"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 792 </div> 793 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></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> 794 <a href="#rule.quoted-string" class="smpl">qdtext</a> = <any <a href="#rule.TEXT" class="smpl">TEXT</a> excluding <a href="#core.rules" class="smpl">DQUOTE</a> and "\"> 795 </pre><div id="rule.quoted-pair"> 796 <p id="rfc.section.1.2.2.p.18"> The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs. 797 </p> 798 </div> 799 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#rule.quoted-pair" class="smpl">quoted-text</a> = %x01-09 / 776 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#rule.quoted-pair" class="smpl">quoted-text</a> = %x01-09 / 800 777 %x0B-0C / 801 778 %x0E-FF ; Characters excluding NUL, <a href="#core.rules" class="smpl">CR</a> and <a href="#core.rules" class="smpl">LF</a> … … 803 780 </pre><h3 id="rfc.section.1.2.3"><a href="#rfc.section.1.2.3">1.2.3</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 804 781 <p id="rfc.section.1.2.3.p.1">The ABNF rules below are defined in other parts:</p> 805 <div id="rfc.figure.u. 9"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">request-header</a> = <request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>>782 <div id="rfc.figure.u.7"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">request-header</a> = <request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>> 806 783 <a href="#abnf.dependencies" class="smpl">response-header</a> = <response-header, 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#response.header.fields" title="Response Header Fields">Section 6</a>> 807 </pre><div id="rfc.figure.u. 10"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">accept-params</a> = <accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>>784 </pre><div id="rfc.figure.u.8"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">accept-params</a> = <accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> 808 785 <a href="#abnf.dependencies" class="smpl">entity-body</a> = <entity-body, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.body" title="Entity Body">Section 4.2</a>> 809 786 <a href="#abnf.dependencies" class="smpl">entity-header</a> = <entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>> 810 </pre><div id="rfc.figure.u. 11"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>>787 </pre><div id="rfc.figure.u.9"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>> 811 788 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>> 812 789 <a href="#abnf.dependencies" class="smpl">Warning</a> = <Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>> … … 824 801 "path-abempty", "path-absolute", "query", and "authority" from <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 without a fragment. 825 802 </p> 826 <div id="rfc.figure.u.1 2"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#uri" class="smpl">URI</a> = <URI, 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-3">Section 3</a>>803 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span> <a href="#uri" class="smpl">URI</a> = <URI, 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-3">Section 3</a>> 827 804 <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, 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.1">Section 4.1</a>> 828 805 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, 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.3">Section 4.3</a>> … … 848 825 for identifiers using the http or https URI schemes. 849 826 </p> 850 <div id="rfc.figure.u.1 3"></div><pre class="inline"><span id="rfc.iref.g.33"></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> ]827 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.30"></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> ] 851 828 </pre><p id="rfc.section.2.1.1.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server 852 829 listening for TCP connections on that port of that host, and the request-target for the resource is path-absolute (<a href="#request-target" title="request-target">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a request-target for a resource (<a href="#request-target" title="request-target">Section 5.1.2</a>). If a proxy receives a host name which 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. … … 870 847 </p> 871 848 <p id="rfc.section.2.1.2.p.3">For example, the following three URIs are equivalent:</p> 872 <div id="rfc.figure.u.1 4"></div><pre class="text"> http://example.com:80/~smith/home.html849 <div id="rfc.figure.u.12"></div><pre class="text"> http://example.com:80/~smith/home.html 873 850 http://EXAMPLE.com/%7Esmith/home.html 874 851 http://EXAMPLE.com:/%7esmith/home.html … … 885 862 server (O). 886 863 </p> 887 <div id="rfc.figure.u.1 5"></div><pre class="drawing"> request chain ------------------------>864 <div id="rfc.figure.u.13"></div><pre class="drawing"> request chain ------------------------> 888 865 UA -------------------v------------------- O 889 866 <----------------------- response chain … … 896 873 cannot understand the contents of the messages. 897 874 </p> 898 <div id="rfc.figure.u.1 6"></div><pre class="drawing"> request chain -------------------------------------->875 <div id="rfc.figure.u.14"></div><pre class="drawing"> request chain --------------------------------------> 899 876 UA -----v----- A -----v----- B -----v----- C -----v----- O 900 877 <------------------------------------- response chain … … 911 888 O (via C) for a request which has not been cached by UA or A. 912 889 </p> 913 <div id="rfc.figure.u.1 7"></div><pre class="drawing"> request chain ---------->890 <div id="rfc.figure.u.15"></div><pre class="drawing"> request chain ----------> 914 891 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 915 892 <--------- response chain … … 952 929 </p> 953 930 <p id="rfc.section.3.1.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> 954 <div id="rfc.figure.u.1 8"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>931 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a> 955 932 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 956 933 </pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. … … 976 953 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="full.date" href="#full.date">Full Date</a></h3> 977 954 <p id="rfc.section.3.2.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p> 978 <div id="rfc.figure.u.1 9"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123955 <div id="rfc.figure.u.17"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 979 956 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 980 957 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format … … 989 966 <p id="rfc.section.3.2.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 990 967 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for 991 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional LWSbeyond that specifically included as SP in the grammar.992 </p> 993 <div id="rfc.figure.u. 20"></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><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><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span> <a href="#full.date" class="smpl">HTTP-date</a> = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a>968 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. 969 </p> 970 <div id="rfc.figure.u.18"></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><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><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><span id="rfc.iref.g.44"></span> <a href="#full.date" class="smpl">HTTP-date</a> = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a> 994 971 <a href="#full.date" class="smpl">obsolete-date</a> = <a href="#full.date" class="smpl">rfc850-date</a> / <a href="#full.date" class="smpl">asctime-date</a> 995 972 <a href="#full.date" class="smpl">rfc1123-date</a> = <a href="#full.date" class="smpl">wkday</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> time <a href="#core.rules" class="smpl">SP</a> GMT … … 1050 1027 is a property of the message, not of the original entity. 1051 1028 </p> 1052 <div id="rfc.figure.u. 21"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>1029 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1053 1030 <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="#transfer.codings" class="smpl">parameter</a> ) 1054 1031 </pre><div id="rule.parameter"> 1055 1032 <p id="rfc.section.3.3.p.3"> Parameters are in the form of attribute/value pairs.</p> 1056 1033 </div> 1057 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#transfer.codings" class="smpl">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>1034 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#transfer.codings" class="smpl">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> 1058 1035 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1059 1036 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> … … 1080 1057 necessary for the recipient to verify that it has received the full message. 1081 1058 </p> 1082 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.53"></span><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><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span> <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>1059 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span><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="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a> 1083 1060 <a href="#chunked.transfer.encoding" class="smpl">last-chunk</a> 1084 1061 <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a> … … 1118 1095 </p> 1119 1096 <p id="rfc.section.3.3.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1120 <div id="rfc.figure.u.2 4"></div><pre class="text"> length := 01097 <div id="rfc.figure.u.22"></div><pre class="text"> length := 0 1121 1098 read chunk-size, chunk-ext (if any) and CRLF 1122 1099 while (chunk-size > 0) { … … 1140 1117 space. By convention, the products are listed in order of their significance for identifying the application. 1141 1118 </p> 1142 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></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>]1119 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></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>] 1143 1120 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1144 1121 </pre><p id="rfc.section.3.4.p.3">Examples:</p> 1145 <div id="rfc.figure.u.2 6"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31122 <div id="rfc.figure.u.24"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1146 1123 Server: Apache/0.8.4 1147 1124 </pre><p id="rfc.section.3.4.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 character <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). … … 1150 1127 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="message.types" href="#message.types">Message Types</a></h2> 1151 1128 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1152 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.64"></span> <a href="#message.types" class="smpl">HTTP-message</a> = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a> ; HTTP/1.1 messages1129 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.61"></span> <a href="#message.types" class="smpl">HTTP-message</a> = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a> ; HTTP/1.1 messages 1153 1130 </pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section 5</a>) and Response (<a href="#response" title="Response">Section 6</a>) messages use the generic message format of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header 1154 1131 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1155 1132 fields, and possibly a message-body. 1156 1133 </p> 1157 <div id="rfc.figure.u.2 8"></div><pre class="inline"><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span> <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a>1134 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span> <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a> 1158 1135 *(<a href="#message.headers" class="smpl">message-header</a> <a href="#core.rules" class="smpl">CRLF</a>) 1159 1136 <a href="#core.rules" class="smpl">CRLF</a> … … 1166 1143 by the BNF, an HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. 1167 1144 </p> 1145 <p id="rfc.section.4.1.p.7">Whitespace (WSP) <em class="bcp14">MUST NOT</em> be sent between the start-line and the first header field. The presence of whitespace might be an attempt to trick a noncompliant 1146 implementation of HTTP into ignoring that field or processing the next line as a new request, either of which may result in 1147 security issues when implementations within the request chain interpret the same message differently. HTTP/1.1 servers <em class="bcp14">MUST</em> reject such a message with a 400 (Bad Request) response. 1148 </p> 1168 1149 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2> 1169 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The 1170 field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding 1171 each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated, 1172 when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common 1173 forms. 1174 </p> 1175 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span> <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" [ <a href="#message.headers" class="smpl">field-value</a> ] 1150 <p id="rfc.section.4.2.p.1">HTTP header fields follow the same general format as Internet messages in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":"), optional whitespace, and the field value. Field names are 1151 case-insensitive. 1152 </p> 1153 <div id="rfc.figure.u.27"></div><pre class="inline"><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> <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" OWS [ <a href="#message.headers" class="smpl">field-value</a> ] OWS 1176 1154 <a href="#message.headers" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1177 1155 <a href="#message.headers" class="smpl">field-value</a> = *( <a href="#message.headers" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> ) 1178 <a href="#message.headers" class="smpl">field-content</a> = <field content> 1179 </pre><p id="rfc.section.4.2.p.3"> <span class="comment">[rfc.comment.1: whitespace between field-name and colon is an error and MUST NOT be accepted]</span> 1180 </p> 1181 <p id="rfc.section.4.2.p.4">The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace 1182 character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS <em class="bcp14">MAY</em> be removed without changing the semantics of the field value. Any LWS that occurs between field-content <em class="bcp14">MAY</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream. 1183 </p> 1184 <p id="rfc.section.4.2.p.5">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1156 <a href="#message.headers" class="smpl">field-content</a> = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1157 </pre><p id="rfc.section.4.2.p.3">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 (allowing other character sets 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 charset <a href="#USASCII" id="rfc.xref.USASCII.2"><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> constrain their field-values to US-ASCII characters. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field-content as opaque data. 1158 </p> 1159 <p id="rfc.section.4.2.p.4">No whitespace is allowed between the header field-name and colon. For security reasons, any request message received containing 1160 such whitespace <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request) and any such whitespace in a response message <em class="bcp14">MUST</em> be removed. 1161 </p> 1162 <p id="rfc.section.4.2.p.5">The field value <em class="bcp14">MAY</em> be preceded by optional white space; a single SP is preferred. The field-value does not include any leading or trailing white 1163 space: OWS occurring before the first non-whitespace character of the field-value or after the last non-whitespace character 1164 of the field-value is ignored and <em class="bcp14">MAY</em> be removed without changing the meaning of the header field. 1165 </p> 1166 <p id="rfc.section.4.2.p.6">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1167 space or horizontal tab character (line folding). This specification deprecates such line folding except within the message/http 1168 media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a>). HTTP/1.1 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 1169 message is intended for packaging within the message/http media type. HTTP/1.1 recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with a single SP prior to interpreting the field value or 1170 forwarding the message downstream. 1171 </p> 1172 <div id="rule.comment"> 1173 <p id="rfc.section.4.2.p.7"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed 1174 in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part 1175 of the field value. 1176 </p> 1177 </div> 1178 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1179 <a href="#rule.comment" class="smpl">ctext</a> = *( <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1180 </pre><p id="rfc.section.4.2.p.9">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1185 1181 to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header 1186 1182 fields. 1187 1183 </p> 1188 <p id="rfc.section.4.2.p. 6">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e.,1184 <p id="rfc.section.4.2.p.10">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., 1189 1185 #(values)]. It <em class="bcp14">MUST</em> be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics 1190 1186 of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header … … 1192 1188 thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded. 1193 1189 </p> 1194 <p id="rfc.section.4.2.p. 7"> </p>1190 <p id="rfc.section.4.2.p.11"> </p> 1195 1191 <dl class="empty"> 1196 1192 <dd> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix … … 1203 1199 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.7</a>). 1204 1200 </p> 1205 <div id="rfc.figure.u. 30"></div><pre class="inline"><span id="rfc.iref.g.71"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>1201 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.70"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a> 1206 1202 / <entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>> 1207 1203 </pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding … … 1210 1206 <p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p> 1211 1207 <p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field 1212 in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length1208 in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length 1213 1209 and a method that does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented 1214 1210 the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response. … … 1271 1267 to the entity being transferred. These header fields apply only to the message being transmitted. 1272 1268 </p> 1273 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.72"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>1269 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.71"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a> 1274 1270 / <a href="#header.connection" class="smpl">Connection</a> ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1275 1271 / <a href="#header.date" class="smpl">Date</a> ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> … … 1288 1284 resource, the identifier of the resource, and the protocol version in use. 1289 1285 </p> 1290 <div id="rfc.figure.u.3 2"></div><pre class="inline"><span id="rfc.iref.g.73"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 5.1</a>1286 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.72"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 5.1</a> 1291 1287 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1292 / <a href="#abnf.dependencies" class="smpl">request-header</a> ; <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>1293 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1288 / <a href="#abnf.dependencies" class="smpl">request-header</a> ; <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> 1289 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1294 1290 <a href="#core.rules" class="smpl">CRLF</a> 1295 1291 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1298 1294 The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1299 1295 </p> 1300 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.74"></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>1296 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.73"></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> 1301 1297 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="method" href="#method">Method</a></h3> 1302 1298 <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p> 1303 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a>1299 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1304 1300 </pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1305 1301 <p id="rfc.section.5.1.2.p.1">The request-target is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section 2.1</a>) and identifies the resource upon which to apply the request. 1306 1302 </p> 1307 <div id="rfc.figure.u.3 5"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#request-target" class="smpl">request-target</a> = "*"1303 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1308 1304 / <a href="#uri" class="smpl">absolute-URI</a> 1309 1305 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) … … 1313 1309 apply to a resource. One example would be 1314 1310 </p> 1315 <div id="rfc.figure.u.3 6"></div><pre class="text"> OPTIONS * HTTP/1.11311 <div id="rfc.figure.u.35"></div><pre class="text"> OPTIONS * HTTP/1.1 1316 1312 </pre><p id="rfc.section.5.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, 1317 1313 and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request … … 1319 1315 Request-Line would be: 1320 1316 </p> 1321 <div id="rfc.figure.u.3 7"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11317 <div id="rfc.figure.u.36"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1322 1318 </pre><p id="rfc.section.5.1.2.p.7">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. 1323 1319 </p> 1324 <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1320 <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1325 1321 </p> 1326 1322 <p id="rfc.section.5.1.2.p.9">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the … … 1328 1324 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1329 1325 </p> 1330 <div id="rfc.figure.u.3 8"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.11326 <div id="rfc.figure.u.37"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1 1331 1327 Host: www.example.org 1332 1328 </pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original … … 1346 1342 </dl> 1347 1343 <p id="rfc.section.5.1.2.p.15">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI too long) status if the received request-target 1348 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1344 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1349 1345 </p> 1350 1346 <p id="rfc.section.5.1.2.p.16">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs. … … 1373 1369 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1> 1374 1370 <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1375 <div id="rfc.figure.u.3 9"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 6.1</a>1371 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 6.1</a> 1376 1372 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1377 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>1378 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3. 10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1373 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> 1374 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1379 1375 <a href="#core.rules" class="smpl">CRLF</a> 1380 1376 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1384 1380 CRLF sequence. 1385 1381 </p> 1386 <div id="rfc.figure.u. 40"></div><pre class="inline"><span id="rfc.iref.g.79"></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.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1382 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.78"></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.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1387 1383 </pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1388 1384 <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes 1389 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2. 10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,1385 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1390 1386 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1391 1387 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. … … 1401 1397 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1402 1398 </ul> 1403 <div id="rfc.figure.u.4 1"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1404 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = * <<a href="#rule.TEXT" class="smpl">TEXT</a>, excluding <a href="#core.rules" class="smpl">CR</a>, <a href="#core.rules" class="smpl">LF</a>>1399 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1400 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1405 1401 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1> 1406 1402 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> … … 1457 1453 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1458 1454 </p> 1459 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1455 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1460 1456 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request. 1461 1457 </p> … … 1482 1478 </p> 1483 1479 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1484 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding1480 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1485 1481 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1486 1482 </p> … … 1500 1496 </p> 1501 1497 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 1502 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing1498 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 1503 1499 to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either 1504 1500 be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking … … 1507 1503 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1508 1504 <ul> 1509 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.1510 </li> 1511 <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.1505 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1506 </li> 1507 <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 1512 1508 </li> 1513 1509 </ul> … … 1553 1549 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 1554 1550 an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding 1555 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1551 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1556 1552 </li> 1557 1553 </ul> … … 1593 1589 </p> 1594 1590 <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p> 1595 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>1591 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1596 1592 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1597 1593 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1606 1602 of the response. For example, 1607 1603 </p> 1608 <div id="rfc.figure.u.4 3"></div><pre class="text"> Connection: close1604 <div id="rfc.figure.u.42"></div><pre class="text"> Connection: close 1609 1605 </pre><p id="rfc.section.8.1.p.8">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 7.1</a>) after the current request/response is complete. 1610 1606 </p> … … 1622 1618 or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. 1623 1619 </p> 1624 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>1620 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1625 1621 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1626 1622 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1627 <div id="rfc.figure.u.4 5"></div><pre class="text"> Content-Length: 34951623 <div id="rfc.figure.u.44"></div><pre class="text"> Content-Length: 3495 1628 1624 </pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 4.4</a>. 1629 1625 </p> … … 1640 1636 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 3.2.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1641 1637 </p> 1642 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>1638 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1643 1639 <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a> 1644 1640 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1645 <div id="rfc.figure.u.4 7"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT1641 <div id="rfc.figure.u.46"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1646 1642 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1647 1643 </p> … … 1679 1675 a single IP address. 1680 1676 </p> 1681 <div id="rfc.figure.u.4 8"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>1677 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 1682 1678 <a href="#header.host" class="smpl">Host-v</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.1.1</a> 1683 1679 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1684 1680 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1685 1681 </p> 1686 <div id="rfc.figure.u.4 9"></div><pre class="text"> GET /pub/WWW/ HTTP/1.11682 <div id="rfc.figure.u.48"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1687 1683 Host: www.example.org 1688 1684 </pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name … … 1699 1695 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>). 1700 1696 </p> 1701 <div id="rfc.figure.u. 50"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>1697 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 1702 1698 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 1703 1699 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#abnf.dependencies" class="smpl">accept-params</a> ] ) … … 1706 1702 </p> 1707 1703 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1708 <div id="rfc.figure.u.5 1"></div><pre class="text"> TE: deflate1704 <div id="rfc.figure.u.50"></div><pre class="text"> TE: deflate 1709 1705 TE: 1710 1706 TE: trailers, deflate;q=0.5 … … 1725 1721 <li> 1726 1722 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1727 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.1 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")1723 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.") 1728 1724 </p> 1729 1725 </li> … … 1743 1739 chunked transfer-coding. 1744 1740 </p> 1745 <div id="rfc.figure.u.5 2"></div><pre class="inline"><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>1741 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 1746 1742 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a> 1747 1743 </pre><p id="rfc.section.8.6.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 … … 1764 1760 transfer-coding is a property of the message, not of the entity. 1765 1761 </p> 1766 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>1762 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1767 1763 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 1768 1764 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1769 1765 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>. An example is: 1770 1766 </p> 1771 <div id="rfc.figure.u.5 4"></div><pre class="text"> Transfer-Encoding: chunked1767 <div id="rfc.figure.u.53"></div><pre class="text"> Transfer-Encoding: chunked 1772 1768 </pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to an entity, 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 entity-header fields not defined by this specification. 1773 1769 </p> … … 1779 1775 to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. 1780 1776 </p> 1781 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>1777 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 1782 1778 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 1783 1779 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1784 <div id="rfc.figure.u.5 6"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x111780 <div id="rfc.figure.u.55"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1785 1781 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 1786 1782 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 1811 1807 of all senders along the request/response chain. 1812 1808 </p> 1813 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>1809 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 1814 1810 <a href="#header.via" class="smpl">Via-v</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> 1815 1811 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 1836 1832 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1837 1833 </p> 1838 <div id="rfc.figure.u.5 8"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)1834 <div id="rfc.figure.u.57"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1839 1835 </pre><p id="rfc.section.8.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1840 1836 </p> … … 1842 1838 For example, 1843 1839 </p> 1844 <div id="rfc.figure.u.5 9"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy1840 <div id="rfc.figure.u.58"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1845 1841 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1846 <div id="rfc.figure.u. 60"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy1842 <div id="rfc.figure.u.59"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1847 1843 </pre><p id="rfc.section.8.9.p.14">Applications <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 1848 1844 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2346 2342 can be interpreted unambiguously. 2347 2343 </p> 2348 <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of SP or HTABcharacters between fields, even though only a single SP is required.2344 <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required. 2349 2345 </p> 2350 2346 <p id="rfc.section.A.p.3">The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing … … 2352 2348 </p> 2353 2349 <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling 2354 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.1 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2350 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2355 2351 </p> 2356 2352 <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 2444 2440 <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2445 2441 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2446 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.1 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)2442 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) 2447 2443 </p> 2448 2444 <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 … … 2457 2453 <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 2458 2454 <p id="rfc.section.B.4.p.1">Rules about implicit linear white space between certain grammar productions have been removed; now it's only allowed when 2459 specifically pointed out in the ABNF. The CHAR rule does not allow the NUL character anymore (this affects the comment and2460 quoted-string rules). Furthermore, the quoted-pair rule does not allow escaping NUL, CR or LF anymore. (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>)2455 specifically pointed out in the ABNF. The NUL character is no longer allowed in comment and quoted-string text. The quoted-pair 2456 rule no longer allows escaping NUL, CR or LF. (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>) 2461 2457 </p> 2462 2458 <p id="rfc.section.B.4.p.2">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section 3.1</a>) … … 2506 2502 <dl class="empty"> 2507 2503 <dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of 2508 entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2504 entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2509 2505 </dd> 2510 2506 </dl> … … 2512 2508 </p> 2513 2509 <dl class="empty"> 2514 <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.2510 <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status. 2515 2511 </dd> 2516 2512 </dl> … … 2518 2514 </p> 2519 2515 <dl class="empty"> 2520 <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1 6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).2516 <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses). 2521 2517 </dd> 2522 2518 </dl> … … 2565 2561 </dd> 2566 2562 </dl> 2567 <p id="rfc.section.C.p.16"> <span id="rfc.iref.g.10 8"></span> <dfn>gateway</dfn>2563 <p id="rfc.section.C.p.16"> <span id="rfc.iref.g.107"></span> <dfn>gateway</dfn> 2568 2564 </p> 2569 2565 <dl class="empty"> … … 2659 2655 <ul> 2660 2656 <li>Update media type registrations to use RFC4288 template.</li> 2661 <li>Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF for chunk-data (work in progress on <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>)2657 <li>Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF for chunk-data (work in progress on <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>) 2662 2658 </li> 2663 2659 </ul> … … 2683 2679 -- these will have to be updated when switching over to RFC3986. 2684 2680 </li> 2685 <li>Synchronize core rules with RFC5234 (this includes a change to CHAR which now excludes NUL).</li>2681 <li>Synchronize core rules with RFC5234.</li> 2686 2682 <li>Get rid of prose rules that span multiple lines.</li> 2687 2683 <li>Get rid of unused rules LOALPHA and UPALPHA.</li> … … 2812 2808 </li> 2813 2809 <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"> 2814 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.10 8">C</a></li>2810 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.107">C</a></li> 2815 2811 <li class="indline1"><tt>Grammar</tt> 2816 2812 <ul class="ind"> 2817 <li class="indline1"><tt>absolute-URI</tt> <a class="iref" href="#rfc.iref.g.2 7"><b>2.1</b></a></li>2813 <li class="indline1"><tt>absolute-URI</tt> <a class="iref" href="#rfc.iref.g.24"><b>2.1</b></a></li> 2818 2814 <li class="indline1">ALPHA <a class="iref" href="#rfc.iref.g.1"><b>1.2</b></a></li> 2819 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g.40"><b>3.2.1</b></a></li> 2820 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.51"><b>3.3</b></a></li> 2821 <li class="indline1"><tt>authority</tt> <a class="iref" href="#rfc.iref.g.28"><b>2.1</b></a></li> 2822 <li class="indline1"><tt>BWS</tt> <a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li> 2823 <li class="indline1">CHAR <a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li> 2824 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g.54"><b>3.3.1</b></a></li> 2825 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.60"><b>3.3.1</b></a></li> 2826 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.57"><b>3.3.1</b></a></li> 2827 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g.58"><b>3.3.1</b></a></li> 2828 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g.59"><b>3.3.1</b></a></li> 2829 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g.55"><b>3.3.1</b></a></li> 2830 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.53"><b>3.3.1</b></a></li> 2831 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li> 2832 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.83"><b>8.1</b></a></li> 2833 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.85"><b>8.1</b></a></li> 2834 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.84"><b>8.1</b></a></li> 2835 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.86"><b>8.2</b></a></li> 2836 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.87"><b>8.2</b></a></li> 2837 <li class="indline1">CR <a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li> 2838 <li class="indline1">CRLF <a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li> 2839 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li> 2840 <li class="indline1">CTL <a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li> 2841 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.3</b></a></li> 2842 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.3</b></a></li> 2843 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.41"><b>3.2.1</b></a></li> 2844 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.42"><b>3.2.1</b></a></li> 2845 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.43"><b>3.2.1</b></a></li> 2846 <li class="indline1">DIGIT <a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li> 2847 <li class="indline1">DQUOTE <a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li> 2848 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.81"><b>6.1.1</b></a></li> 2849 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.76"><b>5.1.1</b></a></li> 2850 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.70"><b>4.2</b></a></li> 2851 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.68"><b>4.2</b></a></li> 2852 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.69"><b>4.2</b></a></li> 2853 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.72"><b>4.5</b></a></li> 2854 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.65"><b>4.1</b></a></li> 2855 <li class="indline1">HEXDIG <a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li> 2856 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.4</b></a></li> 2857 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.4</b></a></li> 2858 <li class="indline1">HTAB <a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li> 2859 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.2.1</b></a></li> 2860 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.64"><b>4.1</b></a></li> 2861 <li class="indline1"><tt>HTTP-Prot-Name</tt> <a class="iref" href="#rfc.iref.g.35"><b>3.1</b></a></li> 2862 <li class="indline1"><tt>http-URI</tt> <a class="iref" href="#rfc.iref.g.33"><b>2.1.1</b></a></li> 2863 <li class="indline1"><tt>HTTP-Version</tt> <a class="iref" href="#rfc.iref.g.34"><b>3.1</b></a></li> 2864 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.56"><b>3.3.1</b></a></li> 2865 <li class="indline1">LF <a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li> 2866 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.71"><b>4.3</b></a></li> 2867 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.67"><b>4.2</b></a></li> 2868 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.75"><b>5.1.1</b></a></li> 2869 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.47"><b>3.2.1</b></a></li> 2870 <li class="indline1"><tt>obsolete-date</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.2.1</b></a></li> 2871 <li class="indline1">OCTET <a class="iref" href="#rfc.iref.g.11"><b>1.2</b></a></li> 2872 <li class="indline1"><tt>OWS</tt> <a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li> 2873 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.50"><b>3.3</b></a></li> 2874 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g.29"><b>2.1</b></a></li> 2875 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.30"><b>2.1</b></a></li> 2876 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.62"><b>3.4</b></a></li> 2877 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.63"><b>3.4</b></a></li> 2878 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.104"><b>8.9</b></a></li> 2879 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.105"><b>8.9</b></a></li> 2880 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.107"><b>8.9</b></a></li> 2881 <li class="indline1"><tt>qdtext</tt> <a class="iref" href="#rfc.iref.g.23"><b>1.2.2</b></a></li> 2882 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.31"><b>2.1</b></a></li> 2883 <li class="indline1"><tt>quoted-pair</tt> <a class="iref" href="#rfc.iref.g.25"><b>1.2.2</b></a></li> 2884 <li class="indline1"><tt>quoted-string</tt> <a class="iref" href="#rfc.iref.g.22"><b>1.2.2</b></a></li> 2885 <li class="indline1"><tt>quoted-text</tt> <a class="iref" href="#rfc.iref.g.24"><b>1.2.2</b></a></li> 2886 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.82"><b>6.1.1</b></a></li> 2887 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.106"><b>8.9</b></a></li> 2888 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.103"><b>8.9</b></a></li> 2889 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.73"><b>5</b></a></li> 2890 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.74"><b>5.1</b></a></li> 2891 <li class="indline1"><tt>request-target</tt> <a class="iref" href="#rfc.iref.g.77"><b>5.1.2</b></a></li> 2892 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.78"><b>6</b></a></li> 2893 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.2.1</b></a></li> 2894 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.2.1</b></a></li> 2895 <li class="indline1"><tt>RWS</tt> <a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 2896 <li class="indline1">SP <a class="iref" href="#rfc.iref.g.12"><b>1.2</b></a></li> 2897 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.66"><b>4.1</b></a></li> 2898 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.80"><b>6.1.1</b></a></li> 2899 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.79"><b>6.1</b></a></li> 2900 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.94"><b>8.5</b></a></li> 2901 <li class="indline1"><tt>tchar</tt> <a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li> 2902 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.92"><b>8.5</b></a></li> 2903 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.5</b></a></li> 2904 <li class="indline1"><tt>TEXT</tt> <a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li> 2905 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.44"><b>3.2.1</b></a></li> 2906 <li class="indline1"><tt>token</tt> <a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li> 2907 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.95"><b>8.6</b></a></li> 2908 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.61"><b>3.3.1</b></a></li> 2909 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.96"><b>8.6</b></a></li> 2910 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.48"><b>3.3</b></a></li> 2911 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.97"><b>8.7</b></a></li> 2912 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.98"><b>8.7</b></a></li> 2913 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.49"><b>3.3</b></a></li> 2914 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.99"><b>8.8</b></a></li> 2915 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.100"><b>8.8</b></a></li> 2916 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.32"><b>2.1</b></a></li> 2917 <li class="indline1"><tt>URI-reference</tt> <a class="iref" href="#rfc.iref.g.26"><b>2.1</b></a></li> 2918 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.52"><b>3.3</b></a></li> 2919 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.101"><b>8.9</b></a></li> 2920 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.102"><b>8.9</b></a></li> 2921 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.46"><b>3.2.1</b></a></li> 2922 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.45"><b>3.2.1</b></a></li> 2923 <li class="indline1">WSP <a class="iref" href="#rfc.iref.g.13"><b>1.2</b></a></li> 2815 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.2.1</b></a></li> 2816 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.48"><b>3.3</b></a></li> 2817 <li class="indline1"><tt>authority</tt> <a class="iref" href="#rfc.iref.g.25"><b>2.1</b></a></li> 2818 <li class="indline1"><tt>BWS</tt> <a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 2819 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g.51"><b>3.3.1</b></a></li> 2820 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.57"><b>3.3.1</b></a></li> 2821 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.54"><b>3.3.1</b></a></li> 2822 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g.55"><b>3.3.1</b></a></li> 2823 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g.56"><b>3.3.1</b></a></li> 2824 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g.52"><b>3.3.1</b></a></li> 2825 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.50"><b>3.3.1</b></a></li> 2826 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.68"><b>4.2</b></a></li> 2827 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.82"><b>8.1</b></a></li> 2828 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.84"><b>8.1</b></a></li> 2829 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.83"><b>8.1</b></a></li> 2830 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.85"><b>8.2</b></a></li> 2831 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.86"><b>8.2</b></a></li> 2832 <li class="indline1">CR <a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li> 2833 <li class="indline1">CRLF <a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li> 2834 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.69"><b>4.2</b></a></li> 2835 <li class="indline1">CTL <a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li> 2836 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.87"><b>8.3</b></a></li> 2837 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.3</b></a></li> 2838 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.2.1</b></a></li> 2839 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.2.1</b></a></li> 2840 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.40"><b>3.2.1</b></a></li> 2841 <li class="indline1">DIGIT <a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li> 2842 <li class="indline1">DQUOTE <a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li> 2843 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.80"><b>6.1.1</b></a></li> 2844 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.75"><b>5.1.1</b></a></li> 2845 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.67"><b>4.2</b></a></li> 2846 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.65"><b>4.2</b></a></li> 2847 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.66"><b>4.2</b></a></li> 2848 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.71"><b>4.5</b></a></li> 2849 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.62"><b>4.1</b></a></li> 2850 <li class="indline1">HEXDIG <a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li> 2851 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.4</b></a></li> 2852 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.4</b></a></li> 2853 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.33"><b>3.2.1</b></a></li> 2854 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.61"><b>4.1</b></a></li> 2855 <li class="indline1"><tt>HTTP-Prot-Name</tt> <a class="iref" href="#rfc.iref.g.32"><b>3.1</b></a></li> 2856 <li class="indline1"><tt>http-URI</tt> <a class="iref" href="#rfc.iref.g.30"><b>2.1.1</b></a></li> 2857 <li class="indline1"><tt>HTTP-Version</tt> <a class="iref" href="#rfc.iref.g.31"><b>3.1</b></a></li> 2858 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.53"><b>3.3.1</b></a></li> 2859 <li class="indline1">LF <a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li> 2860 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.70"><b>4.3</b></a></li> 2861 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.64"><b>4.2</b></a></li> 2862 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.74"><b>5.1.1</b></a></li> 2863 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.44"><b>3.2.1</b></a></li> 2864 <li class="indline1"><tt>obs-text</tt> <a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li> 2865 <li class="indline1"><tt>obsolete-date</tt> <a class="iref" href="#rfc.iref.g.35"><b>3.2.1</b></a></li> 2866 <li class="indline1">OCTET <a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li> 2867 <li class="indline1"><tt>OWS</tt> <a class="iref" href="#rfc.iref.g.13"><b>1.2.2</b></a></li> 2868 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.47"><b>3.3</b></a></li> 2869 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g.26"><b>2.1</b></a></li> 2870 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.27"><b>2.1</b></a></li> 2871 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.59"><b>3.4</b></a></li> 2872 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.60"><b>3.4</b></a></li> 2873 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.103"><b>8.9</b></a></li> 2874 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.104"><b>8.9</b></a></li> 2875 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.106"><b>8.9</b></a></li> 2876 <li class="indline1"><tt>qdtext</tt> <a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li> 2877 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.28"><b>2.1</b></a></li> 2878 <li class="indline1"><tt>quoted-pair</tt> <a class="iref" href="#rfc.iref.g.22"><b>1.2.2</b></a></li> 2879 <li class="indline1"><tt>quoted-string</tt> <a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li> 2880 <li class="indline1"><tt>quoted-text</tt> <a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li> 2881 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.81"><b>6.1.1</b></a></li> 2882 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.105"><b>8.9</b></a></li> 2883 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.102"><b>8.9</b></a></li> 2884 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.72"><b>5</b></a></li> 2885 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.73"><b>5.1</b></a></li> 2886 <li class="indline1"><tt>request-target</tt> <a class="iref" href="#rfc.iref.g.76"><b>5.1.2</b></a></li> 2887 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.77"><b>6</b></a></li> 2888 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.34"><b>3.2.1</b></a></li> 2889 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.2.1</b></a></li> 2890 <li class="indline1"><tt>RWS</tt> <a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li> 2891 <li class="indline1">SP <a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li> 2892 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.63"><b>4.1</b></a></li> 2893 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.79"><b>6.1.1</b></a></li> 2894 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.78"><b>6.1</b></a></li> 2895 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.5</b></a></li> 2896 <li class="indline1"><tt>tchar</tt> <a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li> 2897 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.5</b></a></li> 2898 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.92"><b>8.5</b></a></li> 2899 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.41"><b>3.2.1</b></a></li> 2900 <li class="indline1"><tt>token</tt> <a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li> 2901 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.94"><b>8.6</b></a></li> 2902 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.58"><b>3.3.1</b></a></li> 2903 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.95"><b>8.6</b></a></li> 2904 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.45"><b>3.3</b></a></li> 2905 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.96"><b>8.7</b></a></li> 2906 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.97"><b>8.7</b></a></li> 2907 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.46"><b>3.3</b></a></li> 2908 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.98"><b>8.8</b></a></li> 2909 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.99"><b>8.8</b></a></li> 2910 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.29"><b>2.1</b></a></li> 2911 <li class="indline1"><tt>URI-reference</tt> <a class="iref" href="#rfc.iref.g.23"><b>2.1</b></a></li> 2912 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.49"><b>3.3</b></a></li> 2913 <li class="indline1">VCHAR <a class="iref" href="#rfc.iref.g.11"><b>1.2</b></a></li> 2914 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.100"><b>8.9</b></a></li> 2915 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.101"><b>8.9</b></a></li> 2916 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.43"><b>3.2.1</b></a></li> 2917 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.42"><b>3.2.1</b></a></li> 2918 <li class="indline1">WSP <a class="iref" href="#rfc.iref.g.12"><b>1.2</b></a></li> 2924 2919 </ul> 2925 2920 </li> … … 2947 2942 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 2948 2943 <li class="indline1">inbound <a class="iref" href="#rfc.iref.i.1">C</a></li> 2949 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1"> 1.2.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li>2944 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">4.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li> 2950 2945 </ul> 2951 2946 </li> … … 2976 2971 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2977 2972 <li class="indline1"><em>Pad1995</em> <a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li> 2978 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4. 2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.3</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a>, <a class="iref" href="#rfc.xref.Part2.7">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">2979 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2. 5">4.3</a></li>2980 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2. 3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a></li>2981 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2. 4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li>2982 <li class="indline1"><em>Section 8.1.2</em> <a class="iref" href="#rfc.xref.Part2. 11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a></li>2983 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2. 7">5.1.2</a></li>2984 <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2. 10">6.1.1</a></li>2985 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.1 3">7.2.3</a></li>2986 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.1 6">7.2.3</a></li>2987 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2. 8">5.1.2</a></li>2988 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.1 4">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a></li>2973 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.3</a>, <a class="iref" href="#rfc.xref.Part2.4">5</a>, <a class="iref" href="#rfc.xref.Part2.5">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a>, <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind"> 2974 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.3">4.3</a></li> 2975 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">5</a></li> 2976 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li> 2977 <li class="indline1"><em>Section 8.1.2</em> <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li> 2978 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2.5">5.1.2</a></li> 2979 <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li> 2980 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li> 2981 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li> 2982 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li> 2983 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li> 2989 2984 </ul> 2990 2985 </li> 2991 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a>, <a class="iref" href="#rfc.xref.Part3.8"> 4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">A</a>, <a class="iref" href="#rfc.xref.Part3.13">B.3</a>, <a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a>, <a class="iref" href="#rfc.xref.Part3.16">C</a><ul class="ind">2986 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a>, <a class="iref" href="#rfc.xref.Part3.8">5</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a>, <a class="iref" href="#rfc.xref.Part3.12">B.3</a>, <a class="iref" href="#rfc.xref.Part3.13">C</a>, <a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a><ul class="ind"> 2992 2987 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a></li> 2993 2988 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li> 2994 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.1 1">8.5</a></li>2995 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8"> 4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li>2996 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.1 4">C</a></li>2989 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.10">8.5</a></li> 2990 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">5</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a></li> 2991 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.13">C</a></li> 2997 2992 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a></li> 2998 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.1 5">C</a>, <a class="iref" href="#rfc.xref.Part3.16">C</a></li>2993 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a></li> 2999 2994 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li> 3000 2995 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a></li> … … 3023 3018 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li> 3024 3019 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.3</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li> 3025 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1"> 1.2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li>3020 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">4.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li> 3026 3021 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.5">11</a>, <a class="iref" href="#RFC2068"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.6">B</a>, <a class="iref" href="#rfc.xref.RFC2068.7">B.2</a><ul class="ind"> 3027 3022 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068.6">B</a></li> … … 3088 3083 </ul> 3089 3084 </li> 3090 <li class="indline1"><em>USASCII</em> <a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="# USASCII"><b>12.1</b></a></li>3085 <li class="indline1"><em>USASCII</em> <a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#rfc.xref.USASCII.2">4.2</a>, <a class="iref" href="#USASCII"><b>12.1</b></a></li> 3091 3086 <li class="indline1">user agent <a class="iref" href="#rfc.iref.u.4">C</a></li> 3092 3087 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r391 r395 304 304 <section title="Syntax Notation" anchor="notation"> 305 305 <iref primary="true" item="Grammar" subitem="ALPHA"/> 306 <iref primary="true" item="Grammar" subitem="CHAR"/>307 306 <iref primary="true" item="Grammar" subitem="CR"/> 308 307 <iref primary="true" item="Grammar" subitem="CRLF"/> … … 311 310 <iref primary="true" item="Grammar" subitem="DQUOTE"/> 312 311 <iref primary="true" item="Grammar" subitem="HEXDIG"/> 313 <iref primary="true" item="Grammar" subitem="HTAB"/>314 312 <iref primary="true" item="Grammar" subitem="LF"/> 315 313 <iref primary="true" item="Grammar" subitem="OCTET"/> 316 314 <iref primary="true" item="Grammar" subitem="SP"/> 315 <iref primary="true" item="Grammar" subitem="VCHAR"/> 317 316 <iref primary="true" item="Grammar" subitem="WSP"/> 318 317 <t anchor="core.rules"> 319 318 <x:anchor-alias value="ALPHA"/> 320 <x:anchor-alias value="CHAR"/>321 319 <x:anchor-alias value="CTL"/> 322 320 <x:anchor-alias value="CR"/> … … 325 323 <x:anchor-alias value="DQUOTE"/> 326 324 <x:anchor-alias value="HEXDIG"/> 327 <x:anchor-alias value="HTAB"/>328 325 <x:anchor-alias value="LF"/> 329 326 <x:anchor-alias value="OCTET"/> 330 327 <x:anchor-alias value="SP"/> 328 <x:anchor-alias value="VCHAR"/> 331 329 <x:anchor-alias value="WSP"/> 332 330 This specification uses the Augmented Backus-Naur Form (ABNF) notation 333 331 of <xref target="RFC5234"/>. The following core rules are included by 334 332 reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: 335 ALPHA (letters), CHAR (any <xref target="USASCII"/> character, 336 excluding NUL), CR (carriage return), CRLF (CR LF), CTL (controls), 333 ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), 337 334 DIGIT (decimal 0-9), DQUOTE (double quote), 338 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), 339 LF (line feed), OCTET (any 8-bit sequence of data), SP (space) 335 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), 336 OCTET (any 8-bit sequence of data), SP (space), 337 VCHAR (any visible <xref target="USASCII"/> character), 340 338 and WSP (white space). 341 339 </t> … … 388 386 </t> 389 387 <t anchor="rule.LWS"> 390 All linear white space (LWS) in header field-values has the same semantics as SP. A 391 recipient &MAY; replace any such linear white space with a single SP before 388 This specification uses three rules to denote the use of linear 389 whitespace: OWS (optional whitespace), RWS (required whitespace), and 390 BWS ("bad" whitespace). 391 </t> 392 <t> 393 The OWS rule is used where zero or more linear white space characters may 394 appear. OWS &SHOULD; either not be produced or be produced as a single SP 395 character. Multiple OWS characters that occur within field-content &SHOULD; 396 be replaced with a single SP before interpreting the field value or 397 forwarding the message downstream. 398 </t> 399 <t> 400 RWS is used when at least one linear white space character is required to 401 separate field tokens. RWS &SHOULD; be produced as a single SP character. 402 Multiple RWS characters that occur within field-content &SHOULD; be 403 replaced with a single SP before interpreting the field value or 404 forwarding the message downstream. 405 </t> 406 <t> 407 BWS is used where the grammar allows optional whitespace for historical 408 reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1 409 recipients &MUST; accept such bad optional whitespace and remove it before 392 410 interpreting the field value or forwarding the message downstream. 393 </t>394 <t>395 Historically, HTTP/1.1 header field values allow linear white space folding across396 multiple lines. However, this specification deprecates its use; senders &MUST-NOT;397 produce messages that include LWS folding (i.e., use the obs-fold rule), except398 within the message/http media type (<xref target="internet.media.type.message.http"/>).399 Receivers &SHOULD; still parse folded linear white space.400 </t>401 <t>402 This specification uses three rules to denote the use of linear white space;403 BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space).404 </t>405 <t>406 "Bad" white space is allowed by the BNF, but senders &SHOULD-NOT; produce it in messages.407 Receivers &MUST; accept it in incoming messages.408 </t>409 <t>410 Required white space is used when at least one linear white space character411 is required to separate field tokens. In all such cases, a single SP character412 &SHOULD; be used.413 411 </t> 414 412 <t anchor="rule.whitespace"> … … 427 425 <x:ref>obs-fold</x:ref> = <x:ref>CRLF</x:ref> 428 426 </artwork></figure> 429 <t anchor="rule.TEXT">430 <x:anchor-alias value="TEXT"/>431 The TEXT rule is only used for descriptive field contents and values432 that are not intended to be interpreted by the message parser. Words433 of *TEXT &MAY; contain characters from character sets other than ISO-8859-1434 <xref target="ISO-8859-1"/> only when encoded according to the rules of435 <xref target="RFC2047"/>.436 </t>437 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TEXT"/>438 <x:ref>TEXT</x:ref> = %x20-7E / %x80-FF / <x:ref>OWS</x:ref>439 ; any <x:ref>OCTET</x:ref> except <x:ref>CTL</x:ref>s, but including <x:ref>OWS</x:ref>440 </artwork></figure>441 <t>442 A CRLF is allowed in the definition of TEXT only as part of a header443 field continuation. It is expected that the folding LWS will be444 replaced with a single SP before interpretation of the TEXT value.445 </t>446 427 <t anchor="rule.token.separators"> 447 428 <x:anchor-alias value="tchar"/> 448 429 <x:anchor-alias value="token"/> 449 Many HTTP/1.1 header field values consist of words separated by LWS430 Many HTTP/1.1 header field values consist of words separated by whitespace 450 431 or special characters. These special characters &MUST; be in a quoted 451 432 string to be used within a parameter value (as defined in … … 459 440 <x:ref>token</x:ref> = 1*<x:ref>tchar</x:ref> 460 441 </artwork></figure> 461 <t anchor="rule.comment">462 <x:anchor-alias value="comment"/>463 <x:anchor-alias value="ctext"/>464 Comments can be included in some HTTP header fields by surrounding465 the comment text with parentheses. Comments are only allowed in466 fields containing "comment" as part of their field value definition.467 In all other fields, parentheses are considered part of the field468 value.469 </t>470 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>471 <x:ref>comment</x:ref> = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-pair</x:ref> / <x:ref>comment</x:ref> ) ")"472 <x:ref>ctext</x:ref> = <any <x:ref>TEXT</x:ref> excluding "(" and ")">473 </artwork></figure>474 442 <t anchor="rule.quoted-string"> 475 443 <x:anchor-alias value="quoted-string"/> 476 444 <x:anchor-alias value="qdtext"/> 445 <x:anchor-alias value="obs-text"/> 477 446 A string of text is parsed as a single word if it is quoted using 478 447 double-quote marks. 479 448 </t> 480 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/> 449 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/> 481 450 <x:ref>quoted-string</x:ref> = <x:ref>DQUOTE</x:ref> *(<x:ref>qdtext</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> 482 <x:ref>qdtext</x:ref> = <any <x:ref>TEXT</x:ref> excluding <x:ref>DQUOTE</x:ref> and "\"> 451 <x:ref>qdtext</x:ref> = *( <x:ref>OWS</x:ref> / %x21 / %x23-5B / %x5D-7E / <x:ref>obs-text</x:ref> ) 452 <x:ref>obs-text</x:ref> = %x80-FF 483 453 </artwork></figure> 484 454 <t anchor="rule.quoted-pair"> … … 564 534 </t> 565 535 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/> 566 <x:ref>URI</x:ref> = <URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/> >567 <x:ref>URI-reference</x:ref> = <URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/> >568 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/> >569 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/> >570 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/> >571 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/> >572 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/> >573 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/> >574 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/> >575 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/> >576 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/> >536 <x:ref>URI</x:ref> = <URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/>> 537 <x:ref>URI-reference</x:ref> = <URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/>> 538 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>> 539 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>> 540 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>> 541 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>> 542 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 543 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 544 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>> 545 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>> 546 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>> 577 547 578 548 <x:ref>partial-URI</x:ref> = relative-part [ "?" query ] … … 906 876 abbreviation for time zone, and &MUST; be assumed when reading the 907 877 asctime format. HTTP-date is case sensitive and &MUST-NOT; include 908 additional LWSbeyond that specifically included as SP in the878 additional whitespace beyond that specifically included as SP in the 909 879 grammar. 910 880 </t> … … 1211 1181 extra CRLF. 1212 1182 </t> 1183 <t> 1184 Whitespace (WSP) &MUST-NOT; be sent between the start-line and the first 1185 header field. The presence of whitespace might be an attempt to trick a 1186 noncompliant implementation of HTTP into ignoring that field or processing 1187 the next line as a new request, either of which may result in security 1188 issues when implementations within the request chain interpret the 1189 same message differently. HTTP/1.1 servers &MUST; reject such a message 1190 with a 400 (Bad Request) response. 1191 </t> 1213 1192 </section> 1214 1193 … … 1219 1198 <x:anchor-alias value="message-header"/> 1220 1199 <t> 1221 HTTP header fields, which include general-header (<xref target="general.header.fields"/>), 1222 request-header (&request-header-fields;), response-header (&response-header-fields;), and 1223 entity-header (&entity-header-fields;) fields, follow the same generic format as 1224 that given in <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists 1225 of a name followed by a colon (":") and the field value. Field names 1226 are case-insensitive. The field value &MAY; be preceded by any amount 1227 of LWS, though a single SP is preferred. Header fields can be 1228 extended over multiple lines by preceding each extra line with at 1229 least one SP or HTAB. Applications ought to follow "common form", where 1230 one is known or indicated, when generating HTTP constructs, since 1231 there might exist some implementations that fail to accept anything 1232 beyond the common forms. 1200 HTTP header fields follow the same general format as Internet messages in 1201 <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists 1202 of a name followed by a colon (":"), optional whitespace, and the field 1203 value. Field names are case-insensitive. 1233 1204 </t> 1234 1205 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/> 1235 <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" [ <x:ref>field-value</x:ref> ]1206 <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" OWS [ <x:ref>field-value</x:ref> ] OWS 1236 1207 <x:ref>field-name</x:ref> = <x:ref>token</x:ref> 1237 1208 <x:ref>field-value</x:ref> = *( <x:ref>field-content</x:ref> / <x:ref>OWS</x:ref> ) 1238 <x:ref>field-content</x:ref> = <field content> 1239 </artwork></figure> 1240 <t> 1241 <cref>whitespace between field-name and colon is an error and MUST NOT be accepted</cref> 1242 </t> 1243 <t> 1244 The field-content does not include any leading or trailing LWS: 1245 linear white space occurring before the first non-whitespace 1246 character of the field-value or after the last non-whitespace 1247 character of the field-value. Such leading or trailing LWS &MAY; be 1248 removed without changing the semantics of the field value. Any LWS 1249 that occurs between field-content &MAY; be replaced with a single SP 1250 before interpreting the field value or forwarding the message 1251 downstream. 1252 </t> 1209 <x:ref>field-content</x:ref> = *( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 1210 </artwork></figure> 1211 <t> 1212 Historically, HTTP has allowed field-content with text in the ISO-8859-1 1213 <xref target="ISO-8859-1"/> character encoding (allowing other character sets 1214 through use of <xref target="RFC2047"/> encoding). In practice, most HTTP 1215 header field-values use only a subset of the US-ASCII charset 1216 <xref target="USASCII"/>. Newly defined header fields &SHOULD; constrain 1217 their field-values to US-ASCII characters. Recipients &SHOULD; treat other 1218 (obs-text) octets in field-content as opaque data. 1219 </t> 1220 <t> 1221 No whitespace is allowed between the header field-name and colon. For 1222 security reasons, any request message received containing such whitespace 1223 &MUST; be rejected with a response code of 400 (Bad Request) and any such 1224 whitespace in a response message &MUST; be removed. 1225 </t> 1226 <t> 1227 The field value &MAY; be preceded by optional white space; a single SP is 1228 preferred. The field-value does not include any leading or trailing white 1229 space: OWS occurring before the first non-whitespace character of the 1230 field-value or after the last non-whitespace character of the field-value 1231 is ignored and &MAY; be removed without changing the meaning of the header 1232 field. 1233 </t> 1234 <t> 1235 Historically, HTTP header field values could be extended over multiple 1236 lines by preceding each extra line with at least one space or horizontal 1237 tab character (line folding). This specification deprecates such line 1238 folding except within the message/http media type 1239 (<xref target="internet.media.type.message.http"/>). 1240 HTTP/1.1 senders &MUST-NOT; produce messages that include line folding 1241 (i.e., that contain any field-content that matches the obs-fold rule) unless 1242 the message is intended for packaging within the message/http media type. 1243 HTTP/1.1 recipients &SHOULD; accept line folding and replace any embedded 1244 obs-fold whitespace with a single SP prior to interpreting the field value 1245 or forwarding the message downstream. 1246 </t> 1247 <t anchor="rule.comment"> 1248 <x:anchor-alias value="comment"/> 1249 <x:anchor-alias value="ctext"/> 1250 Comments can be included in some HTTP header fields by surrounding 1251 the comment text with parentheses. Comments are only allowed in 1252 fields containing "comment" as part of their field value definition. 1253 In all other fields, parentheses are considered part of the field 1254 value. 1255 </t> 1256 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/> 1257 <x:ref>comment</x:ref> = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-pair</x:ref> / <x:ref>comment</x:ref> ) ")" 1258 <x:ref>ctext</x:ref> = *( <x:ref>OWS</x:ref> / %x21-27 / %x2A-7E / <x:ref>obs-text</x:ref> ) 1259 </artwork></figure> 1253 1260 <t> 1254 1261 The order in which header fields with differing field names are … … 1692 1699 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/> 1693 1700 <x:ref>Status-Code</x:ref> = 3<x:ref>DIGIT</x:ref> 1694 <x:ref>Reason-Phrase</x:ref> = * <<x:ref>TEXT</x:ref>, excluding <x:ref>CR</x:ref>, <x:ref>LF</x:ref>>1701 <x:ref>Reason-Phrase</x:ref> = *( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 1695 1702 </artwork></figure> 1696 1703 </section> … … 3865 3872 Clients &SHOULD; be tolerant in parsing the Status-Line and servers 3866 3873 tolerant when parsing the Request-Line. In particular, they &SHOULD; 3867 accept any amount of SP or HTABcharacters between fields, even though3874 accept any amount of WSP characters between fields, even though 3868 3875 only a single SP is required. 3869 3876 </t> … … 4077 4084 Rules about implicit linear white space between certain grammar productions 4078 4085 have been removed; now it's only allowed when specifically pointed out 4079 in the ABNF. 4080 The CHAR rule does not allow the NUL character anymore (this affects 4081 the comment and quoted-string rules). Furthermore, the quoted-pair 4082 rule does not allow escaping NUL, CR or LF anymore. 4086 in the ABNF. The NUL character is no longer allowed in comment and quoted-string 4087 text. The quoted-pair rule no longer allows escaping NUL, CR or LF. 4083 4088 (<xref target="basic.rules"/>) 4084 4089 </t> … … 4463 4468 </t> 4464 4469 <t> 4465 Use names of RFC4234 core rules DQUOTE and HTAB,4470 Use names of RFC4234 core rules DQUOTE and WSP, 4466 4471 fix broken ABNF for chunk-data 4467 4472 (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>) … … 4510 4515 </t> 4511 4516 <t> 4512 Synchronize core rules with RFC5234 (this includes a change to CHAR 4513 which now excludes NUL). 4517 Synchronize core rules with RFC5234. 4514 4518 </t> 4515 4519 <t> -
draft-ietf-httpbis/latest/p6-cache.html
r391 r395 485 485 <tr> 486 486 <td class="header left"></td> 487 <td class="header right">November 1 5, 2008</td>487 <td class="header right">November 14, 2008</td> 488 488 </tr> 489 489 </table> … … 1089 1089 <p id="rfc.section.7.3.p.2">If the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this 1090 1090 outgoing response. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache <em class="bcp14">MAY</em> combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body 1091 of this outgoing response, (see <a href="p5-range.html#combining.byte.ranges" title="Combining ByteRanges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).1091 of this outgoing response, (see <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). 1092 1092 </p> 1093 1093 <p id="rfc.section.7.3.p.3">The end-to-end headers stored in the cache entry are used for the constructed response, except that </p> … … 1156 1156 </p> 1157 1157 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></h1> 1158 <p id="rfc.section.10.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining ByteRanges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code.1158 <p id="rfc.section.10.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. 1159 1159 A cache <em class="bcp14">MUST NOT</em> return a partial response using a status code of 200 (OK). 1160 1160 </p> … … 1951 1951 <p id="rfc.section.B.2.p.2">Other changes: </p> 1952 1952 <ul> 1953 <li>Use names of RFC4234 core rule s DQUOTE and HTAB(work in progress on <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>)1953 <li>Use names of RFC4234 core rule DQUOTE (work in progress on <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>) 1954 1954 </li> 1955 1955 </ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r391 r395 2983 2983 <list style="symbols"> 2984 2984 <t> 2985 Use names of RFC4234 core rule s DQUOTE and HTAB(work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>)2985 Use names of RFC4234 core rule DQUOTE (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>) 2986 2986 </t> 2987 2987 </list>
Note: See TracChangeset
for help on using the changeset viewer.