Changeset 1064 for draft-ietf-httpbis/latest
- Timestamp:
- 27/10/10 09:52:38 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1062 r1064 731 731 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 732 732 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 733 <a href="#abnf.dependencies" class="smpl">authority</a> = <authority, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 734 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 735 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 736 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 737 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 738 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a>> 739 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>> 740 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 733 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 734 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 735 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 736 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 737 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a>> 738 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>> 739 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 741 740 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><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>> 742 741 <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> = … … 766 765 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>> 767 766 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 768 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.767 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 769 768 </p> 770 769 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#method" class="smpl">Method</a> = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 7.2</a> … … 806 805 to a single application, so that this is clear. 807 806 </p> 808 <p id="rfc.section.2.1.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message807 <p id="rfc.section.2.1.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message 809 808 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 810 809 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 825 824 / <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> 826 825 / <a href="#header.from" class="smpl">From</a> ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.3</a> 827 / <a href="#abnf.dependencies" class="smpl">Host</a> ; <a href="#Part1" id="rfc.xref.Part1. 20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a>826 / <a href="#abnf.dependencies" class="smpl">Host</a> ; <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> 828 827 / <a href="#abnf.dependencies" class="smpl">If-Match</a> ; <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a> 829 828 / <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a> ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a> … … 835 834 / <a href="#abnf.dependencies" class="smpl">Range</a> ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a> 836 835 / <a href="#header.referer" class="smpl">Referer</a> ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.6</a> 837 / <a href="#abnf.dependencies" class="smpl">TE</a> ; <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>836 / <a href="#abnf.dependencies" class="smpl">TE</a> ; <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a> 838 837 / <a href="#header.user-agent" class="smpl">User-Agent</a> ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.9</a> 839 838 </pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new … … 926 925 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 927 926 <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 928 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).927 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 929 928 </p> 930 929 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> … … 947 946 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 948 947 </p> 949 <p id="rfc.section.6.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied948 <p id="rfc.section.6.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied 950 949 to ensure safe and proper transfer of the message. 951 950 </p> … … 953 952 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 954 953 <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 955 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following954 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 956 955 rules are used (with the first applicable one being selected): 957 956 </p> … … 1136 1135 </p> 1137 1136 <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1138 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1137 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1139 1138 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1140 1139 infinite loop. 1141 1140 </p> 1142 <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1141 <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1143 1142 </p> 1144 1143 <div id="rfc.iref.c.1"></div> … … 1146 1145 <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> 1147 1146 <p id="rfc.section.7.9.p.1">The CONNECT method is used with a proxy to dynamically switch the connection to a tunnel.</p> 1148 <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> be an authority; i.e., the host name and port number destination of the requested connection separated by a colon: 1149 </p> 1150 <div id="rfc.figure.u.12"></div><pre class="text"> CONNECT server.example.com:80 HTTP/1.1 1151 Host: server.example.com:80 1147 <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> be use the authority form (<a href="p3-payload.html#request-target" title="ERROR: Anchor 'request-target' not found in p3-payload.xml.">Appendix ERROR: Anchor 'request-target' in Part3 not found in source file 'p3-payload.xml'.</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>); i.e., the host name and port number destination of the requested connection separated by a colon: 1148 </p> 1149 <div id="rfc.figure.u.12"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1150 Host: server.example.com:80 1151 1152 1152 </pre><p id="rfc.section.7.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method -- except end-to-end protocol Upgrade requests, since the 1153 1153 tunnel must be established first. 1154 1154 </p> 1155 1155 <p id="rfc.section.7.9.p.5">For example, proxy authentication might be used to establish the authority to create a tunnel:</p> 1156 <div id="rfc.figure.u.13"></div><pre class="text"> CONNECT server.example.com:80 HTTP/1.1 1157 Host: server.example.com:80 1158 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1156 <div id="rfc.figure.u.13"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1157 Host: server.example.com:80 1158 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1159 1159 1160 </pre><p id="rfc.section.7.9.p.7">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats 1160 1161 also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if … … 1194 1195 <p id="rfc.section.8.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1195 1196 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1196 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1197 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1197 1198 </p> 1198 1199 <div id="rfc.iref.26"></div> 1199 1200 <div id="rfc.iref.s.3"></div> 1200 1201 <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1201 <p id="rfc.section.8.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1202 <p id="rfc.section.8.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1202 1203 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1203 1204 </p> … … 1279 1280 another input action. 1280 1281 </p> 1281 <p id="rfc.section.8.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1282 <p id="rfc.section.8.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1282 1283 </p> 1283 1284 <div id="rfc.iref.33"></div> … … 1302 1303 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 1303 1304 <p id="rfc.section.8.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information 1304 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</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>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that1305 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 1305 1306 location. 1306 1307 </p> … … 1586 1587 <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1587 1588 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1588 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1. 30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.1589 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 1589 1590 </p> 1590 1591 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1628 1629 </p> 1629 1630 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 1630 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.1631 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 1631 1632 </p> 1632 1633 <div id="rfc.iref.f.1"></div> … … 1679 1680 </div> 1680 1681 <div class="note" id="rfc.section.9.4.p.9"> 1681 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.1 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.1682 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</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>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 1682 1683 It is therefore possible for a response to contain header fields for both Location and Content-Location. 1683 1684 </p> … … 1739 1740 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1740 1741 <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p> 1741 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for1742 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 1742 1743 identifying the application. 1743 1744 </p> … … 1747 1748 </pre><p id="rfc.section.9.8.p.4">Example:</p> 1748 1749 <div id="rfc.figure.u.29"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1749 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1750 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1750 1751 </p> 1751 1752 <div class="note" id="rfc.section.9.8.p.7"> … … 1763 1764 user agent limitations. 1764 1765 </p> 1765 <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance1766 <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 1766 1767 for identifying the application. 1767 1768 </p> … … 2354 2355 </p> 2355 2356 <p id="rfc.section.A.p.8">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 2356 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>)2357 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>) 2357 2358 </p> 2358 2359 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2436 2437 2437 2438 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in [Part1], Section 2.6> 2438 authority = <authority, defined in [Part1], Section 2.6>2439 2439 2440 2440 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in [Part1], Section 3.2> … … 2470 2470 <p>ABNF diagnostics:</p><pre class="inline">; Reason-Phrase defined but not used 2471 2471 ; Status-Code defined but not used 2472 ; authority defined but not used2473 2472 ; request-header defined but not used 2474 2473 ; response-header defined but not used … … 2841 2840 </li> 2842 2841 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2843 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17"> 1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">2</a>, <a class="iref" href="#rfc.xref.Part1.19">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a>, <a class="iref" href="#rfc.xref.Part1.21">3</a>, <a class="iref" href="#rfc.xref.Part1.22">5</a>, <a class="iref" href="#rfc.xref.Part1.23">6</a>, <a class="iref" href="#rfc.xref.Part1.24">6.1</a>, <a class="iref" href="#rfc.xref.Part1.25">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.28">8.1.2</a>, <a class="iref" href="#rfc.xref.Part1.29">8.2.6</a>, <a class="iref" href="#rfc.xref.Part1.30">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.31">9.2</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.8</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a>, <a class="iref" href="#rfc.xref.Part1.36">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.37">A</a><ul class="ind">2842 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a>, <a class="iref" href="#rfc.xref.Part1.21">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6</a>, <a class="iref" href="#rfc.xref.Part1.23">6.1</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">8.1.2</a>, <a class="iref" href="#rfc.xref.Part1.28">8.2.6</a>, <a class="iref" href="#rfc.xref.Part1.29">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.30">9.2</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.9</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.36">A</a><ul class="ind"> 2844 2843 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2</a></li> 2845 2844 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li> 2846 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1. 30">8.5.6</a></li>2847 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.1 0">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">1.2.2</a></li>2848 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.1 1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.36">9.9</a></li>2849 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.1 9">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">6</a>, <a class="iref" href="#rfc.xref.Part1.29">8.2.6</a></li>2850 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.1 8">2</a>, <a class="iref" href="#rfc.xref.Part1.22">5</a>, <a class="iref" href="#rfc.xref.Part1.24">6.1</a></li>2851 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.1 3">1.2.2</a></li>2852 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.1 5">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a></li>2853 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.2 7">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.31">9.2</a></li>2854 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1. 20">3</a></li>2855 <li class="indline1"><em>Section 9.5</em> <a class="iref" href="#rfc.xref.Part1.1 6">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.21">3</a></li>2856 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.2 8">8.1.2</a></li>2857 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.2 5">7.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.8</a>, <a class="iref" href="#rfc.xref.Part1.37">A</a></li>2858 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.2 6">7.8</a></li>2845 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.29">8.5.6</a></li> 2846 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li> 2847 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a></li> 2848 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.18">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.22">6</a>, <a class="iref" href="#rfc.xref.Part1.28">8.2.6</a></li> 2849 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.21">5</a>, <a class="iref" href="#rfc.xref.Part1.23">6.1</a></li> 2850 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li> 2851 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.9</a></li> 2852 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.26">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.30">9.2</a></li> 2853 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1.19">3</a></li> 2854 <li class="indline1"><em>Section 9.5</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a></li> 2855 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.27">8.1.2</a></li> 2856 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.36">A</a></li> 2857 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.25">7.8</a></li> 2859 2858 </ul> 2860 2859 </li> 2861 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind"> 2862 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li> 2860 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.11">7.9</a>, <a class="iref" href="#rfc.xref.Part3.12">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.13">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind"> 2861 <li class="indline1"><em>Appendix </em> <a class="iref" href="#rfc.xref.Part3.11">7.9</a></li> 2862 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.12">8.3.1</a></li> 2863 2863 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li> 2864 2864 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li> 2865 2865 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li> 2866 2866 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li> 2867 <li class="indline1"><em>Section 6.7</em> <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.1 2">9.4</a></li>2867 <li class="indline1"><em>Section 6.7</em> <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.13">9.4</a></li> 2868 2868 </ul> 2869 2869 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1062 r1064 33 33 <!ENTITY use100 "<xref target='Part1' x:rel='#use.of.the.100.status' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 34 34 <!ENTITY qvalue "<xref target='Part3' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 <!ENTITY request-target "<xref target='Part3' x:rel='#request-target' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 36 <!ENTITY header-accept "<xref target='Part3' x:rel='#header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 37 <!ENTITY header-accept-charset "<xref target='Part3' x:rel='#header.accept-charset' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 347 348 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> 348 349 <x:anchor-alias value="absolute-URI"/> 349 <x:anchor-alias value="authority"/>350 350 <x:anchor-alias value="Accept"/> 351 351 <x:anchor-alias value="Accept-Charset"/> … … 378 378 <figure><!--Part1--><artwork type="abnf2616"> 379 379 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 380 <x:ref>authority</x:ref> = <authority, defined in &uri;>381 380 <x:ref>comment</x:ref> = <comment, defined in &header-fields;> 382 381 <x:ref>Host</x:ref> = <Host, defined in &uri;> … … 1149 1148 </t> 1150 1149 <t> 1151 When using CONNECT, the request-target &MUST; be an authority; i.e.,1152 the host name and port number destination of the requested connection1153 separated by a colon:1154 </t> 1155 1156 <figure><artwork type="example"> 1157 CONNECT server.example.com:80 HTTP/1.1 1158 Host: server.example.com:80 1150 When using CONNECT, the request-target &MUST; be use the authority form 1151 (&request-target;); i.e., the host name and port number destination of the 1152 requested connection separated by a colon: 1153 </t> 1154 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 1155 CONNECT server.example.com:80 HTTP/1.1 1156 Host: server.example.com:80 1157 1159 1158 </artwork></figure> 1160 1161 1159 <t> 1162 1160 Other HTTP mechanisms can be used normally with the CONNECT method -- … … 1168 1166 authority to create a tunnel: 1169 1167 </t> 1170 1171 <figure><artwork type="example"> 1172 CONNECT server.example.com:80 HTTP/1.1 1173 Host: server.example.com:80 1174 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1168 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 1169 CONNECT server.example.com:80 HTTP/1.1 1170 Host: server.example.com:80 1171 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1172 1175 1173 </artwork></figure> 1176 1177 1174 <t> 1178 1175 Like any other pipelined HTTP/1.1 request, data to be tunnel may be … … 3558 3555 3559 3556 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in [Part1], Section 2.6> 3560 authority = <authority, defined in [Part1], Section 2.6>3561 3557 3562 3558 <x:ref>comment</x:ref> = <comment, defined in [Part1], Section 3.2> … … 3594 3590 ; Reason-Phrase defined but not used 3595 3591 ; Status-Code defined but not used 3596 ; authority defined but not used3597 3592 ; request-header defined but not used 3598 3593 ; response-header defined but not used
Note: See TracChangeset
for help on using the changeset viewer.