![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 400 for draft-ietf-httpbis
- Timestamp:
- 15/11/08 19:45:44 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p1-messaging.html (modified) (47 diffs)
-
p1-messaging.xml (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r398 r400 717 717 </p> 718 718 <p id="rfc.section.1.2.1.p.2">A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at 719 least <n> and at most <m> elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (OWS). This makes the usual form of lists very easy; a rule such as 720 </p> 721 <div id="rfc.figure.u.1"></div><pre class="text"> ( *<a href="#rule.whitespace" class="smpl">OWS</a> element *( *<a href="#rule.whitespace" class="smpl">OWS</a> "," *<a href="#rule.whitespace" class="smpl">OWS</a> element ))</pre><p id="rfc.section.1.2.1.p.3">can be shown as </p> 722 <div id="rfc.figure.u.2"></div><pre class="text"> 1#element</pre><p id="rfc.section.1.2.1.p.4">Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, 723 "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, 724 at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at 725 least one; and "1#2element" allows one or two. 726 </p> 727 <p id="rfc.section.1.2.1.p.5"> <span class="comment">[abnf.list: At a later point of time, we may want to add an appendix containing the whole ABNF, with the list rules expanded to strict 719 least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS). 720 </p> 721 <div id="rfc.figure.u.1"></div> 722 <p>Thus,</p><pre class="text"> 1#element => element *( OWS "," OWS element ) 723 </pre><div id="rfc.figure.u.2"></div> 724 <p>and:</p><pre class="text"> #element => [ 1#element ] 725 </pre><div id="rfc.figure.u.3"></div> 726 <p>and for n >= 1 and m > 1:</p><pre class="text"> <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 727 </pre><p id="rfc.section.1.2.1.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions: 728 </p> 729 <div id="rfc.figure.u.4"></div><pre class="text">#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 730 731 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 732 </pre><p id="rfc.section.1.2.1.p.8"> <span class="comment">[abnf.list: At a later point of time, we may want to add an appendix containing the whole ABNF, with the list rules expanded to strict 728 733 RFC 5234 notation.]</span> 729 734 </p> … … 748 753 <p id="rfc.section.1.2.2.p.6"> </p> 749 754 </div> 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> )755 <div id="rfc.figure.u.5"></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> ) 751 756 ; "optional" white space 752 757 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> ) … … 759 764 </p> 760 765 </div> 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> = "!" / "#" / "$" / "%" / "&" / "'" / "*"766 <div id="rfc.figure.u.6"></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> = "!" / "#" / "$" / "%" / "&" / "'" / "*" 762 767 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 763 768 / <a href="#core.rules" class="smpl">DIGIT</a> / <a href="#core.rules" class="smpl">ALPHA</a> … … 767 772 <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 773 </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>774 <div id="rfc.figure.u.7"></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 775 <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 776 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF … … 774 779 </p> 775 780 </div> 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 /781 <div id="rfc.figure.u.8"></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 / 777 782 %x0B-0C / 778 783 %x0E-FF ; Characters excluding NUL, <a href="#core.rules" class="smpl">CR</a> and <a href="#core.rules" class="smpl">LF</a> … … 780 785 </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> 781 786 <p id="rfc.section.1.2.3.p.1">The ABNF rules below are defined in other parts:</p> 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>>787 <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>> 783 788 <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>> 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>>789 </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>> 785 790 <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>> 786 791 <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>> 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>>792 </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>> 788 793 <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>> 789 794 <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>> … … 801 806 "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. 802 807 </p> 803 <div id="rfc.figure.u.1 0"></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>>808 <div id="rfc.figure.u.12"></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>> 804 809 <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>> 805 810 <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>> … … 825 830 for identifiers using the http or https URI schemes. 826 831 </p> 827 <div id="rfc.figure.u.1 1"></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> ]832 <div id="rfc.figure.u.13"></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> ] 828 833 </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 829 834 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. … … 847 852 </p> 848 853 <p id="rfc.section.2.1.2.p.3">For example, the following three URIs are equivalent:</p> 849 <div id="rfc.figure.u.1 2"></div><pre class="text"> http://example.com:80/~smith/home.html854 <div id="rfc.figure.u.14"></div><pre class="text"> http://example.com:80/~smith/home.html 850 855 http://EXAMPLE.com/%7Esmith/home.html 851 856 http://EXAMPLE.com:/%7esmith/home.html … … 862 867 server (O). 863 868 </p> 864 <div id="rfc.figure.u.1 3"></div><pre class="drawing"> request chain ------------------------>869 <div id="rfc.figure.u.15"></div><pre class="drawing"> request chain ------------------------> 865 870 UA -------------------v------------------- O 866 871 <----------------------- response chain … … 873 878 cannot understand the contents of the messages. 874 879 </p> 875 <div id="rfc.figure.u.1 4"></div><pre class="drawing"> request chain -------------------------------------->880 <div id="rfc.figure.u.16"></div><pre class="drawing"> request chain --------------------------------------> 876 881 UA -----v----- A -----v----- B -----v----- C -----v----- O 877 882 <------------------------------------- response chain … … 888 893 O (via C) for a request which has not been cached by UA or A. 889 894 </p> 890 <div id="rfc.figure.u.1 5"></div><pre class="drawing"> request chain ---------->895 <div id="rfc.figure.u.17"></div><pre class="drawing"> request chain ----------> 891 896 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 892 897 <--------- response chain … … 929 934 </p> 930 935 <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> 931 <div id="rfc.figure.u.1 6"></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>936 <div id="rfc.figure.u.18"></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> 932 937 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 933 938 </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. … … 953 958 <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> 954 959 <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> 955 <div id="rfc.figure.u.1 7"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123960 <div id="rfc.figure.u.19"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 956 961 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 957 962 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format … … 968 973 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 974 </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>975 <div id="rfc.figure.u.20"></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> 971 976 <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> 972 977 <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 … … 1027 1032 is a property of the message, not of the original entity. 1028 1033 </p> 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>1034 <div id="rfc.figure.u.21"></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> 1030 1035 <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> ) 1031 1036 </pre><div id="rule.parameter"> 1032 1037 <p id="rfc.section.3.3.p.3"> Parameters are in the form of attribute/value pairs.</p> 1033 1038 </div> 1034 <div id="rfc.figure.u.2 0"></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>1039 <div id="rfc.figure.u.22"></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> 1035 1040 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1036 1041 <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> … … 1057 1062 necessary for the recipient to verify that it has received the full message. 1058 1063 </p> 1059 <div id="rfc.figure.u.2 1"></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>1064 <div id="rfc.figure.u.23"></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> 1060 1065 <a href="#chunked.transfer.encoding" class="smpl">last-chunk</a> 1061 1066 <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a> … … 1095 1100 </p> 1096 1101 <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> 1097 <div id="rfc.figure.u.2 2"></div><pre class="text"> length := 01102 <div id="rfc.figure.u.24"></div><pre class="text"> length := 0 1098 1103 read chunk-size, chunk-ext (if any) and CRLF 1099 1104 while (chunk-size > 0) { … … 1117 1122 space. By convention, the products are listed in order of their significance for identifying the application. 1118 1123 </p> 1119 <div id="rfc.figure.u.2 3"></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>]1124 <div id="rfc.figure.u.25"></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>] 1120 1125 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1121 1126 </pre><p id="rfc.section.3.4.p.3">Examples:</p> 1122 <div id="rfc.figure.u.2 4"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31127 <div id="rfc.figure.u.26"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1123 1128 Server: Apache/0.8.4 1124 1129 </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). … … 1127 1132 <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> 1128 1133 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1129 <div id="rfc.figure.u.2 5"></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 messages1134 <div id="rfc.figure.u.27"></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 1130 1135 </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 1131 1136 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1132 1137 fields, and possibly a message-body. 1133 1138 </p> 1134 <div id="rfc.figure.u.2 6"></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>1139 <div id="rfc.figure.u.28"></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> 1135 1140 *(<a href="#message.headers" class="smpl">message-header</a> <a href="#core.rules" class="smpl">CRLF</a>) 1136 1141 <a href="#core.rules" class="smpl">CRLF</a> … … 1151 1156 case-insensitive. 1152 1157 </p> 1153 <div id="rfc.figure.u.2 7"></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> ] OWS1158 <div id="rfc.figure.u.29"></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 1154 1159 <a href="#message.headers" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1155 1160 <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> ) … … 1176 1181 </p> 1177 1182 </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> ) ")"1183 <div id="rfc.figure.u.30"></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 1184 <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 1185 </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" … … 1199 1204 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.7</a>). 1200 1205 </p> 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 <div id="rfc.figure.u.31"></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> 1202 1207 / <entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>> 1203 1208 </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 … … 1267 1272 to the entity being transferred. These header fields apply only to the message being transmitted. 1268 1273 </p> 1269 <div id="rfc.figure.u.3 0"></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 <div id="rfc.figure.u.32"></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> 1270 1275 / <a href="#header.connection" class="smpl">Connection</a> ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1271 1276 / <a href="#header.date" class="smpl">Date</a> ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> … … 1284 1289 resource, the identifier of the resource, and the protocol version in use. 1285 1290 </p> 1286 <div id="rfc.figure.u.3 1"></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 <div id="rfc.figure.u.33"></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> 1287 1292 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1288 1293 / <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> … … 1294 1299 The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1295 1300 </p> 1296 <div id="rfc.figure.u.3 2"></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 <div id="rfc.figure.u.34"></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> 1297 1302 </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> 1298 1303 <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> 1299 <div id="rfc.figure.u.3 3"></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 <div id="rfc.figure.u.35"></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> 1300 1305 </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> 1301 1306 <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. 1302 1307 </p> 1303 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#request-target" class="smpl">request-target</a> = "*"1308 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1304 1309 / <a href="#uri" class="smpl">absolute-URI</a> 1305 1310 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) … … 1309 1314 apply to a resource. One example would be 1310 1315 </p> 1311 <div id="rfc.figure.u.3 5"></div><pre class="text"> OPTIONS * HTTP/1.11316 <div id="rfc.figure.u.37"></div><pre class="text"> OPTIONS * HTTP/1.1 1312 1317 </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, 1313 1318 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 … … 1315 1320 Request-Line would be: 1316 1321 </p> 1317 <div id="rfc.figure.u.3 6"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11322 <div id="rfc.figure.u.38"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1318 1323 </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. 1319 1324 </p> … … 1324 1329 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1325 1330 </p> 1326 <div id="rfc.figure.u.3 7"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.11331 <div id="rfc.figure.u.39"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1 1327 1332 Host: www.example.org 1328 1333 </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 … … 1369 1374 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1> 1370 1375 <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 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 <div id="rfc.figure.u.40"></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> 1372 1377 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1373 1378 / <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> … … 1380 1385 CRLF sequence. 1381 1386 </p> 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 <div id="rfc.figure.u.41"></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> 1383 1388 </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> 1384 1389 <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 … … 1397 1402 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1398 1403 </ul> 1399 <div id="rfc.figure.u.4 0"></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>1404 <div id="rfc.figure.u.42"></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 1405 <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> ) 1401 1406 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1> … … 1589 1594 </p> 1590 1595 <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p> 1591 <div id="rfc.figure.u.4 1"></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 <div id="rfc.figure.u.43"></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> 1592 1597 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1593 1598 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1602 1607 of the response. For example, 1603 1608 </p> 1604 <div id="rfc.figure.u.4 2"></div><pre class="text"> Connection: close1609 <div id="rfc.figure.u.44"></div><pre class="text"> Connection: close 1605 1610 </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. 1606 1611 </p> … … 1618 1623 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. 1619 1624 </p> 1620 <div id="rfc.figure.u.4 3"></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 <div id="rfc.figure.u.45"></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> 1621 1626 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1622 1627 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1623 <div id="rfc.figure.u.4 4"></div><pre class="text"> Content-Length: 34951628 <div id="rfc.figure.u.46"></div><pre class="text"> Content-Length: 3495 1624 1629 </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>. 1625 1630 </p> … … 1636 1641 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. 1637 1642 </p> 1638 <div id="rfc.figure.u.4 5"></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 <div id="rfc.figure.u.47"></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> 1639 1644 <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a> 1640 1645 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1641 <div id="rfc.figure.u.4 6"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT1646 <div id="rfc.figure.u.48"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1642 1647 </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: 1643 1648 </p> … … 1675 1680 a single IP address. 1676 1681 </p> 1677 <div id="rfc.figure.u.4 7"></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 <div id="rfc.figure.u.49"></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> 1678 1683 <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> 1679 1684 </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 1680 1685 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1681 1686 </p> 1682 <div id="rfc.figure.u. 48"></div><pre class="text"> GET /pub/WWW/ HTTP/1.11687 <div id="rfc.figure.u.50"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1683 1688 Host: www.example.org 1684 1689 </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 … … 1695 1700 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>). 1696 1701 </p> 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 <div id="rfc.figure.u.51"></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> 1698 1703 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 1699 1704 <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> ] ) … … 1702 1707 </p> 1703 1708 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1704 <div id="rfc.figure.u.5 0"></div><pre class="text"> TE: deflate1709 <div id="rfc.figure.u.52"></div><pre class="text"> TE: deflate 1705 1710 TE: 1706 1711 TE: trailers, deflate;q=0.5 … … 1739 1744 chunked transfer-coding. 1740 1745 </p> 1741 <div id="rfc.figure.u.5 1"></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 <div id="rfc.figure.u.53"></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> 1742 1747 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a> 1743 1748 </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 … … 1760 1765 transfer-coding is a property of the message, not of the entity. 1761 1766 </p> 1762 <div id="rfc.figure.u.5 2"></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 <div id="rfc.figure.u.54"></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> 1763 1768 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 1764 1769 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1765 1770 </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: 1766 1771 </p> 1767 <div id="rfc.figure.u.5 3"></div><pre class="text"> Transfer-Encoding: chunked1772 <div id="rfc.figure.u.55"></div><pre class="text"> Transfer-Encoding: chunked 1768 1773 </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. 1769 1774 </p> … … 1775 1780 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. 1776 1781 </p> 1777 <div id="rfc.figure.u.5 4"></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 <div id="rfc.figure.u.56"></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> 1778 1783 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 1779 1784 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1780 <div id="rfc.figure.u.5 5"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x111785 <div id="rfc.figure.u.57"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1781 1786 </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 1782 1787 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 1807 1812 of all senders along the request/response chain. 1808 1813 </p> 1809 <div id="rfc.figure.u.5 6"></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 <div id="rfc.figure.u.58"></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> 1810 1815 <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> 1811 1816 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 1832 1837 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1833 1838 </p> 1834 <div id="rfc.figure.u.5 7"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)1839 <div id="rfc.figure.u.59"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1835 1840 </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. 1836 1841 </p> … … 1838 1843 For example, 1839 1844 </p> 1840 <div id="rfc.figure.u. 58"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy1845 <div id="rfc.figure.u.60"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1841 1846 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1842 <div id="rfc.figure.u. 59"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy1847 <div id="rfc.figure.u.61"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1843 1848 </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 1844 1849 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2452 2457 </p> 2453 2458 <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> 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 <p id="rfc.section.B.4.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a>) 2460 </p> 2461 <p id="rfc.section.B.4.p.2">Rules about implicit linear white space between certain grammar productions have been removed; now it's only allowed when 2455 2462 specifically pointed out in the ABNF. The NUL character is no longer allowed in comment and quoted-string text. The quoted-pair 2456 2463 rule no longer allows escaping NUL, CR or LF. Non-ASCII content in header fields and reason phrase has been obsoleted and 2457 2464 made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>) 2458 2465 </p> 2459 <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>)2460 </p> 2461 <p id="rfc.section.B.4.p. 3">Remove reference to non-existant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a> and <a href="#message.length" title="Message Length">4.4</a>)2462 </p> 2463 <p id="rfc.section.B.4.p. 4">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.3.1</a>)2464 </p> 2465 <p id="rfc.section.B.4.p. 5">Require that invalid whitespace around field-names be rejected. (<a href="#message.headers" title="Message Headers">Section 4.2</a>)2466 </p> 2467 <p id="rfc.section.B.4.p. 6">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-target" title="request-target">Section 5.1.2</a>)2468 </p> 2469 <p id="rfc.section.B.4.p. 7">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a>)2466 <p id="rfc.section.B.4.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section 3.1</a>) 2467 </p> 2468 <p id="rfc.section.B.4.p.4">Remove reference to non-existant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a> and <a href="#message.length" title="Message Length">4.4</a>) 2469 </p> 2470 <p id="rfc.section.B.4.p.5">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.3.1</a>) 2471 </p> 2472 <p id="rfc.section.B.4.p.6">Require that invalid whitespace around field-names be rejected. (<a href="#message.headers" title="Message Headers">Section 4.2</a>) 2473 </p> 2474 <p id="rfc.section.B.4.p.7">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-target" title="request-target">Section 5.1.2</a>) 2475 </p> 2476 <p id="rfc.section.B.4.p.8">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a>) 2470 2477 </p> 2471 2478 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="terminology" href="#terminology">Terminology</a></h1> … … 2766 2773 </li> 2767 2774 </ul> 2768 <p id="rfc.section.D.7.p.2">Other changes: </p> 2775 <p id="rfc.section.D.7.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 2776 </p> 2777 <ul> 2778 <li>Rewrite definition of list rules, deprecate empty list elements.</li> 2779 </ul> 2780 <p id="rfc.section.D.7.p.3">Other changes: </p> 2769 2781 <ul> 2770 2782 <li>Rewrite introduction; add mostly new Architecture Section.</li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r398 r400 347 347 A construct "#" is defined, similar to "*", for defining lists of 348 348 elements. The full form is "<n>#<m>element" indicating at least 349 <n> and at most <m> elements, each separated by one or more commas 350 (",") and &OPTIONAL; linear white space (OWS). This makes the usual 351 form of lists very easy; a rule such as 352 <figure><artwork type="example"> 353 ( *<x:ref>OWS</x:ref> element *( *<x:ref>OWS</x:ref> "," *<x:ref>OWS</x:ref> element ))</artwork></figure> 349 <n> and at most <m> elements, each separated by a single comma 350 (",") and optional whitespace (OWS). 354 351 </t> 352 <figure><preamble> 353 Thus, 354 </preamble><artwork type="example"> 355 1#element => element *( OWS "," OWS element ) 356 </artwork></figure> 357 <figure><preamble> 358 and: 359 </preamble><artwork type="example"> 360 #element => [ 1#element ] 361 </artwork></figure> 362 <figure><preamble> 363 and for n >= 1 and m > 1: 364 </preamble><artwork type="example"> 365 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 366 </artwork></figure> 355 367 <t> 356 can be shown as 357 <figure><artwork type="example"> 358 1#element</artwork></figure> 368 For compatibility with legacy list rules, recipients &SHOULD; accept empty 369 list elements. In other words, consumers would follow the list productions: 359 370 </t> 360 <t> 361 Wherever this construct is used, null elements are allowed, but do 362 not contribute to the count of elements present. That is, 363 "(element), , (element) " is permitted, but counts as only two 364 elements. Therefore, where at least one element is required, at 365 least one non-null element &MUST; be present. Default values are 0 366 and infinity so that "#element" allows any number, including zero; 367 "1#element" requires at least one; and "1#2element" allows one or 368 two. 369 </t> 371 <figure><artwork type="example"> 372 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 373 374 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 375 </artwork></figure> 370 376 <t> 371 377 <cref anchor="abnf.list"> … … 4082 4088 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 4083 4089 <t> 4090 Empty list elements in list productions have been deprecated. 4091 (<xref target="notation.abnf"/>) 4092 </t> 4093 <t> 4084 4094 Rules about implicit linear white space between certain grammar productions 4085 4095 have been removed; now it's only allowed when specifically pointed out … … 4696 4706 </t> 4697 4707 <t> 4708 Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): 4709 <list style="symbols"> 4710 <t> 4711 Rewrite definition of list rules, deprecate empty list elements. 4712 </t> 4713 </list> 4714 </t> 4715 <t> 4698 4716 Other changes: 4699 4717 <list style="symbols">
Note: See TracChangeset
for help on using the changeset viewer.
