Changeset 1432 for draft-ietf-httpbis/latest
- Timestamp:
- 02/09/11 01:20:56 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1431 r1432 570 570 </li> 571 571 <li>3. <a href="#http.message">Message Format</a><ul> 572 <li>3.1 <a href="#start.line">Start Line</a></li> 572 <li>3.1 <a href="#start.line">Start Line</a><ul> 573 <li>3.1.1 <a href="#request-line">Request-Line</a><ul> 574 <li>3.1.1.1 <a href="#method">Method</a></li> 575 <li>3.1.1.2 <a href="#request-target">request-target</a></li> 576 </ul> 577 </li> 578 <li>3.1.2 <a href="#status-line">Status-Line</a><ul> 579 <li>3.1.2.1 <a href="#status.code">Status Code</a></li> 580 <li>3.1.2.2 <a href="#reason.phrase">Reason Phrase</a></li> 581 </ul> 582 </li> 583 </ul> 584 </li> 573 585 <li>3.2 <a href="#header.fields">Header Fields</a><ul> 574 586 <li>3.2.1 <a href="#field.parsing">Field Parsing</a></li> … … 583 595 </li> 584 596 <li>4. <a href="#request">Request</a><ul> 585 <li>4.1 <a href="#request-line">Request-Line</a><ul> 586 <li>4.1.1 <a href="#method">Method</a></li> 587 <li>4.1.2 <a href="#request-target">request-target</a></li> 588 </ul> 589 </li> 597 <li>4.1 <a href="#request-target-types">Types of Request Target</a></li> 590 598 <li>4.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 591 599 <li>4.3 <a href="#effective.request.uri">Effective Request URI</a></li> 592 600 </ul> 593 601 </li> 594 <li>5. <a href="#response">Response</a><ul> 595 <li>5.1 <a href="#status-line">Status-Line</a><ul> 596 <li>5.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li> 597 </ul> 598 </li> 599 </ul> 600 </li> 602 <li>5. <a href="#response">Response</a></li> 601 603 <li>6. <a href="#protocol.parameters">Protocol Parameters</a><ul> 602 604 <li>6.1 <a href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></li> … … 1199 1201 Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing. 1200 1202 </p> 1201 <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> 1203 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="request-line" href="#request-line">Request-Line</a></h3> 1204 <p id="rfc.section.3.1.1.p.1">The Request-Line begins with a method token, followed by a single space (SP), the request-target, another single space (SP), 1205 the protocol version, and ending with CRLF. 1206 </p> 1207 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a> 1208 </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> 1209 <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> 1210 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1211 </pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations 1212 for new methods. 1213 </p> 1214 <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> 1215 <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 1216 described in <a href="#request-target-types" title="Types of Request Target">Section 4.1</a>. 1217 </p> 1218 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1219 / <a href="#uri" class="smpl">absolute-URI</a> 1220 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) 1221 / <a href="#uri" class="smpl">authority</a> 1222 </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 1223 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.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1224 </p> 1225 <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. 1226 </p> 1227 <div class="note" id="rfc.section.3.1.1.2.p.5"> 1228 <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. 1229 </p> 1230 </div> 1231 <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> 1232 <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, 1233 another space, a possibly-empty textual phrase describing the status code, and ending with CRLF. 1234 </p> 1235 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1236 </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> 1237 <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.4"><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 1238 for new status codes. 1239 </p> 1240 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#status.code" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1241 </pre><p id="rfc.section.3.1.2.1.p.3">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. 1242 There are 5 values for the first digit: 1243 </p> 1244 <ul> 1245 <li>1xx: Informational - Request received, continuing process</li> 1246 <li>2xx: Success - The action was successfully received, understood, and accepted</li> 1247 <li>3xx: Redirection - Further action must be taken in order to complete the request</li> 1248 <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li> 1249 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1250 </ul> 1251 <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> 1252 <p id="rfc.section.3.1.2.2.p.1">The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1253 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1254 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. 1255 </p> 1256 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1257 </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> 1202 1258 <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 1203 1259 value. 1204 1260 </p> 1205 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></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>1261 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">BWS</a> 1206 1262 <a href="#header.fields" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1207 1263 <a href="#header.fields" class="smpl">field-value</a> = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">obs-fold</a> ) … … 1216 1272 them. 1217 1273 </p> 1218 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2. 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 9.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1274 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 9.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1219 1275 </p> 1220 1276 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1264 1320 </p> 1265 1321 </div> 1266 <div id="rfc.figure.u.2 2"></div><pre class="inline"><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="#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>1322 <div id="rfc.figure.u.28"></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> 1267 1323 1268 1324 <a href="#rule.token.separators" class="smpl">token</a> = 1*<a href="#rule.token.separators" class="smpl">tchar</a> … … 1279 1335 <p id="rfc.section.3.2.3.p.3"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 1280 1336 </div> 1281 <div id="rfc.figure.u.2 3"></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.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>1337 <div id="rfc.figure.u.29"></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> 1282 1338 <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> 1283 1339 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF … … 1285 1341 <p id="rfc.section.3.2.3.p.5"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p> 1286 1342 </div> 1287 <div id="rfc.figure.u. 24"></div><pre class="inline"><span id="rfc.iref.g.41"></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> )1343 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> /<a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1288 1344 </pre><p id="rfc.section.3.2.3.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 1289 1345 </p> … … 1295 1351 </p> 1296 1352 </div> 1297 <div id="rfc.figure.u. 25"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></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> ) ")"1353 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1298 1354 <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> 1299 1355 </pre><div id="rule.quoted-cpair"> 1300 1356 <p id="rfc.section.3.2.3.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> 1301 1357 </div> 1302 <div id="rfc.figure.u. 26"></div><pre class="inline"><span id="rfc.iref.g.44"></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> )1358 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> /<a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1303 1359 </pre><p id="rfc.section.3.2.3.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and 1304 1360 ")"). … … 1306 1362 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> 1307 1363 <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p> 1308 <div id="rfc.figure.u. 27"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET1364 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET 1309 1365 </pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding 1310 1366 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 9.7</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message-body length. … … 1324 1380 </p> 1325 1381 <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and 1326 the response status code (<a href="#status.code .and.reason.phrase" title="Status Code and Reason Phrase">Section 5.1.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,1382 the response 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., 1327 1383 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1328 1384 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length. … … 1425 1481 signifying the end of the header block, and an optional message body. 1426 1482 </p> 1427 <div id="rfc.figure.u. 28"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 4.1</a>1483 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 3.1.1</a> 1428 1484 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#header.fields" title="Header Fields">Section 3.2</a> 1429 1485 <a href="#core.rules" class="smpl">CRLF</a> 1430 1486 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> 1431 </pre><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2> 1432 <p id="rfc.section.4.1.p.1">The Request-Line begins with a method token, followed by a single space (SP), the request-target, another single space (SP), 1433 the protocol version, and ending with CRLF. 1434 </p> 1435 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></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> 1436 </pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="method" href="#method">Method</a></h3> 1437 <p id="rfc.section.4.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> 1438 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1439 </pre><p id="rfc.section.4.1.1.p.3">See <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> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations 1440 for new methods. 1441 </p> 1442 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1443 <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request. In most cases, the user agent is provided 1444 a URI reference from which it determines an absolute URI for identifying the target resource. When a request to the resource 1445 is initiated, all or part of that URI is used to construct the HTTP request-target. 1446 </p> 1447 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.49"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1448 / <a href="#uri" class="smpl">absolute-URI</a> 1449 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) 1450 / <a href="#uri" class="smpl">authority</a> 1451 </pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request.</p> 1452 <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening 1487 </pre><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2> 1488 <p id="rfc.section.4.1.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target 1489 resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target. 1490 </p> 1491 <p id="rfc.section.4.1.p.2">The four options for request-target are dependent on the nature of the request.</p> 1492 <p id="rfc.section.4.1.p.3"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening 1453 1493 process) rather than to a specific named resource at that server. For example, 1454 1494 </p> 1455 <div id="rfc.figure.u.3 2"></div><pre class="text2">OPTIONS * HTTP/1.11456 </pre><p id="rfc.section.4.1. 2.p.6"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid1495 <div id="rfc.figure.u.35"></div><pre class="text2">OPTIONS * HTTP/1.1 1496 </pre><p id="rfc.section.4.1.p.5"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid 1457 1497 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 1458 1498 loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, and the numeric IP 1459 1499 address. An example Request-Line would be: 1460 1500 </p> 1461 <div id="rfc.figure.u.3 3"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11462 </pre><p id="rfc.section.4.1. 2.p.8">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.1463 </p> 1464 <p id="rfc.section.4.1. 2.p.9">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.1465 </p> 1466 <p id="rfc.section.4.1. 2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1467 </p> 1468 <p id="rfc.section.4.1. 2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,1501 <div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1502 </pre><p id="rfc.section.4.1.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1503 </p> 1504 <p id="rfc.section.4.1.p.8">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1505 </p> 1506 <p id="rfc.section.4.1.p.9"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1507 </p> 1508 <p id="rfc.section.4.1.p.10"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case, 1469 1509 the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified 1470 1510 above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and 1471 1511 send the lines: 1472 1512 </p> 1473 <div id="rfc.figure.u.3 4"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.11513 <div id="rfc.figure.u.37"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1 1474 1514 Host: www.example.org 1475 </pre><p id="rfc.section.4.1. 2.p.13">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path;1515 </pre><p id="rfc.section.4.1.p.12">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path; 1476 1516 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. 1477 1517 </p> 1478 <p id="rfc.section.4.1. 2.p.14">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and1518 <p id="rfc.section.4.1.p.13">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and 1479 1519 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. 1480 1520 </p> 1481 <div id="rfc.figure.u.3 5"></div>1521 <div id="rfc.figure.u.38"></div> 1482 1522 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1483 </pre><div id="rfc.figure.u.3 6"></div>1523 </pre><div id="rfc.figure.u.39"></div> 1484 1524 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1485 1525 Host: www.example.org:8001 1486 1526 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> 1487 <p id="rfc.section.4.1. 2.p.17">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><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.1488 </p> 1489 <p id="rfc.section.4.1. 2.p.18">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted1527 <p id="rfc.section.4.1.p.16">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1528 </p> 1529 <p id="rfc.section.4.1.p.17">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted 1490 1530 above to replace a null path-absolute with "/" or "*". 1491 1531 </p> 1492 <div class="note" id="rfc.section.4.1. 2.p.19">1532 <div class="note" id="rfc.section.4.1.p.18"> 1493 1533 <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1494 1534 a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been 1495 1535 known to rewrite the request-target. 1496 </p>1497 </div>1498 <p id="rfc.section.4.1.2.p.20">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-target1499 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.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1500 </p>1501 <p id="rfc.section.4.1.2.p.21">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.1502 </p>1503 <div class="note" id="rfc.section.4.1.2.p.22">1504 <p> <b>Note:</b> Fragments (<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-3.5">Section 3.5</a>) are not part of the request-target and thus will not be transmitted in an HTTP request.1505 1536 </p> 1506 1537 </div> … … 1551 1582 </p> 1552 1583 <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 1553 <div id="rfc.figure.u. 37"></div>1584 <div id="rfc.figure.u.40"></div> 1554 1585 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1555 1586 Host: www.example.org:8080 … … 1557 1588 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 1558 1589 </p> 1559 <div id="rfc.figure.u. 38"></div>1590 <div id="rfc.figure.u.41"></div> 1560 1591 <p>Example 2: the effective request URI for the message</p> <pre class="text">OPTIONS * HTTP/1.1 1561 1592 Host: www.example.org … … 1567 1598 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1> 1568 1599 <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1569 <div id="rfc.figure.u. 39"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a>1600 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 3.1.2</a> 1570 1601 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#header.fields" title="Header Fields">Section 3.2</a> 1571 1602 <a href="#core.rules" class="smpl">CRLF</a> 1572 1603 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> 1573 </pre><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2>1574 <p id="rfc.section.5.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version, a space (SP), the status code,1575 another space, a possibly-empty textual phrase describing the status code, and ending with CRLF.1576 </p>1577 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1578 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>1579 <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations1580 for new status codes.1581 </p>1582 <p id="rfc.section.5.1.1.p.2">The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,1583 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A1584 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.1585 </p>1586 <p id="rfc.section.5.1.1.p.3">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.1587 There are 5 values for the first digit:1588 </p>1589 <ul>1590 <li>1xx: Informational - Request received, continuing process</li>1591 <li>2xx: Success - The action was successfully received, understood, and accepted</li>1592 <li>3xx: Redirection - Further action must be taken in order to complete the request</li>1593 <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li>1594 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>1595 </ul>1596 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1597 <a href="#status.code.and.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> )1598 1604 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 1599 1605 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2> … … 1601 1607 a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 1602 1608 </p> 1603 <div id="rfc.figure.u.4 2"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 11231609 <div id="rfc.figure.u.43"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1604 1610 </pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> 1605 <div id="rfc.figure.u.4 3"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format1611 <div id="rfc.figure.u.44"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1606 1612 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1607 1613 </pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. … … 1611 1617 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. 1612 1618 </p> 1613 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>1619 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 1614 1620 </pre><div id="preferred.date.format"> 1615 1621 <p id="rfc.section.6.1.p.8"> Preferred format:</p> 1616 1622 </div> 1617 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><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> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1623 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><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> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1618 1624 ; fixed length subset of the format defined in 1619 1625 ; <a href="http://tools.ietf.org/html/rfc1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> … … 1658 1664 <p id="rfc.section.6.1.p.11"> Obsolete formats:</p> 1659 1665 </div> 1660 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.67"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>1661 </pre><div id="rfc.figure.u.4 7"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1666 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.67"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 1667 </pre><div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1662 1668 <a href="#obsolete.date.formats" class="smpl">date2</a> = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a> 1663 1669 ; day-month-year (e.g., 02-Jun-82) … … 1670 1676 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1671 1677 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1672 </pre><div id="rfc.figure.u.4 8"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>1678 </pre><div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 1673 1679 <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> )) 1674 1680 ; month day (e.g., Jun 2) … … 1688 1694 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1689 1695 </p> 1690 <div id="rfc.figure.u. 49"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>1696 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a> 1691 1697 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 6.2.2.1</a> 1692 1698 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> … … 1697 1703 <p id="rfc.section.6.2.p.3"> Parameters are in the form of attribute/value pairs.</p> 1698 1704 </div> 1699 <div id="rfc.figure.u.5 0"></div><pre class="inline"><span id="rfc.iref.g.72"></span><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="#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>1705 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.72"></span><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="#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> 1700 1706 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1701 1707 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> … … 1715 1721 for the recipient to verify that it has received the full message. 1716 1722 </p> 1717 <div id="rfc.figure.u.5 1"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1723 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1718 1724 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1719 1725 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1758 1764 </p> 1759 1765 <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1760 <div id="rfc.figure.u.5 2"></div><pre class="text"> length := 01766 <div id="rfc.figure.u.53"></div><pre class="text"> length := 0 1761 1767 read chunk-size, chunk-ext (if any) and CRLF 1762 1768 while (chunk-size > 0) { … … 1830 1836 By convention, the products are listed in order of their significance for identifying the application. 1831 1837 </p> 1832 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1838 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1833 1839 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1834 1840 </pre><p id="rfc.section.6.3.p.3">Examples:</p> 1835 <div id="rfc.figure.u.5 4"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31841 <div id="rfc.figure.u.55"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1836 1842 Server: Apache/0.8.4 1837 1843 </pre><p id="rfc.section.6.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). … … 1842 1848 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. 1843 1849 </p> 1844 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.91"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1850 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.91"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1845 1851 / ( "1" [ "." 0*3("0") ] ) 1846 1852 </pre><div class="note" id="rfc.section.6.4.p.3"> … … 2173 2179 </p> 2174 2180 <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p> 2175 <div id="rfc.figure.u.5 6"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a>2181 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2176 2182 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 2177 2183 </pre><p id="rfc.section.9.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove … … 2196 2202 of the response. For example, 2197 2203 </p> 2198 <div id="rfc.figure.u.5 7"></div><pre class="text"> Connection: close2204 <div id="rfc.figure.u.58"></div><pre class="text"> Connection: close 2199 2205 </pre><p id="rfc.section.9.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 2200 2206 </p> … … 2212 2218 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 2213 2219 </p> 2214 <div id="rfc.figure.u.5 8"></div><pre class="inline"><span id="rfc.iref.g.94"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>2220 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.94"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 2215 2221 </pre><p id="rfc.section.9.2.p.3">An example is</p> 2216 <div id="rfc.figure.u. 59"></div><pre class="text"> Content-Length: 34952222 <div id="rfc.figure.u.60"></div><pre class="text"> Content-Length: 3495 2217 2223 </pre><p id="rfc.section.9.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length 2218 2224 can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section 3.3</a> describes how recipients determine the length of a message-body. … … 2228 2234 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 2229 2235 </p> 2230 <div id="rfc.figure.u.6 0"></div><pre class="inline"><span id="rfc.iref.g.95"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>2236 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.95"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> 2231 2237 </pre><p id="rfc.section.9.3.p.3">An example is</p> 2232 <div id="rfc.figure.u.6 1"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2238 <div id="rfc.figure.u.62"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2233 2239 </pre><p id="rfc.section.9.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 2234 2240 </p> … … 2264 2270 Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line. 2265 2271 </p> 2266 <div id="rfc.figure.u.6 2"></div><pre class="inline"><span id="rfc.iref.g.96"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>2272 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.96"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a> 2267 2273 </pre><p id="rfc.section.9.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then 2268 2274 the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 2269 2275 </p> 2270 2276 <p id="rfc.section.9.4.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 2271 <div id="rfc.figure.u.6 3"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12277 <div id="rfc.figure.u.64"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2272 2278 Host: www.example.org 2273 2279 </pre><p id="rfc.section.9.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information … … 2296 2302 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 2297 2303 </p> 2298 <div id="rfc.figure.u.6 4"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>2304 <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 2299 2305 <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> ] ) 2300 2306 <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> ) … … 2304 2310 </p> 2305 2311 <p id="rfc.section.9.5.p.5">Examples of its use are:</p> 2306 <div id="rfc.figure.u.6 5"></div><pre class="text"> TE: deflate2312 <div id="rfc.figure.u.66"></div><pre class="text"> TE: deflate 2307 2313 TE: 2308 2314 TE: trailers, deflate;q=0.5 … … 2341 2347 chunked transfer-coding. 2342 2348 </p> 2343 <div id="rfc.figure.u.6 6"></div><pre class="inline"><span id="rfc.iref.g.101"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>2349 <div id="rfc.figure.u.67"></div><pre class="inline"><span id="rfc.iref.g.101"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 2344 2350 </pre><p id="rfc.section.9.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 2345 2351 to know which header fields to expect in the trailer. … … 2361 2367 are not. 2362 2368 </p> 2363 <div id="rfc.figure.u.6 7"></div><pre class="inline"><span id="rfc.iref.g.102"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>2369 <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.102"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 2364 2370 </pre><p id="rfc.section.9.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>. An example is: 2365 2371 </p> 2366 <div id="rfc.figure.u.6 8"></div><pre class="text"> Transfer-Encoding: chunked2372 <div id="rfc.figure.u.69"></div><pre class="text"> Transfer-Encoding: chunked 2367 2373 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 2368 2374 </p> … … 2374 2380 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2375 2381 </p> 2376 <div id="rfc.figure.u. 69"></div><pre class="inline"><span id="rfc.iref.g.103"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>2382 <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.103"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a> 2377 2383 </pre><p id="rfc.section.9.8.p.3">For example,</p> 2378 <div id="rfc.figure.u.7 0"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112384 <div id="rfc.figure.u.71"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2379 2385 </pre><p id="rfc.section.9.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 2380 2386 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2431 2437 of all senders along the request/response chain. 2432 2438 </p> 2433 <div id="rfc.figure.u.7 1"></div><pre class="inline"><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>2439 <div id="rfc.figure.u.72"></div><pre class="inline"><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 2434 2440 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2435 2441 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a> … … 2455 2461 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2456 2462 </p> 2457 <div id="rfc.figure.u.7 2"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2463 <div id="rfc.figure.u.73"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2458 2464 </pre><p id="rfc.section.9.9.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, 2459 2465 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. … … 2462 2468 For example, 2463 2469 </p> 2464 <div id="rfc.figure.u.7 3"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2470 <div id="rfc.figure.u.74"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2465 2471 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p> 2466 <div id="rfc.figure.u.7 4"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2472 <div id="rfc.figure.u.75"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2467 2473 </pre><p id="rfc.section.9.9.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 2468 2474 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2817 2823 a Denial of Service against implementations that accept fields with unlimited lengths. 2818 2824 </p> 2819 <p id="rfc.section.11.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 4.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 expected2825 <p id="rfc.section.11.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 expected 2820 2826 that most implementations will choose substantially higher limits. 2821 2827 </p> … … 3074 3080 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3075 3081 <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> 3076 <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 9.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 4.1.2</a>) are among the most important changes defined by HTTP/1.1.3082 <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 9.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. 3077 3083 </p> 3078 3084 <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 … … 3120 3126 </p> 3121 3127 <p id="rfc.section.A.2.p.8">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk 3122 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section 4.1.2</a>)3128 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section 3.1.1.2</a>) 3123 3129 </p> 3124 3130 <p id="rfc.section.A.2.p.9">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore … … 3134 3140 </p> 3135 3141 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3136 <div id="rfc.figure.u.7 5"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS3142 <div id="rfc.figure.u.76"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3137 3143 3138 3144 <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF … … 3157 3163 3158 3164 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( SP / HTAB / obs-fold ) 3159 <a href="# status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( HTAB / SP / VCHAR / obs-text )3165 <a href="#reason.phrase" class="smpl">Reason-Phrase</a> = *( HTAB / SP / VCHAR / obs-text ) 3160 3166 <a href="#request" class="smpl">Request</a> = Request-Line *( header-field CRLF ) CRLF [ message-body ] 3161 3167 <a href="#request-line" class="smpl">Request-Line</a> = Method SP request-target SP HTTP-Version CRLF 3162 3168 <a href="#response" class="smpl">Response</a> = Status-Line *( header-field CRLF ) CRLF [ message-body ] 3163 3169 3164 <a href="#status.code .and.reason.phrase" class="smpl">Status-Code</a> = 3DIGIT3170 <a href="#status.code" class="smpl">Status-Code</a> = 3DIGIT 3165 3171 <a href="#status-line" class="smpl">Status-Line</a> = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3166 3172 … … 3300 3306 3301 3307 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3302 </pre> <div id="rfc.figure.u.7 6"></div>3308 </pre> <div id="rfc.figure.u.77"></div> 3303 3309 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3304 3310 ; Connection defined but not used … … 3677 3683 <ul class="ind"> 3678 3684 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3679 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.3">4.1 .2</a></li>3685 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.3">4.1</a></li> 3680 3686 <li>accelerator <a href="#rfc.iref.a.1"><b>2.4</b></a></li> 3681 3687 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>10.3.2</b></a></li> 3682 <li>asterisk form (of request-target) <a href="#rfc.iref.a.2">4.1 .2</a></li>3683 <li>authority form (of request-target) <a href="#rfc.iref.a.4">4.1 .2</a></li>3688 <li>asterisk form (of request-target) <a href="#rfc.iref.a.2">4.1</a></li> 3689 <li>authority form (of request-target) <a href="#rfc.iref.a.4">4.1</a></li> 3684 3690 </ul> 3685 3691 </li> … … 3736 3742 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.79"><b>6.2.1</b></a></li> 3737 3743 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g.77"><b>6.2.1</b></a></li> 3738 <li><tt>comment</tt> <a href="#rfc.iref.g.4 2"><b>3.2.3</b></a></li>3744 <li><tt>comment</tt> <a href="#rfc.iref.g.48"><b>3.2.3</b></a></li> 3739 3745 <li><tt>Connection</tt> <a href="#rfc.iref.g.92"><b>9.1</b></a></li> 3740 3746 <li><tt>connection-token</tt> <a href="#rfc.iref.g.93"><b>9.1</b></a></li> … … 3742 3748 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3743 3749 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3744 <li><tt>ctext</tt> <a href="#rfc.iref.g.4 3"><b>3.2.3</b></a></li>3750 <li><tt>ctext</tt> <a href="#rfc.iref.g.49"><b>3.2.3</b></a></li> 3745 3751 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3746 3752 <li><tt>Date</tt> <a href="#rfc.iref.g.95"><b>9.3</b></a></li> … … 3753 3759 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3754 3760 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> 3755 <li><tt>field-content</tt> <a href="#rfc.iref.g.3 3"><b>3.2</b></a></li>3756 <li><tt>field-name</tt> <a href="#rfc.iref.g.3 1"><b>3.2</b></a></li>3757 <li><tt>field-value</tt> <a href="#rfc.iref.g.3 2"><b>3.2</b></a></li>3761 <li><tt>field-content</tt> <a href="#rfc.iref.g.39"><b>3.2</b></a></li> 3762 <li><tt>field-name</tt> <a href="#rfc.iref.g.37"><b>3.2</b></a></li> 3763 <li><tt>field-value</tt> <a href="#rfc.iref.g.38"><b>3.2</b></a></li> 3758 3764 <li><tt>GMT</tt> <a href="#rfc.iref.g.66"><b>6.1</b></a></li> 3759 <li><tt>header-field</tt> <a href="#rfc.iref.g.3 0"><b>3.2</b></a></li>3765 <li><tt>header-field</tt> <a href="#rfc.iref.g.36"><b>3.2</b></a></li> 3760 3766 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3761 3767 <li><tt>Host</tt> <a href="#rfc.iref.g.96"><b>9.4</b></a></li> … … 3770 3776 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.80"><b>6.2.1</b></a></li> 3771 3777 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3772 <li><tt>message-body</tt> <a href="#rfc.iref.g. 45"><b>3.3</b></a></li>3773 <li><tt>Method</tt> <a href="#rfc.iref.g. 48"><b>4.1.1</b></a></li>3778 <li><tt>message-body</tt> <a href="#rfc.iref.g.51"><b>3.3</b></a></li> 3779 <li><tt>Method</tt> <a href="#rfc.iref.g.31"><b>3.1.1.1</b></a></li> 3774 3780 <li><tt>minute</tt> <a href="#rfc.iref.g.59"><b>6.1</b></a></li> 3775 3781 <li><tt>month</tt> <a href="#rfc.iref.g.64"><b>6.1</b></a></li> 3776 3782 <li><tt>obs-date</tt> <a href="#rfc.iref.g.67"><b>6.1</b></a></li> 3777 <li><tt>obs-text</tt> <a href="#rfc.iref.g.4 0"><b>3.2.3</b></a></li>3783 <li><tt>obs-text</tt> <a href="#rfc.iref.g.46"><b>3.2.3</b></a></li> 3778 3784 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3779 3785 <li><tt>OWS</tt> <a href="#rfc.iref.g.13"><b>1.2.2</b></a></li> … … 3785 3791 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.107"><b>9.9</b></a></li> 3786 3792 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.109"><b>9.9</b></a></li> 3787 <li><tt>qdtext</tt> <a href="#rfc.iref.g. 39"><b>3.2.3</b></a></li>3793 <li><tt>qdtext</tt> <a href="#rfc.iref.g.45"><b>3.2.3</b></a></li> 3788 3794 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.87"><b>6.2.1</b></a></li> 3789 3795 <li><tt>query</tt> <a href="#rfc.iref.g.24"><b>2.7</b></a></li> 3790 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g. 44"><b>3.2.3</b></a></li>3791 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.4 1"><b>3.2.3</b></a></li>3796 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.50"><b>3.2.3</b></a></li> 3797 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.47"><b>3.2.3</b></a></li> 3792 3798 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.86"><b>6.2.1</b></a></li> 3793 <li><tt>quoted-string</tt> <a href="#rfc.iref.g. 38"><b>3.2.3</b></a></li>3799 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.44"><b>3.2.3</b></a></li> 3794 3800 <li><tt>qvalue</tt> <a href="#rfc.iref.g.91"><b>6.4</b></a></li> 3795 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g. 53"><b>5.1.1</b></a></li>3801 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.35"><b>3.1.2.2</b></a></li> 3796 3802 <li><tt>received-by</tt> <a href="#rfc.iref.g.108"><b>9.9</b></a></li> 3797 3803 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.105"><b>9.9</b></a></li> 3798 <li><tt>Request</tt> <a href="#rfc.iref.g. 46"><b>4</b></a></li>3799 <li><tt>Request-Line</tt> <a href="#rfc.iref.g. 47"><b>4.1</b></a></li>3800 <li><tt>request-target</tt> <a href="#rfc.iref.g. 49"><b>4.1.2</b></a></li>3801 <li><tt>Response</tt> <a href="#rfc.iref.g.5 0"><b>5</b></a></li>3804 <li><tt>Request</tt> <a href="#rfc.iref.g.52"><b>4</b></a></li> 3805 <li><tt>Request-Line</tt> <a href="#rfc.iref.g.30"><b>3.1.1</b></a></li> 3806 <li><tt>request-target</tt> <a href="#rfc.iref.g.32"><b>3.1.1.2</b></a></li> 3807 <li><tt>Response</tt> <a href="#rfc.iref.g.53"><b>5</b></a></li> 3802 3808 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.55"><b>6.1</b></a></li> 3803 3809 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.68"><b>6.1</b></a></li> … … 3805 3811 <li><tt>second</tt> <a href="#rfc.iref.g.60"><b>6.1</b></a></li> 3806 3812 <li>SP <a href="#rfc.iref.g.11"><b>1.2</b></a></li> 3807 <li><tt>special</tt> <a href="#rfc.iref.g. 37"><b>3.2.3</b></a></li>3813 <li><tt>special</tt> <a href="#rfc.iref.g.43"><b>3.2.3</b></a></li> 3808 3814 <li><tt>start-line</tt> <a href="#rfc.iref.g.29"><b>3.1</b></a></li> 3809 <li><tt>Status-Code</tt> <a href="#rfc.iref.g. 52"><b>5.1.1</b></a></li>3810 <li><tt>Status-Line</tt> <a href="#rfc.iref.g. 51"><b>5.1</b></a></li>3815 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.34"><b>3.1.2.1</b></a></li> 3816 <li><tt>Status-Line</tt> <a href="#rfc.iref.g.33"><b>3.1.2</b></a></li> 3811 3817 <li><tt>t-codings</tt> <a href="#rfc.iref.g.98"><b>9.5</b></a></li> 3812 <li><tt>tchar</tt> <a href="#rfc.iref.g. 36"><b>3.2.3</b></a></li>3818 <li><tt>tchar</tt> <a href="#rfc.iref.g.42"><b>3.2.3</b></a></li> 3813 3819 <li><tt>TE</tt> <a href="#rfc.iref.g.97"><b>9.5</b></a></li> 3814 3820 <li><tt>te-ext</tt> <a href="#rfc.iref.g.100"><b>9.5</b></a></li> 3815 3821 <li><tt>te-params</tt> <a href="#rfc.iref.g.99"><b>9.5</b></a></li> 3816 3822 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.57"><b>6.1</b></a></li> 3817 <li><tt>token</tt> <a href="#rfc.iref.g. 35"><b>3.2.3</b></a></li>3823 <li><tt>token</tt> <a href="#rfc.iref.g.41"><b>3.2.3</b></a></li> 3818 3824 <li><tt>Trailer</tt> <a href="#rfc.iref.g.101"><b>9.6</b></a></li> 3819 3825 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.85"><b>6.2.1</b></a></li> … … 3828 3834 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3829 3835 <li><tt>Via</tt> <a href="#rfc.iref.g.104"><b>9.9</b></a></li> 3830 <li><tt>word</tt> <a href="#rfc.iref.g. 34"><b>3.2.3</b></a></li>3836 <li><tt>word</tt> <a href="#rfc.iref.g.40"><b>3.2.3</b></a></li> 3831 3837 <li><tt>year</tt> <a href="#rfc.iref.g.65"><b>6.1</b></a></li> 3832 3838 </ul> … … 3885 3891 </li> 3886 3892 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3887 <li>origin form (of request-target) <a href="#rfc.iref.o.3">4.1 .2</a></li>3893 <li>origin form (of request-target) <a href="#rfc.iref.o.3">4.1</a></li> 3888 3894 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3889 3895 <li>outbound <a href="#rfc.iref.o.2"><b>2.4</b></a></li> … … 3892 3898 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3893 3899 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li> 3894 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">3. 2</a>, <a href="#rfc.xref.Part2.3">4.1.1</a>, <a href="#rfc.xref.Part2.4">4.1.2</a>, <a href="#rfc.xref.Part2.5">4.1.2</a>, <a href="#rfc.xref.Part2.6">5.1.1</a>, <a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a>, <a href="#rfc.xref.Part2.12">7.2.3</a>, <a href="#rfc.xref.Part2.13">9.8</a>, <a href="#rfc.xref.Part2.14">11.6</a>, <a href="#rfc.xref.Part2.15">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul>3895 <li><em>Section 2</em> <a href="#rfc.xref.Part2. 3">4.1.1</a></li>3896 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2. 2">3.2</a></li>3897 <li><em>Section 4</em> <a href="#rfc.xref.Part2. 6">5.1.1</a></li>3900 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">3.1.1.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.2</a>, <a href="#rfc.xref.Part2.4">3.1.2.1</a>, <a href="#rfc.xref.Part2.5">3.2</a>, <a href="#rfc.xref.Part2.6">4.1</a>, <a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a>, <a href="#rfc.xref.Part2.12">7.2.3</a>, <a href="#rfc.xref.Part2.13">9.8</a>, <a href="#rfc.xref.Part2.14">11.6</a>, <a href="#rfc.xref.Part2.15">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul> 3901 <li><em>Section 2</em> <a href="#rfc.xref.Part2.2">3.1.1.1</a></li> 3902 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.5">3.2</a></li> 3903 <li><em>Section 4</em> <a href="#rfc.xref.Part2.4">3.1.2.1</a></li> 3898 3904 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a></li> 3899 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2. 4">4.1.2</a></li>3905 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.6">4.1</a></li> 3900 3906 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.9">7.2.3</a></li> 3901 3907 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.12">7.2.3</a></li> … … 3903 3909 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.13">9.8</a></li> 3904 3910 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.15">11.6</a></li> 3905 <li><em>Section 7.4.15</em> <a href="#rfc.xref.Part2. 5">4.1.2</a>, <a href="#rfc.xref.Part2.14">11.6</a></li>3911 <li><em>Section 7.4.15</em> <a href="#rfc.xref.Part2.3">3.1.1.2</a>, <a href="#rfc.xref.Part2.14">11.6</a></li> 3906 3912 <li><em>Section 8.2</em> <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a></li> 3907 3913 </ul> … … 3961 3967 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>13.2</b></a></li> 3962 3968 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">10.1</a>, <a href="#RFC3864"><b>13.2</b></a></li> 3963 <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"> 4.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1.2</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>13.1</b></a><ul>3964 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.1 8">4.1.2</a></li>3969 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>13.1</b></a><ul> 3970 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">4.1</a></li> 3965 3971 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.7</a></li> 3966 3972 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2.7.1</a></li> … … 3969 3975 <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> 3970 3976 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC3986.12">2.7</a></li> 3971 <li><em>Section 3.5</em> <a href="#rfc.xref.RFC3986.1 9">4.1.2</a></li>3977 <li><em>Section 3.5</em> <a href="#rfc.xref.RFC3986.18">3.1.1.2</a></li> 3972 3978 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3973 3979 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1431 r1432 1190 1190 ignored by some clients or cause others to cease parsing. 1191 1191 </t> 1192 1193 <section title="Request-Line" anchor="request-line"> 1194 <x:anchor-alias value="Request-Line"/> 1195 <t> 1196 The Request-Line begins with a method token, followed by a single 1197 space (SP), the request-target, another single space (SP), the 1198 protocol version, and ending with CRLF. 1199 </t> 1200 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-Line"/> 1201 <x:ref>Request-Line</x:ref> = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref> 1202 </artwork></figure> 1203 1204 <section title="Method" anchor="method"> 1205 <x:anchor-alias value="Method"/> 1206 <t> 1207 The Method token indicates the request method to be performed on the 1208 target resource. The request method is case-sensitive. 1209 </t> 1210 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/> 1211 <x:ref>Method</x:ref> = <x:ref>token</x:ref> 1212 </artwork></figure> 1213 <t> 1214 See &method; for further information, such as the list of methods defined 1215 by this specification, the IANA registry, and considerations for new methods. 1216 </t> 1217 </section> 1218 1219 <section title="request-target" anchor="request-target"> 1220 <x:anchor-alias value="request-target"/> 1221 <t> 1222 The request-target identifies the target resource upon which to apply 1223 the request. The four options for request-target are described in 1224 <xref target="request-target-types"/>. 1225 </t> 1226 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/> 1227 <x:ref>request-target</x:ref> = "*" 1228 / <x:ref>absolute-URI</x:ref> 1229 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) 1230 / <x:ref>authority</x:ref> 1231 </artwork></figure> 1232 <t> 1233 HTTP does not place a pre-defined limit on the length of a request-target. 1234 A server &MUST; be prepared to receive URIs of unbounded length and 1235 respond with the 414 (URI Too Long) status code if the received 1236 request-target would be longer than the server wishes to handle 1237 (see &status-414;). 1238 </t> 1239 <t> 1240 Various ad-hoc limitations on request-target length are found in practice. 1241 It is &RECOMMENDED; that all HTTP senders and recipients support 1242 request-target lengths of 8000 or more octets. 1243 </t> 1244 <x:note> 1245 <t> 1246 <x:h>Note:</x:h> Fragments (<xref target="RFC3986" x:fmt="," x:sec="3.5"/>) 1247 are not part of the request-target and thus will not be transmitted 1248 in an HTTP request. 1249 </t> 1250 </x:note> 1251 </section> 1252 </section> 1253 1254 <section title="Status-Line" anchor="status-line"> 1255 <x:anchor-alias value="Status-Line"/> 1256 <t> 1257 The first line of a Response message is the Status-Line, consisting 1258 of the protocol version, a space (SP), the status code, another space, 1259 a possibly-empty textual phrase describing the status code, and 1260 ending with CRLF. 1261 </t> 1262 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Line"/> 1263 <x:ref>Status-Line</x:ref> = <x:ref>HTTP-Version</x:ref> <x:ref>SP</x:ref> <x:ref>Status-Code</x:ref> <x:ref>SP</x:ref> <x:ref>Reason-Phrase</x:ref> <x:ref>CRLF</x:ref> 1264 </artwork></figure> 1265 1266 <section title="Status Code" anchor="status.code"> 1267 <x:anchor-alias value="Status-Code"/> 1268 <t> 1269 The Status-Code element is a 3-digit integer result code of the attempt to 1270 understand and satisfy the request. See &status-code-reasonphr; for 1271 further information, such as the list of status codes defined by this 1272 specification, the IANA registry, and considerations for new status codes. 1273 </t> 1274 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/> 1275 <x:ref>Status-Code</x:ref> = 3<x:ref>DIGIT</x:ref> 1276 </artwork></figure> 1277 <t> 1278 The first digit of the Status-Code defines the class of response. The 1279 last two digits do not have any categorization role. There are 5 1280 values for the first digit: 1281 <list style="symbols"> 1282 <t> 1283 1xx: Informational - Request received, continuing process 1284 </t> 1285 <t> 1286 2xx: Success - The action was successfully received, 1287 understood, and accepted 1288 </t> 1289 <t> 1290 3xx: Redirection - Further action must be taken in order to 1291 complete the request 1292 </t> 1293 <t> 1294 4xx: Client Error - The request contains bad syntax or cannot 1295 be fulfilled 1296 </t> 1297 <t> 1298 5xx: Server Error - The server failed to fulfill an apparently 1299 valid request 1300 </t> 1301 </list> 1302 </t> 1303 </section> 1304 1305 <section title="Reason Phrase" anchor="reason.phrase"> 1306 <x:anchor-alias value="Reason-Phrase"/> 1307 <t> 1308 The Reason Phrase exists for the sole purpose of providing a textual 1309 description associated with the numeric status code, out of deference to 1310 earlier Internet application protocols that were more frequently used with 1311 interactive text clients. A client &SHOULD; ignore the content of the Reason 1312 Phrase. 1313 </t> 1314 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Reason-Phrase"/> 1315 <x:ref>Reason-Phrase</x:ref> = *( <x:ref>HTAB</x:ref> / <x:ref>SP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 1316 </artwork></figure> 1317 </section> 1318 </section> 1319 1192 1320 </section> 1193 1321 … … 1463 1591 For response messages, whether or not a message-body is included with 1464 1592 a message is dependent on both the request method and the response 1465 status code (<xref target="status.code .and.reason.phrase"/>).1593 status code (<xref target="status.code"/>). 1466 1594 Responses to the HEAD request method never include a message-body 1467 1595 because the associated response header fields (e.g., Transfer-Encoding, … … 1671 1799 </artwork></figure> 1672 1800 1673 <section title="Request-Line" anchor="request-line"> 1674 <x:anchor-alias value="Request-Line"/> 1675 <t> 1676 The Request-Line begins with a method token, followed by a single 1677 space (SP), the request-target, another single space (SP), the 1678 protocol version, and ending with CRLF. 1679 </t> 1680 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-Line"/> 1681 <x:ref>Request-Line</x:ref> = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref> 1682 </artwork></figure> 1683 1684 <section title="Method" anchor="method"> 1685 <x:anchor-alias value="Method"/> 1686 <t> 1687 The Method token indicates the request method to be performed on the 1688 target resource. The request method is case-sensitive. 1689 </t> 1690 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/> 1691 <x:ref>Method</x:ref> = <x:ref>token</x:ref> 1692 </artwork></figure> 1693 <t> 1694 See &method; for further information, such as the list of methods defined 1695 by this specification, the IANA registry, and considerations for new methods. 1696 </t> 1697 </section> 1698 1699 <section title="request-target" anchor="request-target"> 1700 <x:anchor-alias value="request-target"/> 1701 <t> 1702 The request-target identifies the target resource upon which to apply 1703 the request. In most cases, the user agent is provided a URI reference 1801 <section title="Types of Request Target" anchor="request-target-types"> 1802 <t> 1803 In most cases, the user agent is provided a URI reference 1704 1804 from which it determines an absolute URI for identifying the target 1705 1805 resource. When a request to the resource is initiated, all or part 1706 1806 of that URI is used to construct the HTTP request-target. 1707 1807 </t> 1708 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/>1709 <x:ref>request-target</x:ref> = "*"1710 / <x:ref>absolute-URI</x:ref>1711 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] )1712 / <x:ref>authority</x:ref>1713 </artwork></figure>1714 1808 <t> 1715 1809 The four options for request-target are dependent on the nature of the … … 1817 1911 </t> 1818 1912 </x:note> 1819 <t>1820 HTTP does not place a pre-defined limit on the length of a request-target.1821 A server &MUST; be prepared to receive URIs of unbounded length and1822 respond with the 414 (URI Too Long) status code if the received1823 request-target would be longer than the server wishes to handle1824 (see &status-414;).1825 </t>1826 <t>1827 Various ad-hoc limitations on request-target length are found in practice.1828 It is &RECOMMENDED; that all HTTP senders and recipients support1829 request-target lengths of 8000 or more octets.1830 </t>1831 <x:note>1832 <t>1833 <x:h>Note:</x:h> Fragments (<xref target="RFC3986" x:fmt="," x:sec="3.5"/>)1834 are not part of the request-target and thus will not be transmitted1835 in an HTTP request.1836 </t>1837 </x:note>1838 </section>1839 1913 </section> 1840 1914 … … 1973 2047 [ <x:ref>message-body</x:ref> ] ; <xref target="message.body"/> 1974 2048 </artwork></figure> 1975 1976 <section title="Status-Line" anchor="status-line">1977 <x:anchor-alias value="Status-Line"/>1978 <t>1979 The first line of a Response message is the Status-Line, consisting1980 of the protocol version, a space (SP), the status code, another space,1981 a possibly-empty textual phrase describing the status code, and1982 ending with CRLF.1983 </t>1984 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Line"/>1985 <x:ref>Status-Line</x:ref> = <x:ref>HTTP-Version</x:ref> <x:ref>SP</x:ref> <x:ref>Status-Code</x:ref> <x:ref>SP</x:ref> <x:ref>Reason-Phrase</x:ref> <x:ref>CRLF</x:ref>1986 </artwork></figure>1987 1988 <section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase">1989 <x:anchor-alias value="Reason-Phrase"/>1990 <x:anchor-alias value="Status-Code"/>1991 <t>1992 The Status-Code element is a 3-digit integer result code of the attempt to1993 understand and satisfy the request. See &status-code-reasonphr; for1994 further information, such as the list of status codes defined by this1995 specification, the IANA registry, and considerations for new status codes.1996 </t>1997 <t>1998 The Reason Phrase exists for the sole purpose of providing a textual1999 description associated with the numeric status code, out of deference to2000 earlier Internet application protocols that were more frequently used with2001 interactive text clients. A client &SHOULD; ignore the content of the Reason2002 Phrase.2003 </t>2004 <t>2005 The first digit of the Status-Code defines the class of response. The2006 last two digits do not have any categorization role. There are 52007 values for the first digit:2008 <list style="symbols">2009 <t>2010 1xx: Informational - Request received, continuing process2011 </t>2012 <t>2013 2xx: Success - The action was successfully received,2014 understood, and accepted2015 </t>2016 <t>2017 3xx: Redirection - Further action must be taken in order to2018 complete the request2019 </t>2020 <t>2021 4xx: Client Error - The request contains bad syntax or cannot2022 be fulfilled2023 </t>2024 <t>2025 5xx: Server Error - The server failed to fulfill an apparently2026 valid request2027 </t>2028 </list>2029 </t>2030 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/>2031 <x:ref>Status-Code</x:ref> = 3<x:ref>DIGIT</x:ref>2032 <x:ref>Reason-Phrase</x:ref> = *( <x:ref>HTAB</x:ref> / <x:ref>SP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> )2033 </artwork></figure>2034 </section>2035 </section>2036 2049 2037 2050 </section>
Note: See TracChangeset
for help on using the changeset viewer.