Changeset 1580
- Timestamp:
- 11/03/12 05:43:44 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1576 r1580 668 668 <li>3. <a href="#http.message">Message Format</a><ul> 669 669 <li>3.1 <a href="#start.line">Start Line</a><ul> 670 <li>3.1.1 <a href="#request.line">Request Line</a><ul> 671 <li>3.1.1.1 <a href="#method">Method</a></li> 672 <li>3.1.1.2 <a href="#request-target">Request Target</a></li> 673 </ul> 674 </li> 675 <li>3.1.2 <a href="#status.line">Response Status Line</a><ul> 676 <li>3.1.2.1 <a href="#status.code">Status Code</a></li> 677 <li>3.1.2.2 <a href="#reason.phrase">Reason Phrase</a></li> 678 </ul> 679 </li> 670 <li>3.1.1 <a href="#request.line">Request Line</a></li> 671 <li>3.1.2 <a href="#status.line">Status Line</a></li> 680 672 </ul> 681 673 </li> … … 717 709 <li>5.1 <a href="#target-resource">Identifying a Target Resource</a></li> 718 710 <li>5.2 <a href="#connecting.inbound">Connecting Inbound</a></li> 719 <li>5.3 <a href="#request-target -types">Types ofRequest Target</a></li>711 <li>5.3 <a href="#request-target">Request Target</a></li> 720 712 <li>5.4 <a href="#header.host">Host</a></li> 721 713 <li>5.5 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> … … 925 917 </p> 926 918 <p id="rfc.section.2.1.p.7">A server responds to the client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason 927 phrase (<a href="#status.line" title=" ResponseStatus Line">Section 3.1.2</a>), possibly followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>).919 phrase (<a href="#status.line" title="Status Line">Section 3.1.2</a>), possibly followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 928 920 </p> 929 921 <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> … … 1247 1239 </p> 1248 1240 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.27"></span> <a href="#request.line" class="smpl">request-line</a> = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a> 1249 </pre><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a> <a id="method" href="#method">Method</a></h4> 1250 <p id="rfc.section.3.1.1.1.p.1">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1241 </pre><div id="rfc.iref.m.2"></div> 1242 <div id="method"> 1243 <p id="rfc.section.3.1.1.p.3">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1244 </div> 1251 1245 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1252 </pre><p id="rfc.section.3.1.1.1.p.3">The methods defined by this specification can be found in <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1253 </p> 1254 <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a id="request-target" href="#request-target">Request Target</a></h4> 1255 <p id="rfc.section.3.1.1.2.p.1">The request-target identifies the target resource upon which to apply the request. The four options for request-target are 1256 described in <a href="#request-target-types" title="Types of Request Target">Section 5.3</a>. 1257 </p> 1258 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1259 / <a href="#uri" class="smpl">absolute-URI</a> 1260 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) 1261 / <a href="#uri" class="smpl">authority</a> 1262 </pre><p id="rfc.section.3.1.1.2.p.3">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1246 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1247 </p> 1248 <div id="rfc.iref.r.6"></div> 1249 <p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section 5.3</a>. 1250 </p> 1251 <p id="rfc.section.3.1.1.p.7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line 1252 into its component parts by splitting on the SP characters. 1253 </p> 1254 <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters 1255 directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. 1256 Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately 1257 crafted to bypass security filters along the request chain. 1258 </p> 1259 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1260 it implements <em class="bcp14">SHOULD</em> respond with either a 404 (Not Allowed), if it is an origin server, or a 501 (Not Implemented) status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1263 1261 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1264 1262 </p> 1265 <p id="rfc.section.3.1.1.2.p.4">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets. 1266 </p> 1267 <div class="note" id="rfc.section.3.1.1.2.p.5"> 1268 <p> <b>Note:</b> Fragments (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>) are not part of the request-target and thus will not be transmitted in an HTTP request. 1269 </p> 1270 </div> 1271 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="status.line" href="#status.line">Response Status Line</a></h3> 1263 <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets. 1264 </p> 1265 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="status.line" href="#status.line">Status Line</a></h3> 1272 1266 <p id="rfc.section.3.1.2.p.1">The first line of a response message is the status-line, consisting of the protocol version, a space (SP), the status code, 1273 1267 another space, a possibly-empty textual phrase describing the status code, and ending with CRLF. 1274 1268 </p> 1275 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1276 </pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a> <a id="status.code" href="#status.code">Status Code</a></h4> 1277 <p id="rfc.section.3.1.2.1.p.1">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1278 for new status codes. 1279 </p> 1280 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#status.code" class="smpl">status-code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1281 </pre><h4 id="rfc.section.3.1.2.2"><a href="#rfc.section.3.1.2.2">3.1.2.2</a> <a id="reason.phrase" href="#reason.phrase">Reason Phrase</a></h4> 1282 <p id="rfc.section.3.1.2.2.p.1">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status 1283 code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text 1284 clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content. 1285 </p> 1286 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#reason.phrase" class="smpl">reason-phrase</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1269 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status-code" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason-phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1270 </pre><div id="status-code"> 1271 <p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1272 for new status codes. 1273 </p> 1274 </div> 1275 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status-code" class="smpl">status-code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1276 </pre><div id="reason-phrase"> 1277 <p id="rfc.section.3.1.2.p.5">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status 1278 code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text 1279 clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content. 1280 </p> 1281 </div> 1282 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#reason-phrase" class="smpl">reason-phrase</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1287 1283 </pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.fields" href="#header.fields">Header Fields</a></h2> 1288 1284 <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field 1289 1285 value. 1290 1286 </p> 1291 <div id="rfc.figure.u.1 9"></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> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">BWS</a>1287 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">BWS</a> 1292 1288 <a href="#header.fields" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1293 1289 <a href="#header.fields" class="smpl">field-value</a> = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#header.fields" class="smpl">obs-fold</a> ) … … 1346 1342 <p id="rfc.section.3.2.1.p.5"> </p> 1347 1343 </div> 1348 <div id="rfc.figure.u. 20"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )1344 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) 1349 1345 ; "optional" whitespace 1350 1346 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) … … 1382 1378 </p> 1383 1379 </div> 1384 <div id="rfc.figure.u.2 1"></div><pre class="inline"><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="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>1380 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span> <a href="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> 1385 1381 1386 1382 <a href="#rule.token.separators" class="smpl">token</a> = 1*<a href="#rule.token.separators" class="smpl">tchar</a> … … 1397 1393 <p id="rfc.section.3.2.4.p.3"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 1398 1394 </div> 1399 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></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>1395 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span> <a href="#rule.quoted-string" class="smpl">quoted-string</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> 1400 1396 <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> 1401 1397 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF … … 1403 1399 <p id="rfc.section.3.2.4.p.5"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p> 1404 1400 </div> 1405 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )1401 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1406 1402 </pre><p id="rfc.section.3.2.4.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 1407 1403 </p> … … 1413 1409 </p> 1414 1410 </div> 1415 <div id="rfc.figure.u.2 4"></div><pre class="inline"><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"1411 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1416 1412 <a href="#rule.comment" class="smpl">ctext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1417 1413 </pre><div id="rule.quoted-cpair"> 1418 1414 <p id="rfc.section.3.2.4.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> 1419 1415 </div> 1420 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )1416 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1421 1417 </pre><p id="rfc.section.3.2.4.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and 1422 1418 ")"). … … 1428 1424 indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS). 1429 1425 </p> 1430 <div id="rfc.figure.u.2 6"></div>1426 <div id="rfc.figure.u.25"></div> 1431 1427 <p>Thus,</p><pre class="text"> 1#element => element *( OWS "," OWS element ) 1428 </pre><div id="rfc.figure.u.26"></div> 1429 <p>and:</p><pre class="text"> #element => [ 1#element ] 1432 1430 </pre><div id="rfc.figure.u.27"></div> 1433 <p>and:</p><pre class="text"> #element => [ 1#element ]1434 </pre><div id="rfc.figure.u.28"></div>1435 1431 <p>and for n >= 1 and m > 1:</p><pre class="text"> <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 1436 1432 </pre><p id="rfc.section.3.2.5.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions: 1437 1433 </p> 1438 <div id="rfc.figure.u.2 9"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]1434 <div id="rfc.figure.u.28"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 1439 1435 1440 1436 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 1441 1437 </pre><p id="rfc.section.3.2.5.p.8">Note that empty elements do not contribute to the count of elements present, though.</p> 1442 1438 <p id="rfc.section.3.2.5.p.9">For example, given these ABNF productions:</p> 1443 <div id="rfc.figure.u. 30"></div><pre class="text"> example-list = 1#example-list-elmt1439 <div id="rfc.figure.u.29"></div><pre class="text"> example-list = 1#example-list-elmt 1444 1440 example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section 3.2.4</a> 1445 1441 </pre><p id="rfc.section.3.2.5.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p> 1446 <div id="rfc.figure.u.3 1"></div><pre class="text"> "foo,bar"1442 <div id="rfc.figure.u.30"></div><pre class="text"> "foo,bar" 1447 1443 "foo ,bar," 1448 1444 "foo , ,bar,charlie " 1449 1445 </pre><p id="rfc.section.3.2.5.p.13">But these values would be invalid, as at least one non-empty element is required:</p> 1450 <div id="rfc.figure.u.3 2"></div><pre class="text"> ""1446 <div id="rfc.figure.u.31"></div><pre class="text"> "" 1451 1447 "," 1452 1448 ", ," … … 1457 1453 is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>. 1458 1454 </p> 1459 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET1455 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET 1460 1456 </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p> 1461 1457 <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a Content-Length or Transfer-Encoding header field. Request message … … 1463 1459 </p> 1464 1460 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 1465 status code (<a href="#status .code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,1461 status code (<a href="#status-code">Paragraph 3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., 1466 1462 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1467 1463 Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), 204 … … 1475 1471 in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. 1476 1472 </p> 1477 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>1473 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1478 1474 </pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport 1479 1475 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is … … 1485 1481 applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. 1486 1482 </p> 1487 <div id="rfc.figure.u.3 5"></div>1483 <div id="rfc.figure.u.34"></div> 1488 1484 <p>For example,</p><pre class="text"> Transfer-Encoding: gzip, chunked 1489 1485 </pre><p>indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while … … 1513 1509 number of octets. 1514 1510 </p> 1515 <div id="rfc.figure.u.3 6"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>1511 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1516 1512 </pre><p id="rfc.section.3.3.2.p.3">An example is</p> 1517 <div id="rfc.figure.u.3 7"></div><pre class="text"> Content-Length: 34951513 <div id="rfc.figure.u.36"></div><pre class="text"> Content-Length: 3495 1518 1514 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential 1519 1515 transfer-coding) that would have been sent had the request been a GET. In the case of a 304 (Not Modified) response to a GET … … 1637 1633 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1638 1634 </p> 1639 <div id="rfc.figure.u.3 8"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>1635 <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> 1640 1636 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 4.2.1</a> 1641 1637 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a> … … 1646 1642 <p id="rfc.section.4.p.3"> Parameters are in the form of attribute/value pairs.</p> 1647 1643 </div> 1648 <div id="rfc.figure.u.3 9"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1644 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1649 1645 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1650 1646 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> … … 1658 1654 for the recipient to verify that it has received the full message. 1659 1655 </p> 1660 <div id="rfc.figure.u. 40"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#chunked.encoding" class="smpl">chunked-body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1656 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> <a href="#chunked.encoding" class="smpl">chunked-body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1661 1657 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1662 1658 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1700 1696 </p> 1701 1697 <p id="rfc.section.4.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1702 <div id="rfc.figure.u.4 1"></div><pre class="text"> length := 01698 <div id="rfc.figure.u.40"></div><pre class="text"> length := 0 1703 1699 read chunk-size, chunk-ext (if any) and CRLF 1704 1700 while (chunk-size > 0) { … … 1745 1741 </p> 1746 1742 </div> 1747 <div id="rfc.iref.g.7 3"></div>1743 <div id="rfc.iref.g.72"></div> 1748 1744 <div id="rfc.iref.c.12"></div> 1749 1745 <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h3> … … 1774 1770 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1775 1771 </p> 1776 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>1772 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 1777 1773 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) 1778 1774 <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> ) … … 1782 1778 </p> 1783 1779 <p id="rfc.section.4.4.p.5">Examples of its use are:</p> 1784 <div id="rfc.figure.u.4 3"></div><pre class="text"> TE: deflate1780 <div id="rfc.figure.u.42"></div><pre class="text"> TE: deflate 1785 1781 TE: 1786 1782 TE: trailers, deflate;q=0.5 … … 1818 1814 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 1819 1815 </p> 1820 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1816 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1821 1817 / ( "1" [ "." 0*3("0") ] ) 1822 1818 </pre><div class="note" id="rfc.section.4.4.1.p.3"> … … 1830 1826 chunked transfer-coding. 1831 1827 </p> 1832 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.79"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>1828 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 1833 1829 </pre><p id="rfc.section.4.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 1834 1830 to know which header fields to expect in the trailer. … … 1848 1844 back to the client. 1849 1845 </p> 1846 <div id="rfc.iref.t.7"></div> 1847 <div id="rfc.iref.t.8"></div> 1850 1848 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="target-resource" href="#target-resource">Identifying a Target Resource</a></h2> 1851 1849 <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, … … 1856 1854 are defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the target resource, which a user agent would resolve to its absolute form in order 1857 1855 to obtain the target URI. The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers 1858 are for client-side processing only.1856 are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). 1859 1857 </p> 1860 1858 <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p> … … 1875 1873 the "http" (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) schemes. 1876 1874 </p> 1877 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2> 1878 <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>), depending on both the method being requested and whether the request is to a proxy. 1879 </p> 1880 <div id="origin-form"> 1881 <p id="rfc.section.5.3.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a 1875 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="request-target" href="#request-target">Request Target</a></h2> 1876 <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained (<a href="#connections" title="Connections">Section 6</a>), the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on 1877 both the method being requested and whether the request is to a proxy. 1878 </p> 1879 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.79"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1880 / <a href="#uri" class="smpl">absolute-URI</a> 1881 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) 1882 / <a href="#uri" class="smpl">authority</a> 1883 </pre><div id="origin-form"> 1884 <p id="rfc.section.5.3.p.3"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a 1882 1885 resource identified by an "http" (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) URI. In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target and the authority component (excluding any userinfo) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource identified 1883 1886 as … … 1885 1888 </div> 1886 1889 <div id="rfc.figure.u.46"></div><pre>http://www.example.org/where?q=now 1887 </pre><p id="rfc.section.5.3.p. 4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the1890 </pre><p id="rfc.section.5.3.p.5">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the 1888 1891 lines: 1889 1892 </p> 1890 1893 <div id="rfc.figure.u.47"></div><pre class="text2">GET /where?q=now HTTP/1.1 1891 1894 Host: www.example.org 1892 </pre><p id="rfc.section.5.3.p. 6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.1895 </pre><p id="rfc.section.5.3.p.7">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path. 1893 1896 If the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target. 1894 1897 </p> 1895 <p id="rfc.section.5.3.p. 7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.1898 <p id="rfc.section.5.3.p.8">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1896 1899 </p> 1897 1900 <div id="absolute-URI-form"> 1898 <p id="rfc.section.5.3.p. 8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid1901 <p id="rfc.section.5.3.p.9"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid 1899 1902 cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request 1900 1903 loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses. … … 1903 1906 </div> 1904 1907 <div id="rfc.figure.u.48"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1905 </pre><p id="rfc.section.5.3.p.1 0">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.1906 </p> 1907 <p id="rfc.section.5.3.p.1 1">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.1908 </pre><p id="rfc.section.5.3.p.11">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. 1909 </p> 1910 <p id="rfc.section.5.3.p.12">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1908 1911 </p> 1909 1912 <div id="authority-form"> 1910 <p id="rfc.section.5.3.p.1 2"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,1913 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example, 1911 1914 </p> 1912 1915 </div> 1913 1916 <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1914 1917 </pre><div id="asterix-form"> 1915 <p id="rfc.section.5.3.p.1 4"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening1918 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening 1916 1919 process) rather than to a specific named resource at that server. For example, 1917 1920 </p> 1918 1921 </div> 1919 1922 <div id="rfc.figure.u.50"></div><pre class="text2">OPTIONS * HTTP/1.1 1920 </pre><p id="rfc.section.5.3.p.1 6">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and1923 </pre><p id="rfc.section.5.3.p.17">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and 1921 1924 no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server. 1922 1925 </p> … … 1927 1930 Host: www.example.org:8001 1928 1931 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> 1929 <p id="rfc.section.5.3.p. 19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,1932 <p id="rfc.section.5.3.p.20">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1930 1933 except as noted above to replace a null path-absolute with "/" or "*". 1931 1934 </p> … … 1982 1985 </p> 1983 1986 <div id="rfc.iref.e.1"></div> 1984 <div id="rfc.iref.t.7"></div>1985 1987 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 1986 1988 <p id="rfc.section.5.6.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><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>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection … … 2569 2571 is to be registered with IANA (see <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>). 2570 2572 </p> 2571 <div id="rfc.iref.m.2"></div>2572 2573 <div id="rfc.iref.m.3"></div> 2574 <div id="rfc.iref.m.4"></div> 2573 2575 <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a> <a id="internet.media.type.message.http" href="#internet.media.type.message.http">Internet Media Type message/http</a></h3> 2574 2576 <p id="rfc.section.9.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions … … 2624 2626 <dd>IESG</dd> 2625 2627 </dl> 2626 <div id="rfc.iref.m. 4"></div>2628 <div id="rfc.iref.m.5"></div> 2627 2629 <div id="rfc.iref.a.5"></div> 2628 2630 <h3 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a> <a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3> … … 2804 2806 a Denial of Service against implementations that accept fields with unlimited lengths. 2805 2807 </p> 2806 <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section 3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected2808 <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section 3.1.1</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section 3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected 2807 2809 that most implementations will choose substantially higher limits. 2808 2810 </p> … … 3075 3077 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3076 3078 <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3> 3077 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section 5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.3079 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section 5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section 5.3</a>) are among the most important changes defined by HTTP/1.1. 3078 3080 </p> 3079 3081 <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism … … 3107 3109 </p> 3108 3110 <p id="rfc.section.A.2.p.2">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk 3109 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="Request Target">Section 3.1.1.2</a>)3111 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="Request Target">Section 5.3</a>) 3110 3112 </p> 3111 3113 <p id="rfc.section.A.2.p.3">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) … … 3228 3230 <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3229 3231 3230 <a href="#reason .phrase" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text )3232 <a href="#reason-phrase" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text ) 3231 3233 <a href="#header.via" class="smpl">received-by</a> = ( uri-host [ ":" port ] ) / pseudonym 3232 3234 <a href="#header.via" class="smpl">received-protocol</a> = [ protocol-name "/" ] protocol-version … … 3239 3241 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3240 3242 <a href="#http.message" class="smpl">start-line</a> = request-line / status-line 3241 <a href="#status .code" class="smpl">status-code</a> = 3DIGIT3243 <a href="#status-code" class="smpl">status-code</a> = 3DIGIT 3242 3244 <a href="#status.line" class="smpl">status-line</a> = HTTP-version SP status-code SP reason-phrase CRLF 3243 3245 … … 3713 3715 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.7</b></a></li> 3714 3716 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3715 <li><tt>attribute</tt> <a href="#rfc.iref.g.5 8"><b>4</b></a></li>3717 <li><tt>attribute</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3716 3718 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3717 <li><tt>BWS</tt> <a href="#rfc.iref.g. 40"><b>3.2.1</b></a></li>3718 <li><tt>chunk</tt> <a href="#rfc.iref.g.6 3"><b>4.1</b></a></li>3719 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.6 9"><b>4.1</b></a></li>3720 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.6 6"><b>4.1</b></a></li>3721 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.6 7"><b>4.1</b></a></li>3722 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.6 8"><b>4.1</b></a></li>3723 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.6 4"><b>4.1</b></a></li>3724 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.6 2"><b>4.1</b></a></li>3725 <li><tt>comment</tt> <a href="#rfc.iref.g.4 9"><b>3.2.4</b></a></li>3719 <li><tt>BWS</tt> <a href="#rfc.iref.g.39"><b>3.2.1</b></a></li> 3720 <li><tt>chunk</tt> <a href="#rfc.iref.g.62"><b>4.1</b></a></li> 3721 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.68"><b>4.1</b></a></li> 3722 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.65"><b>4.1</b></a></li> 3723 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.66"><b>4.1</b></a></li> 3724 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.67"><b>4.1</b></a></li> 3725 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.63"><b>4.1</b></a></li> 3726 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.61"><b>4.1</b></a></li> 3727 <li><tt>comment</tt> <a href="#rfc.iref.g.48"><b>3.2.4</b></a></li> 3726 3728 <li><tt>Connection</tt> <a href="#rfc.iref.g.81"><b>8.1</b></a></li> 3727 3729 <li><tt>connection-token</tt> <a href="#rfc.iref.g.82"><b>8.1</b></a></li> 3728 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.5 4"><b>3.3.2</b></a></li>3730 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.53"><b>3.3.2</b></a></li> 3729 3731 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3730 3732 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3731 <li><tt>ctext</tt> <a href="#rfc.iref.g. 50"><b>3.2.4</b></a></li>3733 <li><tt>ctext</tt> <a href="#rfc.iref.g.49"><b>3.2.4</b></a></li> 3732 3734 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3733 <li><tt>date2</tt> <a href="#rfc.iref.g. 60"><b>4</b></a></li>3734 <li><tt>date3</tt> <a href="#rfc.iref.g.6 1"><b>4</b></a></li>3735 <li><tt>date2</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3736 <li><tt>date3</tt> <a href="#rfc.iref.g.60"><b>4</b></a></li> 3735 3737 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3736 3738 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> 3737 <li><tt>field-content</tt> <a href="#rfc.iref.g.3 6"><b>3.2</b></a></li>3738 <li><tt>field-name</tt> <a href="#rfc.iref.g.3 4"><b>3.2</b></a></li>3739 <li><tt>field-value</tt> <a href="#rfc.iref.g.3 5"><b>3.2</b></a></li>3740 <li><tt>header-field</tt> <a href="#rfc.iref.g.3 3"><b>3.2</b></a></li>3739 <li><tt>field-content</tt> <a href="#rfc.iref.g.35"><b>3.2</b></a></li> 3740 <li><tt>field-name</tt> <a href="#rfc.iref.g.33"><b>3.2</b></a></li> 3741 <li><tt>field-value</tt> <a href="#rfc.iref.g.34"><b>3.2</b></a></li> 3742 <li><tt>header-field</tt> <a href="#rfc.iref.g.32"><b>3.2</b></a></li> 3741 3743 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3742 3744 <li><tt>Host</tt> <a href="#rfc.iref.g.80"><b>5.4</b></a></li> … … 3747 3749 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2.6</b></a></li> 3748 3750 <li><tt>https-URI</tt> <a href="#rfc.iref.g.24"><b>2.7.2</b></a></li> 3749 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.6 5"><b>4.1</b></a></li>3751 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.64"><b>4.1</b></a></li> 3750 3752 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3751 <li><tt>message-body</tt> <a href="#rfc.iref.g.5 2"><b>3.3</b></a></li>3752 <li><tt>method</tt> <a href="#rfc.iref.g.28"><b>3.1.1 .1</b></a></li>3753 <li><tt>obs-fold</tt> <a href="#rfc.iref.g.3 7"><b>3.2</b></a></li>3754 <li><tt>obs-text</tt> <a href="#rfc.iref.g.4 7"><b>3.2.4</b></a></li>3753 <li><tt>message-body</tt> <a href="#rfc.iref.g.51"><b>3.3</b></a></li> 3754 <li><tt>method</tt> <a href="#rfc.iref.g.28"><b>3.1.1</b></a></li> 3755 <li><tt>obs-fold</tt> <a href="#rfc.iref.g.36"><b>3.2</b></a></li> 3756 <li><tt>obs-text</tt> <a href="#rfc.iref.g.46"><b>3.2.4</b></a></li> 3755 3757 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3756 <li><tt>OWS</tt> <a href="#rfc.iref.g.3 8"><b>3.2.1</b></a></li>3758 <li><tt>OWS</tt> <a href="#rfc.iref.g.37"><b>3.2.1</b></a></li> 3757 3759 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3758 3760 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> … … 3760 3762 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.87"><b>8.3</b></a></li> 3761 3763 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.89"><b>8.3</b></a></li> 3762 <li><tt>qdtext</tt> <a href="#rfc.iref.g.4 6"><b>3.2.4</b></a></li>3763 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.7 2"><b>4.1</b></a></li>3764 <li><tt>qdtext</tt> <a href="#rfc.iref.g.45"><b>3.2.4</b></a></li> 3765 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a></li> 3764 3766 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3765 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.5 1"><b>3.2.4</b></a></li>3766 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.4 8"><b>3.2.4</b></a></li>3767 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.7 1"><b>4.1</b></a></li>3768 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.4 5"><b>3.2.4</b></a></li>3769 <li><tt>qvalue</tt> <a href="#rfc.iref.g.7 8"><b>4.4.1</b></a></li>3770 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.3 2"><b>3.1.2.2</b></a></li>3767 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.50"><b>3.2.4</b></a></li> 3768 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.47"><b>3.2.4</b></a></li> 3769 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a></li> 3770 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.44"><b>3.2.4</b></a></li> 3771 <li><tt>qvalue</tt> <a href="#rfc.iref.g.77"><b>4.4.1</b></a></li> 3772 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.31"><b>3.1.2</b></a></li> 3771 3773 <li><tt>received-by</tt> <a href="#rfc.iref.g.88"><b>8.3</b></a></li> 3772 3774 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.85"><b>8.3</b></a></li> 3773 3775 <li><tt>request-line</tt> <a href="#rfc.iref.g.27"><b>3.1.1</b></a></li> 3774 <li><tt>request-target</tt> <a href="#rfc.iref.g. 29"><b>3.1.1.2</b></a></li>3775 <li><tt>RWS</tt> <a href="#rfc.iref.g.3 9"><b>3.2.1</b></a></li>3776 <li><tt>request-target</tt> <a href="#rfc.iref.g.79"><b>5.3</b></a></li> 3777 <li><tt>RWS</tt> <a href="#rfc.iref.g.38"><b>3.2.1</b></a></li> 3776 3778 <li>SP <a href="#rfc.iref.g.11"><b>1.2</b></a></li> 3777 <li><tt>special</tt> <a href="#rfc.iref.g.4 4"><b>3.2.4</b></a></li>3779 <li><tt>special</tt> <a href="#rfc.iref.g.43"><b>3.2.4</b></a></li> 3778 3780 <li><tt>start-line</tt> <a href="#rfc.iref.g.26"><b>3.1</b></a></li> 3779 <li><tt>status-code</tt> <a href="#rfc.iref.g.3 1"><b>3.1.2.1</b></a></li>3780 <li><tt>status-line</tt> <a href="#rfc.iref.g. 30"><b>3.1.2</b></a></li>3781 <li><tt>t-codings</tt> <a href="#rfc.iref.g.7 5"><b>4.4</b></a></li>3782 <li><tt>tchar</tt> <a href="#rfc.iref.g.4 3"><b>3.2.4</b></a></li>3783 <li><tt>TE</tt> <a href="#rfc.iref.g.7 4"><b>4.4</b></a></li>3784 <li><tt>te-ext</tt> <a href="#rfc.iref.g.7 7"><b>4.4</b></a></li>3785 <li><tt>te-params</tt> <a href="#rfc.iref.g.7 6"><b>4.4</b></a></li>3786 <li><tt>token</tt> <a href="#rfc.iref.g.4 2"><b>3.2.4</b></a></li>3787 <li><tt>Trailer</tt> <a href="#rfc.iref.g.7 9"><b>4.5</b></a></li>3788 <li><tt>trailer-part</tt> <a href="#rfc.iref.g. 70"><b>4.1</b></a></li>3789 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.5 5"><b>4</b></a></li>3790 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.5 3"><b>3.3.1</b></a></li>3791 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.5 6"><b>4</b></a></li>3792 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.5 7"><b>4</b></a></li>3781 <li><tt>status-code</tt> <a href="#rfc.iref.g.30"><b>3.1.2</b></a></li> 3782 <li><tt>status-line</tt> <a href="#rfc.iref.g.29"><b>3.1.2</b></a></li> 3783 <li><tt>t-codings</tt> <a href="#rfc.iref.g.74"><b>4.4</b></a></li> 3784 <li><tt>tchar</tt> <a href="#rfc.iref.g.42"><b>3.2.4</b></a></li> 3785 <li><tt>TE</tt> <a href="#rfc.iref.g.73"><b>4.4</b></a></li> 3786 <li><tt>te-ext</tt> <a href="#rfc.iref.g.76"><b>4.4</b></a></li> 3787 <li><tt>te-params</tt> <a href="#rfc.iref.g.75"><b>4.4</b></a></li> 3788 <li><tt>token</tt> <a href="#rfc.iref.g.41"><b>3.2.4</b></a></li> 3789 <li><tt>Trailer</tt> <a href="#rfc.iref.g.78"><b>4.5</b></a></li> 3790 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.69"><b>4.1</b></a></li> 3791 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.54"><b>4</b></a></li> 3792 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.52"><b>3.3.1</b></a></li> 3793 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.55"><b>4</b></a></li> 3794 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3793 3795 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.83"><b>8.2</b></a></li> 3794 3796 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3795 3797 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3796 <li><tt>value</tt> <a href="#rfc.iref.g.5 9"><b>4</b></a></li>3798 <li><tt>value</tt> <a href="#rfc.iref.g.58"><b>4</b></a></li> 3797 3799 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3798 3800 <li><tt>Via</tt> <a href="#rfc.iref.g.84"><b>8.3</b></a></li> 3799 <li><tt>word</tt> <a href="#rfc.iref.g.4 1"><b>3.2.4</b></a></li>3801 <li><tt>word</tt> <a href="#rfc.iref.g.40"><b>3.2.4</b></a></li> 3800 3802 </ul> 3801 3803 </li> 3802 <li>gzip (Coding Format) <a href="#rfc.iref.g.7 3">4.2.3</a></li>3804 <li>gzip (Coding Format) <a href="#rfc.iref.g.72">4.2.3</a></li> 3803 3805 </ul> 3804 3806 </li> … … 3838 3840 <li>Media Type 3839 3841 <ul> 3840 <li>application/http <a href="#rfc.iref.m. 4"><b>9.3.2</b></a></li>3841 <li>message/http <a href="#rfc.iref.m. 2"><b>9.3.1</b></a></li>3842 <li>application/http <a href="#rfc.iref.m.5"><b>9.3.2</b></a></li> 3843 <li>message/http <a href="#rfc.iref.m.3"><b>9.3.1</b></a></li> 3842 3844 </ul> 3843 3845 </li> 3844 3846 <li>message <a href="#rfc.iref.m.1"><b>2.1</b></a></li> 3845 <li>message/http Media Type <a href="#rfc.iref.m.3"><b>9.3.1</b></a></li> 3847 <li>message/http Media Type <a href="#rfc.iref.m.4"><b>9.3.1</b></a></li> 3848 <li>method <a href="#rfc.iref.m.2"><b>3.1.1</b></a></li> 3846 3849 </ul> 3847 3850 </li> … … 3859 3862 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3860 3863 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3861 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1 .1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.7</a>, <a href="#rfc.xref.Part2.11">6.1.2.2</a>, <a href="#rfc.xref.Part2.12">6.1.5</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a>, <a href="#rfc.xref.Part2.17">8.2</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>3862 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1 .1</a></li>3864 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.7</a>, <a href="#rfc.xref.Part2.11">6.1.2.2</a>, <a href="#rfc.xref.Part2.12">6.1.5</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a>, <a href="#rfc.xref.Part2.17">8.2</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3865 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1</a></li> 3863 3866 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3864 <li><em>Section 4</em> <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2 .1</a></li>3867 <li><em>Section 4</em> <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a></li> 3865 3868 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.11">6.1.2.2</a>, <a href="#rfc.xref.Part2.12">6.1.5</a></li> 3866 3869 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.9">5.3</a></li> … … 3870 3873 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.17">8.2</a></li> 3871 3874 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.19">10.6</a></li> 3872 <li><em>Section 7.4.12</em> <a href="#rfc.xref.Part2.4">3.1.1 .2</a>, <a href="#rfc.xref.Part2.18">10.6</a></li>3875 <li><em>Section 7.4.12</em> <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.18">10.6</a></li> 3873 3876 <li><em>Section 10.2</em> <a href="#rfc.xref.Part2.6">3.2</a></li> 3874 3877 <li><em>Section 10.3</em> <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li> … … 3894 3897 <li>recipient <a href="#rfc.iref.r.1"><b>2.1</b></a></li> 3895 3898 <li>request <a href="#rfc.iref.r.2"><b>2.1</b></a></li> 3899 <li>request-target <a href="#rfc.iref.r.6">3.1.1</a></li> 3896 3900 <li>resource <a href="#rfc.iref.r.5"><b>2.7</b></a></li> 3897 3901 <li>response <a href="#rfc.iref.r.3"><b>2.1</b></a></li> … … 3925 3929 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li> 3926 3930 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li> 3927 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18"> 3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">5.3</a>, <a href="#rfc.xref.RFC3986.20">5.6</a>, <a href="#RFC3986"><b>12.1</b></a><ul>3931 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#rfc.xref.RFC3986.19">5.3</a>, <a href="#rfc.xref.RFC3986.20">5.6</a>, <a href="#RFC3986"><b>12.1</b></a><ul> 3928 3932 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">5.3</a></li> 3929 3933 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.7</a></li> … … 3933 3937 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a></li> 3934 3938 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC3986.12">2.7</a></li> 3935 <li><em>Section 3.5</em> <a href="#rfc.xref.RFC3986.18"> 3.1.1.2</a></li>3939 <li><em>Section 3.5</em> <a href="#rfc.xref.RFC3986.18">5.1</a></li> 3936 3940 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3937 3941 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</a></li> … … 3967 3971 </li> 3968 3972 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3969 <li>target resource <a href="#rfc.iref.t.7"><b>5.6</b></a></li> 3973 <li>target resource <a href="#rfc.iref.t.7"><b>5.1</b></a></li> 3974 <li>target URI <a href="#rfc.iref.t.8"><b>5.1</b></a></li> 3970 3975 <li>TE header field <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.t.5"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3971 3976 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li> -
draft-ietf-httpbis/latest/p2-semantics.html
r1577 r1580 1499 1499 to HTTP might use the OPTIONS body to make more detailed queries on the server. 1500 1500 </p> 1501 <p id="rfc.section.6.2.p.4">If the request-target is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than1502 to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful1503 as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server.1504 For example, this can beused to test a proxy for HTTP/1.1 conformance (or lack thereof).1501 <p id="rfc.section.6.2.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.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>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 1502 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1503 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 1504 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 1505 1505 </p> 1506 1506 <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating … … 1662 1662 </p> 1663 1663 <p id="rfc.section.6.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 1664 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.3</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1664 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.3</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1665 1665 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1666 1666 infinite loop. 1667 1667 </p> 1668 <p id="rfc.section.6.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 9.3.1</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>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1668 <p id="rfc.section.6.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 9.3.1</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>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1669 1669 </p> 1670 1670 <div id="rfc.iref.c.1"></div> … … 1674 1674 its behavior to blind forwarding of packets until the connection is closed. 1675 1675 </p> 1676 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 3.1.1.2</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>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1676 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.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>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1677 1677 For example, 1678 1678 </p> … … 1740 1740 <p id="rfc.section.7.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 1741 1741 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 1742 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 6.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 detailed discussion of the use and handling of this status code.1742 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 6.2.3</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> for detailed discussion of the use and handling of this status code. 1743 1743 </p> 1744 1744 <div id="rfc.iref.23"></div> 1745 1745 <div id="rfc.iref.s.3"></div> 1746 1746 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1747 <p id="rfc.section.7.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 8.2</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>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1747 <p id="rfc.section.7.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 8.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>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1748 1748 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1749 1749 </p> … … 1798 1798 <div id="rfc.iref.s.7"></div> 1799 1799 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1800 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1800 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1801 1801 </p> 1802 1802 <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code … … 1833 1833 another input action. 1834 1834 </p> 1835 <p id="rfc.section.7.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.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1835 <p id="rfc.section.7.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.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1836 1836 </p> 1837 1837 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2093 2093 <div id="rfc.iref.s.31"></div> 2094 2094 <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2095 <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.2</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>) specifying the required protocols.2095 <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.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>) specifying the required protocols. 2096 2096 </p> 2097 2097 <div id="rfc.figure.u.8"></div> … … 2154 2154 <p id="rfc.section.7.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 2155 2155 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2156 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><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.2156 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.37"><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. 2157 2157 </p> 2158 2158 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h1> … … 2318 2318 </p> 2319 2319 <ul class="empty"> 2320 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</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>. It does not support any expect-params.2320 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2321 2321 </li> 2322 2322 </ul> … … 2430 2430 <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a> <a id="header.server" href="#header.server">Server</a></h2> 2431 2431 <p id="rfc.section.10.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2432 <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</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.3 8"><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 for2432 <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</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.39"><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 2433 2433 identifying the application. 2434 2434 </p> … … 2436 2436 </pre><p id="rfc.section.10.9.p.4">Example:</p> 2437 2437 <div id="rfc.figure.u.35"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2438 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server 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 8.3</a> of <a href="#Part1" id="rfc.xref.Part1. 39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2438 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server 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 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2439 2439 </p> 2440 2440 <div class="note" id="rfc.section.10.9.p.7"> … … 2452 2452 user agent limitations. 2453 2453 </p> 2454 <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</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.4 0"><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 significance2454 <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</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.41"><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 2455 2455 for identifying the application. 2456 2456 </p> … … 2922 2922 </p> 2923 2923 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2924 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.4 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2924 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2925 2925 </p> 2926 2926 <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References … … 3087 3087 </p> 3088 3088 <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3089 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 2"><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 10.9</a>)3089 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.43"><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 10.9</a>) 3090 3090 </p> 3091 3091 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3693 3693 </li> 3694 3694 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3695 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6. 8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.15</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">10.3</a>, <a href="#rfc.xref.Part1.38">10.9</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a>, <a href="#rfc.xref.Part1.41">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.42">A</a><ul>3695 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.2</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.8</a>, <a href="#rfc.xref.Part1.31">6.9</a>, <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.2.4</a>, <a href="#rfc.xref.Part1.35">7.2.6</a>, <a href="#rfc.xref.Part1.36">7.4.15</a>, <a href="#rfc.xref.Part1.37">7.5.6</a>, <a href="#rfc.xref.Part1.38">10.3</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.40">10.9</a>, <a href="#rfc.xref.Part1.41">10.10</a>, <a href="#rfc.xref.Part1.42">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul> 3696 3696 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3697 3697 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3698 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.3 3">7.2.4</a></li>3699 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 6">7.5.6</a></li>3698 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.34">7.2.4</a></li> 3699 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.37">7.5.6</a></li> 3700 3700 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 3701 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.30">6.9</a></li>3702 3701 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 3703 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.3 8">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a></li>3702 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.41">10.10</a></li> 3704 3703 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.19">3.1</a></li> 3705 3704 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.18">3.1</a></li> 3706 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.3 4">7.2.6</a></li>3705 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</a></li> 3707 3706 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3708 3707 <li><em>Section 4.4</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3708 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.28">6.2</a>, <a href="#rfc.xref.Part1.31">6.9</a></li> 3709 3709 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3710 3710 <li><em>Section 5.6</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> 3711 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.3 1">7.1.1</a>, <a href="#rfc.xref.Part1.37">10.3</a></li>3711 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">10.3</a></li> 3712 3712 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3713 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.3 2">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li>3714 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.2 8">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li>3715 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1. 29">6.8</a></li>3716 <li><em>Section 11</em> <a href="#rfc.xref.Part1.4 1">13</a></li>3713 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li> 3714 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.40">10.9</a>, <a href="#rfc.xref.Part1.43">A</a></li> 3715 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.30">6.8</a></li> 3716 <li><em>Section 11</em> <a href="#rfc.xref.Part1.42">13</a></li> 3717 3717 </ul> 3718 3718 </li> -
draft-ietf-httpbis/latest/p4-conditional.html
r1569 r1580 460 460 } 461 461 @bottom-center { 462 content: "Expires September 9, 2012";462 content: "Expires September 11, 2012"; 463 463 } 464 464 @bottom-right { … … 507 507 <meta name="dct.creator" content="Reschke, J. F."> 508 508 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 509 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 08">509 <meta name="dct.issued" scheme="ISO8601" content="2012-03-10"> 510 510 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 511 511 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 533 533 </tr> 534 534 <tr> 535 <td class="left">Expires: September 9, 2012</td>535 <td class="left">Expires: September 11, 2012</td> 536 536 <td class="right">J. Mogul</td> 537 537 </tr> … … 590 590 <tr> 591 591 <td class="left"></td> 592 <td class="right">March 8, 2012</td>592 <td class="right">March 10, 2012</td> 593 593 </tr> 594 594 </tbody> … … 620 620 in progress”. 621 621 </p> 622 <p>This Internet-Draft will expire on September 9, 2012.</p>622 <p>This Internet-Draft will expire on September 11, 2012.</p> 623 623 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 624 624 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1003 1003 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct 1004 1004 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings 1005 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.1005 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags. 1006 1006 </p> 1007 1007 </div> … … 1630 1630 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.2</a></li> 1631 1631 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.5">1.2</a></li> 1632 <li><em>Section 5</em> <a href="#rfc.xref.Part1.6">2.3.3</a></li>1632 <li><em>Section 4</em> <a href="#rfc.xref.Part1.6">2.3.3</a></li> 1633 1633 <li><em>Section 11</em> <a href="#rfc.xref.Part1.8">7</a></li> 1634 1634 </ul> -
draft-ietf-httpbis/latest/p5-range.html
r1567 r1580 460 460 } 461 461 @bottom-center { 462 content: "Expires September 9, 2012";462 content: "Expires September 11, 2012"; 463 463 } 464 464 @bottom-right { … … 509 509 <meta name="dct.creator" content="Reschke, J. F."> 510 510 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 511 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 08">511 <meta name="dct.issued" scheme="ISO8601" content="2012-03-10"> 512 512 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 513 513 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 535 535 </tr> 536 536 <tr> 537 <td class="left">Expires: September 9, 2012</td>537 <td class="left">Expires: September 11, 2012</td> 538 538 <td class="right">J. Mogul</td> 539 539 </tr> … … 592 592 <tr> 593 593 <td class="left"></td> 594 <td class="right">March 8, 2012</td>594 <td class="right">March 10, 2012</td> 595 595 </tr> 596 596 </tbody> … … 620 620 in progress”. 621 621 </p> 622 <p>This Internet-Draft will expire on September 9, 2012.</p>622 <p>This Internet-Draft will expire on September 11, 2012.</p> 623 623 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 624 624 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r1567 r1580 460 460 } 461 461 @bottom-center { 462 content: "Expires September 9, 2012";462 content: "Expires September 11, 2012"; 463 463 } 464 464 @bottom-right { … … 506 506 <meta name="dct.creator" content="Reschke, J. F."> 507 507 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 508 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 08">508 <meta name="dct.issued" scheme="ISO8601" content="2012-03-10"> 509 509 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 510 510 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 537 537 </tr> 538 538 <tr> 539 <td class="left">Expires: September 9, 2012</td>539 <td class="left">Expires: September 11, 2012</td> 540 540 <td class="right">HP</td> 541 541 </tr> … … 590 590 <tr> 591 591 <td class="left"></td> 592 <td class="right">March 8, 2012</td>592 <td class="right">March 10, 2012</td> 593 593 </tr> 594 594 </tbody> … … 618 618 in progress”. 619 619 </p> 620 <p>This Internet-Draft will expire on September 9, 2012.</p>620 <p>This Internet-Draft will expire on September 11, 2012.</p> 621 621 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 622 622 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 808 808 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="protection.space" href="#protection.space">Protection Space (Realm)</a></h2> 809 809 <p id="rfc.section.2.2.p.1">The authentication parameter realm is reserved for use by authentication schemes that wish to indicate the scope of protection.</p> 810 <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; 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.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources810 <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.6</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources 811 811 on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization 812 812 database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific … … 933 933 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 934 934 <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of a challenge that indicates the authentication scheme and parameters applicable 935 to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.935 to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.6</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 936 936 </p> 937 937 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a> … … 959 959 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 960 960 <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters 961 applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).961 applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.6</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 962 962 </p> 963 963 <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the … … 1399 1399 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a></li> 1400 1400 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 1401 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.8">2.2</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a></li>1401 <li><em>Section 5.6</em> <a href="#rfc.xref.Part1.8">2.2</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a></li> 1402 1402 <li><em>Section 11</em> <a href="#rfc.xref.Part1.12">7</a></li> 1403 1403 </ul>
Note: See TracChangeset
for help on using the changeset viewer.