Changeset 1431
- Timestamp:
- 02/09/11 00:24:29 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1427 r1431 382 382 <link rel="Index" href="#rfc.index"> 383 383 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 384 <link rel="Chapter" title="2 HTTP-related architecture" href="#rfc.section.2">384 <link rel="Chapter" title="2 Architecture" href="#rfc.section.2"> 385 385 <link rel="Chapter" title="3 Message Format" href="#rfc.section.3"> 386 386 <link rel="Chapter" title="4 Request" href="#rfc.section.4"> … … 554 554 </ul> 555 555 </li> 556 <li>2. <a href="#architecture"> HTTP-related architecture</a><ul>556 <li>2. <a href="#architecture">Architecture</a><ul> 557 557 <li>2.1 <a href="#operation">Client/Server Messaging</a></li> 558 558 <li>2.2 <a href="#message-orientation-and-buffering">Message Orientation and Buffering</a></li> … … 570 570 </li> 571 571 <li>3. <a href="#http.message">Message Format</a><ul> 572 <li>3.1 <a href="# message.robustness">Message Parsing and Robustness</a></li>572 <li>3.1 <a href="#start.line">Start Line</a></li> 573 573 <li>3.2 <a href="#header.fields">Header Fields</a><ul> 574 574 <li>3.2.1 <a href="#field.parsing">Field Parsing</a></li> … … 578 578 </li> 579 579 <li>3.3 <a href="#message.body">Message Body</a></li> 580 <li>3.4 <a href="#incomplete.messages"> Incomplete Messages</a></li>581 <li>3.5 <a href="# general.header.fields">General Header Fields</a></li>580 <li>3.4 <a href="#incomplete.messages">Handling Incomplete Messages</a></li> 581 <li>3.5 <a href="#message.robustness">Message Parsing Robustness</a></li> 582 582 </ul> 583 583 </li> … … 853 853 ; obsolete line folding 854 854 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.1</a> 855 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture"> HTTP-related architecture</a></h1>855 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">Architecture</a></h1> 856 856 <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide 857 857 hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP. … … 1172 1172 the end of the header section, and an optional message-body. 1173 1173 </p> 1174 <p id="rfc.section.3.p.2">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two 1174 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a> 1175 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1176 <a href="#core.rules" class="smpl">CRLF</a> 1177 [ <a href="#message.body" class="smpl">message-body</a> ] 1178 </pre><p id="rfc.section.3.p.3">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a 1179 hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If 1180 a message-body has been indicated, then it is read as a stream until an amount of octets equal to the message-body length 1181 is read or the connection is closed. 1182 </p> 1183 <p id="rfc.section.3.p.4">Recipients <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities 1184 due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet 1185 LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from 1186 the message, such as within a header field-value after message parsing has delineated the individual fields. 1187 </p> 1188 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="start.line" href="#start.line">Start Line</a></h2> 1189 <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two 1175 1190 types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses), 1176 1191 and in the algorithm for determining the length of the message-body (<a href="#message.body" title="Message Body">Section 3.3</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different … … 1178 1193 or invalid request method) and clients are implemented to only expect a response. 1179 1194 </p> 1180 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a> 1181 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1182 <a href="#core.rules" class="smpl">CRLF</a> 1183 [ <a href="#message.body" class="smpl">message-body</a> ] 1184 <a href="#http.message" class="smpl">start-line</a> = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a> 1185 </pre><p id="rfc.section.3.p.4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an 1195 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a> 1196 </pre><p id="rfc.section.3.1.p.4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an 1186 1197 attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might 1187 1198 result in a security vulnerability if other implementations within the request chain interpret the same message differently. 1188 1199 Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing. 1189 1200 </p> 1190 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="message.robustness" href="#message.robustness">Message Parsing and Robustness</a></h2>1191 <p id="rfc.section.3.1.p.1">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a1192 hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If1193 a message-body has been indicated, then it is read as a stream until an amount of octets equal to the message-body length1194 is read or the connection is closed.1195 </p>1196 <p id="rfc.section.3.1.p.2">Recipients <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities1197 due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet1198 LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from1199 the message, such as within a header field-value after message parsing has delineated the individual fields.1200 </p>1201 <p id="rfc.section.3.1.p.3">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server1202 applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then1203 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length.1204 </p>1205 <p id="rfc.section.3.1.p.4">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol1206 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend1207 that recipients recognize a single LF as a line terminator and ignore any CR.1208 </p>1209 <p id="rfc.section.3.1.p.5">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request1210 message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed1211 above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response.1212 </p>1213 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> 1214 1202 <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 1215 1203 value. 1216 1204 </p> 1217 <div id="rfc.figure.u.2 0"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#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>1205 <div id="rfc.figure.u.21"></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> 1218 1206 <a href="#header.fields" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1219 1207 <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> ) … … 1276 1264 </p> 1277 1265 </div> 1278 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <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>1266 <div id="rfc.figure.u.22"></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> 1279 1267 1280 1268 <a href="#rule.token.separators" class="smpl">token</a> = 1*<a href="#rule.token.separators" class="smpl">tchar</a> … … 1291 1279 <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> 1292 1280 </div> 1293 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#rule.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>1281 <div id="rfc.figure.u.23"></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> 1294 1282 <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> 1295 1283 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF … … 1297 1285 <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> 1298 1286 </div> 1299 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.40"></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> )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> ) 1300 1288 </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. 1301 1289 </p> … … 1307 1295 </p> 1308 1296 </div> 1309 <div id="rfc.figure.u.2 4"></div><pre class="inline"><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></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> ) ")"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> ) ")" 1310 1298 <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> 1311 1299 </pre><div id="rule.quoted-cpair"> 1312 1300 <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> 1313 1301 </div> 1314 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.43"></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> )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> ) 1315 1303 </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 1316 1304 ")"). … … 1318 1306 <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> 1319 1307 <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> 1320 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET1308 <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> = *OCTET 1321 1309 </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 1322 1310 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. … … 1400 1388 knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. 1401 1389 </p> 1402 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="incomplete.messages" href="#incomplete.messages"> Incomplete Messages</a></h2>1390 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2> 1403 1391 <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. 1404 1392 </p> … … 1420 1408 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 7.1.2.2</a>. 1421 1409 </p> 1422 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2> 1423 <p id="rfc.section.3.5.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply 1424 to the payload being transferred. These header fields apply only to the message being transmitted. 1425 </p> 1426 <div id="rfc.table.u.1"> 1427 <table class="tt full left" cellpadding="3" cellspacing="0"> 1428 <thead> 1429 <tr> 1430 <th>Header Field Name</th> 1431 <th>Defined in...</th> 1432 </tr> 1433 </thead> 1434 <tbody> 1435 <tr> 1436 <td class="left">Connection</td> 1437 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 9.1</a></td> 1438 </tr> 1439 <tr> 1440 <td class="left">Date</td> 1441 <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 9.3</a></td> 1442 </tr> 1443 <tr> 1444 <td class="left">Trailer</td> 1445 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 9.6</a></td> 1446 </tr> 1447 <tr> 1448 <td class="left">Transfer-Encoding</td> 1449 <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 9.7</a></td> 1450 </tr> 1451 <tr> 1452 <td class="left">Upgrade</td> 1453 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 9.8</a></td> 1454 </tr> 1455 <tr> 1456 <td class="left">Via</td> 1457 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 9.9</a></td> 1458 </tr> 1459 </tbody> 1460 </table> 1461 </div> 1410 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> 1411 <p id="rfc.section.3.5.p.1">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server 1412 applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then 1413 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length. 1414 </p> 1415 <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol 1416 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend 1417 that recipients recognize a single LF as a line terminator and ignore any CR. 1418 </p> 1419 <p id="rfc.section.3.5.p.3">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request 1420 message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed 1421 above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response. 1422 </p> 1462 1423 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="request" href="#request">Request</a></h1> 1463 1424 <p id="rfc.section.4.p.1">A request message from a client to a server begins with a Request-Line, followed by zero or more header fields, an empty line 1464 1425 signifying the end of the header block, and an optional message body. 1465 1426 </p> 1466 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.45"></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>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> 1467 1428 *( <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> 1468 1429 <a href="#core.rules" class="smpl">CRLF</a> … … 1472 1433 the protocol version, and ending with CRLF. 1473 1434 </p> 1474 <div id="rfc.figure.u.2 8"></div><pre class="inline"><span id="rfc.iref.g.46"></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>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> 1475 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> 1476 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> 1477 <div id="rfc.figure.u. 29"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a>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> 1478 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 1479 1440 for new methods. … … 1484 1445 is initiated, all or part of that URI is used to construct the HTTP request-target. 1485 1446 </p> 1486 <div id="rfc.figure.u.3 0"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#request-target" class="smpl">request-target</a> = "*"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> = "*" 1487 1448 / <a href="#uri" class="smpl">absolute-URI</a> 1488 1449 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) … … 1492 1453 process) rather than to a specific named resource at that server. For example, 1493 1454 </p> 1494 <div id="rfc.figure.u.3 1"></div><pre class="text2">OPTIONS * HTTP/1.11455 <div id="rfc.figure.u.32"></div><pre class="text2">OPTIONS * HTTP/1.1 1495 1456 </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 valid 1496 1457 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 … … 1498 1459 address. An example Request-Line would be: 1499 1460 </p> 1500 <div id="rfc.figure.u.3 2"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11461 <div id="rfc.figure.u.33"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1501 1462 </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. 1502 1463 </p> … … 1510 1471 send the lines: 1511 1472 </p> 1512 <div id="rfc.figure.u.3 3"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.11473 <div id="rfc.figure.u.34"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1 1513 1474 Host: www.example.org 1514 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; … … 1518 1479 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. 1519 1480 </p> 1520 <div id="rfc.figure.u.3 4"></div>1481 <div id="rfc.figure.u.35"></div> 1521 1482 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1522 </pre><div id="rfc.figure.u.3 5"></div>1483 </pre><div id="rfc.figure.u.36"></div> 1523 1484 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1524 1485 Host: www.example.org:8001 … … 1590 1551 </p> 1591 1552 <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 1592 <div id="rfc.figure.u.3 6"></div>1553 <div id="rfc.figure.u.37"></div> 1593 1554 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1594 1555 Host: www.example.org:8080 … … 1596 1557 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 1597 1558 </p> 1598 <div id="rfc.figure.u.3 7"></div>1559 <div id="rfc.figure.u.38"></div> 1599 1560 <p>Example 2: the effective request URI for the message</p> <pre class="text">OPTIONS * HTTP/1.1 1600 1561 Host: www.example.org … … 1606 1567 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1> 1607 1568 <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1608 <div id="rfc.figure.u.3 8"></div><pre class="inline"><span id="rfc.iref.g.49"></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>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> 1609 1570 *( <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> 1610 1571 <a href="#core.rules" class="smpl">CRLF</a> … … 1614 1575 another space, a possibly-empty textual phrase describing the status code, and ending with CRLF. 1615 1576 </p> 1616 <div id="rfc.figure.u. 39"></div><pre class="inline"><span id="rfc.iref.g.50"></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>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> 1617 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> 1618 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 considerations … … 1633 1594 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1634 1595 </ul> 1635 <div id="rfc.figure.u.4 0"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>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> 1636 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> ) 1637 1598 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> … … 1640 1601 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>: 1641 1602 </p> 1642 <div id="rfc.figure.u.4 1"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 11231603 <div id="rfc.figure.u.42"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1643 1604 </pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> 1644 <div id="rfc.figure.u.4 2"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format1605 <div id="rfc.figure.u.43"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1645 1606 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1646 1607 </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. … … 1650 1611 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. 1651 1612 </p> 1652 <div id="rfc.figure.u.4 3"></div><pre class="inline"><span id="rfc.iref.g.53"></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>1613 <div id="rfc.figure.u.44"></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> 1653 1614 </pre><div id="preferred.date.format"> 1654 1615 <p id="rfc.section.6.1.p.8"> Preferred format:</p> 1655 1616 </div> 1656 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><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> <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>1617 <div id="rfc.figure.u.45"></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> 1657 1618 ; fixed length subset of the format defined in 1658 1619 ; <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> … … 1697 1658 <p id="rfc.section.6.1.p.11"> Obsolete formats:</p> 1698 1659 </div> 1699 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.66"></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>1700 </pre><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">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>1660 <div id="rfc.figure.u.46"></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.47"></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> 1701 1662 <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> 1702 1663 ; day-month-year (e.g., 02-Jun-82) … … 1709 1670 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1710 1671 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1711 </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">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>1672 </pre><div id="rfc.figure.u.48"></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> 1712 1673 <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> )) 1713 1674 ; month day (e.g., Jun 2) … … 1727 1688 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1728 1689 </p> 1729 <div id="rfc.figure.u.4 8"></div><pre class="inline"><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>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> 1730 1691 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 6.2.2.1</a> 1731 1692 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> … … 1736 1697 <p id="rfc.section.6.2.p.3"> Parameters are in the form of attribute/value pairs.</p> 1737 1698 </div> 1738 <div id="rfc.figure.u. 49"></div><pre class="inline"><span id="rfc.iref.g.71"></span><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> <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>1699 <div id="rfc.figure.u.50"></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> 1739 1700 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1740 1701 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1741 </pre><p id="rfc.section.6.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 9.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding. 3" title="Transfer-Encoding">Section 9.7</a>).1702 </pre><p id="rfc.section.6.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 9.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 9.7</a>). 1742 1703 </p> 1743 1704 <p id="rfc.section.6.2.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport … … 1754 1715 for the recipient to verify that it has received the full message. 1755 1716 </p> 1756 <div id="rfc.figure.u.5 0"></div><pre class="inline"><span id="rfc.iref.g.76"></span><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> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1717 <div id="rfc.figure.u.51"></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> 1757 1718 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1758 1719 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1778 1739 </p> 1779 1740 <p id="rfc.section.6.2.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field 1780 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer. 2" title="Trailer">Section 9.6</a>).1741 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 9.6</a>). 1781 1742 </p> 1782 1743 <p id="rfc.section.6.2.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: … … 1797 1758 </p> 1798 1759 <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> 1799 <div id="rfc.figure.u.5 1"></div><pre class="text"> length := 01760 <div id="rfc.figure.u.52"></div><pre class="text"> length := 0 1800 1761 read chunk-size, chunk-ext (if any) and CRLF 1801 1762 while (chunk-size > 0) { … … 1844 1805 </p> 1845 1806 </div> 1846 <div id="rfc.iref.g.8 7"></div>1807 <div id="rfc.iref.g.88"></div> 1847 1808 <div id="rfc.iref.c.11"></div> 1848 1809 <h4 id="rfc.section.6.2.2.3"><a href="#rfc.section.6.2.2.3">6.2.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4> … … 1869 1830 By convention, the products are listed in order of their significance for identifying the application. 1870 1831 </p> 1871 <div id="rfc.figure.u.5 2"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></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>]1832 <div id="rfc.figure.u.53"></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>] 1872 1833 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1873 1834 </pre><p id="rfc.section.6.3.p.3">Examples:</p> 1874 <div id="rfc.figure.u.5 3"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31835 <div id="rfc.figure.u.54"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1875 1836 Server: Apache/0.8.4 1876 1837 </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). … … 1881 1842 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. 1882 1843 </p> 1883 <div id="rfc.figure.u.5 4"></div><pre class="inline"><span id="rfc.iref.g.90"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1844 <div id="rfc.figure.u.55"></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> ] ) 1884 1845 / ( "1" [ "." 0*3("0") ] ) 1885 1846 </pre><div class="note" id="rfc.section.6.4.p.3"> … … 1919 1880 </p> 1920 1881 <p id="rfc.section.7.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 1921 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 5" title="Connection">Section 9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.1882 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 1922 1883 </p> 1923 1884 <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> … … 1945 1906 </p> 1946 1907 <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3> 1947 <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection. 6" title="Connection">Section 9.1</a>.1908 <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 9.1</a>. 1948 1909 </p> 1949 1910 <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects … … 1974 1935 </ul> 1975 1936 <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> 1976 <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 7" title="Connection">Section 9.1</a>).1937 <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 9.1</a>). 1977 1938 </p> 1978 1939 <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4> … … 2152 2113 </p> 2153 2114 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 2154 <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP header fields related to message framing and transport protocols.</p> 2115 <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP header fields related to message origination, framing, and routing.</p> 2116 <div id="rfc.table.u.1"> 2117 <table class="tt full left" cellpadding="3" cellspacing="0"> 2118 <thead> 2119 <tr> 2120 <th>Header Field Name</th> 2121 <th>Defined in...</th> 2122 </tr> 2123 </thead> 2124 <tbody> 2125 <tr> 2126 <td class="left">Connection</td> 2127 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 9.1</a></td> 2128 </tr> 2129 <tr> 2130 <td class="left">Content-Length</td> 2131 <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 9.2</a></td> 2132 </tr> 2133 <tr> 2134 <td class="left">Date</td> 2135 <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 9.3</a></td> 2136 </tr> 2137 <tr> 2138 <td class="left">Host</td> 2139 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 9.4</a></td> 2140 </tr> 2141 <tr> 2142 <td class="left">TE</td> 2143 <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 9.5</a></td> 2144 </tr> 2145 <tr> 2146 <td class="left">Trailer</td> 2147 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 9.6</a></td> 2148 </tr> 2149 <tr> 2150 <td class="left">Transfer-Encoding</td> 2151 <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 9.7</a></td> 2152 </tr> 2153 <tr> 2154 <td class="left">Upgrade</td> 2155 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 9.8</a></td> 2156 </tr> 2157 <tr> 2158 <td class="left">Via</td> 2159 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 9.9</a></td> 2160 </tr> 2161 </tbody> 2162 </table> 2163 </div> 2155 2164 <div id="rfc.iref.c.12"></div> 2156 2165 <div id="rfc.iref.h.6"></div> … … 2164 2173 </p> 2165 2174 <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p> 2166 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a>2175 <div id="rfc.figure.u.56"></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> 2167 2176 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 2168 2177 </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 … … 2187 2196 of the response. For example, 2188 2197 </p> 2189 <div id="rfc.figure.u.5 6"></div><pre class="text"> Connection: close2198 <div id="rfc.figure.u.57"></div><pre class="text"> Connection: close 2190 2199 </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. 2191 2200 </p> … … 2203 2212 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 2204 2213 </p> 2205 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.93"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>2214 <div id="rfc.figure.u.58"></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> 2206 2215 </pre><p id="rfc.section.9.2.p.3">An example is</p> 2207 <div id="rfc.figure.u.5 8"></div><pre class="text"> Content-Length: 34952216 <div id="rfc.figure.u.59"></div><pre class="text"> Content-Length: 3495 2208 2217 </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 2209 2218 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. … … 2219 2228 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. 2220 2229 </p> 2221 <div id="rfc.figure.u. 59"></div><pre class="inline"><span id="rfc.iref.g.94"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>2230 <div id="rfc.figure.u.60"></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> 2222 2231 </pre><p id="rfc.section.9.3.p.3">An example is</p> 2223 <div id="rfc.figure.u.6 0"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2232 <div id="rfc.figure.u.61"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2224 2233 </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: 2225 2234 </p> … … 2255 2264 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. 2256 2265 </p> 2257 <div id="rfc.figure.u.6 1"></div><pre class="inline"><span id="rfc.iref.g.95"></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>2266 <div id="rfc.figure.u.62"></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> 2258 2267 </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 2259 2268 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. 2260 2269 </p> 2261 2270 <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> 2262 <div id="rfc.figure.u.6 2"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12271 <div id="rfc.figure.u.63"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2263 2272 Host: www.example.org 2264 2273 </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 … … 2287 2296 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 2288 2297 </p> 2289 <div id="rfc.figure.u.6 3"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>2298 <div id="rfc.figure.u.64"></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> 2290 2299 <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> ] ) 2291 2300 <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> ) … … 2295 2304 </p> 2296 2305 <p id="rfc.section.9.5.p.5">Examples of its use are:</p> 2297 <div id="rfc.figure.u.6 4"></div><pre class="text"> TE: deflate2306 <div id="rfc.figure.u.65"></div><pre class="text"> TE: deflate 2298 2307 TE: 2299 2308 TE: trailers, deflate;q=0.5 … … 2332 2341 chunked transfer-coding. 2333 2342 </p> 2334 <div id="rfc.figure.u.6 5"></div><pre class="inline"><span id="rfc.iref.g.100"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>2343 <div id="rfc.figure.u.66"></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> 2335 2344 </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 2336 2345 to know which header fields to expect in the trailer. … … 2352 2361 are not. 2353 2362 </p> 2354 <div id="rfc.figure.u.6 6"></div><pre class="inline"><span id="rfc.iref.g.101"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>2363 <div id="rfc.figure.u.67"></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> 2355 2364 </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: 2356 2365 </p> 2357 <div id="rfc.figure.u.6 7"></div><pre class="text"> Transfer-Encoding: chunked2366 <div id="rfc.figure.u.68"></div><pre class="text"> Transfer-Encoding: chunked 2358 2367 </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. 2359 2368 </p> … … 2365 2374 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2366 2375 </p> 2367 <div id="rfc.figure.u.6 8"></div><pre class="inline"><span id="rfc.iref.g.102"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>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> 2368 2377 </pre><p id="rfc.section.9.8.p.3">For example,</p> 2369 <div id="rfc.figure.u. 69"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112378 <div id="rfc.figure.u.70"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2370 2379 </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 2371 2380 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2422 2431 of all senders along the request/response chain. 2423 2432 </p> 2424 <div id="rfc.figure.u.7 0"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></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>2433 <div id="rfc.figure.u.71"></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> 2425 2434 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2426 2435 <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> … … 2446 2455 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2447 2456 </p> 2448 <div id="rfc.figure.u.7 1"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2457 <div id="rfc.figure.u.72"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2449 2458 </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, 2450 2459 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. … … 2453 2462 For example, 2454 2463 </p> 2455 <div id="rfc.figure.u.7 2"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2464 <div id="rfc.figure.u.73"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2456 2465 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p> 2457 <div id="rfc.figure.u.7 3"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2466 <div id="rfc.figure.u.74"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2458 2467 </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 2459 2468 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2486 2495 <td class="left">http</td> 2487 2496 <td class="left">standard</td> 2488 <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length. 2" title="Content-Length">Section 9.2</a>2497 <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section 9.2</a> 2489 2498 </td> 2490 2499 </tr> … … 2500 2509 <td class="left">http</td> 2501 2510 <td class="left">standard</td> 2502 <td class="left"> <a href="#header.host" id="rfc.xref.header.host. 2" title="Host">Section 9.4</a>2511 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a> 2503 2512 </td> 2504 2513 </tr> … … 2507 2516 <td class="left">http</td> 2508 2517 <td class="left">standard</td> 2509 <td class="left"> <a href="#header.te" id="rfc.xref.header.te. 4" title="TE">Section 9.5</a>2518 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section 9.5</a> 2510 2519 </td> 2511 2520 </tr> … … 3065 3074 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3066 3075 <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> 3067 <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. 3" 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.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. 3068 3077 </p> 3069 3078 <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 … … 3125 3134 </p> 3126 3135 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3127 <div id="rfc.figure.u.7 4"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS3136 <div id="rfc.figure.u.75"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3128 3137 3129 3138 <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF … … 3291 3300 3292 3301 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3293 </pre> <div id="rfc.figure.u.7 5"></div>3302 </pre> <div id="rfc.figure.u.76"></div> 3294 3303 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3295 3304 ; Connection defined but not used … … 3696 3705 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3697 3706 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3698 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4"> 3.5</a>, <a href="#rfc.xref.header.connection.5">7.1.2</a>, <a href="#rfc.xref.header.connection.6">7.1.3</a>, <a href="#rfc.xref.header.connection.7">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>3699 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc. iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>3707 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.xref.header.connection.7">9</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li> 3708 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">9</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.3">10.1</a></li> 3700 3709 </ul> 3701 3710 </li> 3702 3711 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3703 <li>Date header field <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2"> 3.5</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li>3712 <li>Date header field <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">9</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li> 3704 3713 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.2.2.2</a></li> 3705 3714 <li>downstream <a href="#rfc.iref.d.1"><b>2.4</b></a></li> … … 3716 3725 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3717 3726 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3718 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.6 8"><b>6.1</b></a></li>3719 <li><tt>attribute</tt> <a href="#rfc.iref.g.7 2"><b>6.2</b></a></li>3727 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.69"><b>6.1</b></a></li> 3728 <li><tt>attribute</tt> <a href="#rfc.iref.g.73"><b>6.2</b></a></li> 3720 3729 <li><tt>authority</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3721 3730 <li><tt>BWS</tt> <a href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 3722 <li><tt>chunk</tt> <a href="#rfc.iref.g.7 7"><b>6.2.1</b></a></li>3723 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.8 3"><b>6.2.1</b></a></li>3724 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.8 0"><b>6.2.1</b></a></li>3725 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.8 1"><b>6.2.1</b></a></li>3726 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.8 2"><b>6.2.1</b></a></li>3727 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.7 8"><b>6.2.1</b></a></li>3728 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g.7 6"><b>6.2.1</b></a></li>3729 <li><tt>comment</tt> <a href="#rfc.iref.g.4 1"><b>3.2.3</b></a></li>3730 <li><tt>Connection</tt> <a href="#rfc.iref.g.9 1"><b>9.1</b></a></li>3731 <li><tt>connection-token</tt> <a href="#rfc.iref.g.9 2"><b>9.1</b></a></li>3732 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.9 3"><b>9.2</b></a></li>3731 <li><tt>chunk</tt> <a href="#rfc.iref.g.78"><b>6.2.1</b></a></li> 3732 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.84"><b>6.2.1</b></a></li> 3733 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.81"><b>6.2.1</b></a></li> 3734 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.82"><b>6.2.1</b></a></li> 3735 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.83"><b>6.2.1</b></a></li> 3736 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.79"><b>6.2.1</b></a></li> 3737 <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.42"><b>3.2.3</b></a></li> 3739 <li><tt>Connection</tt> <a href="#rfc.iref.g.92"><b>9.1</b></a></li> 3740 <li><tt>connection-token</tt> <a href="#rfc.iref.g.93"><b>9.1</b></a></li> 3741 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.94"><b>9.2</b></a></li> 3733 3742 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3734 3743 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3735 <li><tt>ctext</tt> <a href="#rfc.iref.g.4 2"><b>3.2.3</b></a></li>3744 <li><tt>ctext</tt> <a href="#rfc.iref.g.43"><b>3.2.3</b></a></li> 3736 3745 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3737 <li><tt>Date</tt> <a href="#rfc.iref.g.9 4"><b>9.3</b></a></li>3738 <li><tt>date1</tt> <a href="#rfc.iref.g.5 5"><b>6.1</b></a></li>3739 <li><tt>date2</tt> <a href="#rfc.iref.g.7 4"><b>6.2</b></a></li>3740 <li><tt>date3</tt> <a href="#rfc.iref.g.7 5"><b>6.2</b></a></li>3741 <li><tt>day</tt> <a href="#rfc.iref.g.6 2"><b>6.1</b></a></li>3742 <li><tt>day-name</tt> <a href="#rfc.iref.g.6 0"><b>6.1</b></a></li>3743 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.6 1"><b>6.1</b></a></li>3746 <li><tt>Date</tt> <a href="#rfc.iref.g.95"><b>9.3</b></a></li> 3747 <li><tt>date1</tt> <a href="#rfc.iref.g.56"><b>6.1</b></a></li> 3748 <li><tt>date2</tt> <a href="#rfc.iref.g.75"><b>6.2</b></a></li> 3749 <li><tt>date3</tt> <a href="#rfc.iref.g.76"><b>6.2</b></a></li> 3750 <li><tt>day</tt> <a href="#rfc.iref.g.63"><b>6.1</b></a></li> 3751 <li><tt>day-name</tt> <a href="#rfc.iref.g.61"><b>6.1</b></a></li> 3752 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.62"><b>6.1</b></a></li> 3744 3753 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3745 3754 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> 3746 <li><tt>field-content</tt> <a href="#rfc.iref.g.3 2"><b>3.2</b></a></li>3747 <li><tt>field-name</tt> <a href="#rfc.iref.g.3 0"><b>3.2</b></a></li>3748 <li><tt>field-value</tt> <a href="#rfc.iref.g.3 1"><b>3.2</b></a></li>3749 <li><tt>GMT</tt> <a href="#rfc.iref.g.6 5"><b>6.1</b></a></li>3750 <li><tt>header-field</tt> <a href="#rfc.iref.g. 29"><b>3.2</b></a></li>3755 <li><tt>field-content</tt> <a href="#rfc.iref.g.33"><b>3.2</b></a></li> 3756 <li><tt>field-name</tt> <a href="#rfc.iref.g.31"><b>3.2</b></a></li> 3757 <li><tt>field-value</tt> <a href="#rfc.iref.g.32"><b>3.2</b></a></li> 3758 <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.30"><b>3.2</b></a></li> 3751 3760 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3752 <li><tt>Host</tt> <a href="#rfc.iref.g.9 5"><b>9.4</b></a></li>3753 <li><tt>hour</tt> <a href="#rfc.iref.g.5 7"><b>6.1</b></a></li>3761 <li><tt>Host</tt> <a href="#rfc.iref.g.96"><b>9.4</b></a></li> 3762 <li><tt>hour</tt> <a href="#rfc.iref.g.58"><b>6.1</b></a></li> 3754 3763 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3755 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.5 3"><b>6.1</b></a></li>3764 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.54"><b>6.1</b></a></li> 3756 3765 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.28"><b>3</b></a></li> 3757 3766 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g.18"><b>2.6</b></a></li> … … 3759 3768 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.17"><b>2.6</b></a></li> 3760 3769 <li><tt>https-URI</tt> <a href="#rfc.iref.g.27"><b>2.7.2</b></a></li> 3761 <li><tt>last-chunk</tt> <a href="#rfc.iref.g. 79"><b>6.2.1</b></a></li>3770 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.80"><b>6.2.1</b></a></li> 3762 3771 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3763 <li><tt>message-body</tt> <a href="#rfc.iref.g.4 4"><b>3.3</b></a></li>3764 <li><tt>Method</tt> <a href="#rfc.iref.g.4 7"><b>4.1.1</b></a></li>3765 <li><tt>minute</tt> <a href="#rfc.iref.g.5 8"><b>6.1</b></a></li>3766 <li><tt>month</tt> <a href="#rfc.iref.g.6 3"><b>6.1</b></a></li>3767 <li><tt>obs-date</tt> <a href="#rfc.iref.g.6 6"><b>6.1</b></a></li>3768 <li><tt>obs-text</tt> <a href="#rfc.iref.g. 39"><b>3.2.3</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> 3774 <li><tt>minute</tt> <a href="#rfc.iref.g.59"><b>6.1</b></a></li> 3775 <li><tt>month</tt> <a href="#rfc.iref.g.64"><b>6.1</b></a></li> 3776 <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.40"><b>3.2.3</b></a></li> 3769 3778 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3770 3779 <li><tt>OWS</tt> <a href="#rfc.iref.g.13"><b>1.2.2</b></a></li> 3771 3780 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3772 3781 <li><tt>port</tt> <a href="#rfc.iref.g.23"><b>2.7</b></a></li> 3773 <li><tt>product</tt> <a href="#rfc.iref.g.8 8"><b>6.3</b></a></li>3774 <li><tt>product-version</tt> <a href="#rfc.iref.g. 89"><b>6.3</b></a></li>3775 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.10 5"><b>9.9</b></a></li>3776 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.10 6"><b>9.9</b></a></li>3777 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.10 8"><b>9.9</b></a></li>3778 <li><tt>qdtext</tt> <a href="#rfc.iref.g.3 8"><b>3.2.3</b></a></li>3779 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.8 6"><b>6.2.1</b></a></li>3782 <li><tt>product</tt> <a href="#rfc.iref.g.89"><b>6.3</b></a></li> 3783 <li><tt>product-version</tt> <a href="#rfc.iref.g.90"><b>6.3</b></a></li> 3784 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.106"><b>9.9</b></a></li> 3785 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.107"><b>9.9</b></a></li> 3786 <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> 3788 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.87"><b>6.2.1</b></a></li> 3780 3789 <li><tt>query</tt> <a href="#rfc.iref.g.24"><b>2.7</b></a></li> 3781 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.4 3"><b>3.2.3</b></a></li>3782 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.4 0"><b>3.2.3</b></a></li>3783 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.8 5"><b>6.2.1</b></a></li>3784 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.3 7"><b>3.2.3</b></a></li>3785 <li><tt>qvalue</tt> <a href="#rfc.iref.g.9 0"><b>6.4</b></a></li>3786 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.5 2"><b>5.1.1</b></a></li>3787 <li><tt>received-by</tt> <a href="#rfc.iref.g.10 7"><b>9.9</b></a></li>3788 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.10 4"><b>9.9</b></a></li>3789 <li><tt>Request</tt> <a href="#rfc.iref.g.4 5"><b>4</b></a></li>3790 <li><tt>Request-Line</tt> <a href="#rfc.iref.g.4 6"><b>4.1</b></a></li>3791 <li><tt>request-target</tt> <a href="#rfc.iref.g.4 8"><b>4.1.2</b></a></li>3792 <li><tt>Response</tt> <a href="#rfc.iref.g. 49"><b>5</b></a></li>3793 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.5 4"><b>6.1</b></a></li>3794 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.6 7"><b>6.1</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.41"><b>3.2.3</b></a></li> 3792 <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> 3794 <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> 3796 <li><tt>received-by</tt> <a href="#rfc.iref.g.108"><b>9.9</b></a></li> 3797 <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.50"><b>5</b></a></li> 3802 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.55"><b>6.1</b></a></li> 3803 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.68"><b>6.1</b></a></li> 3795 3804 <li><tt>RWS</tt> <a href="#rfc.iref.g.14"><b>1.2.2</b></a></li> 3796 <li><tt>second</tt> <a href="#rfc.iref.g. 59"><b>6.1</b></a></li>3805 <li><tt>second</tt> <a href="#rfc.iref.g.60"><b>6.1</b></a></li> 3797 3806 <li>SP <a href="#rfc.iref.g.11"><b>1.2</b></a></li> 3798 <li><tt>special</tt> <a href="#rfc.iref.g.36"><b>3.2.3</b></a></li> 3799 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.51"><b>5.1.1</b></a></li> 3800 <li><tt>Status-Line</tt> <a href="#rfc.iref.g.50"><b>5.1</b></a></li> 3801 <li><tt>t-codings</tt> <a href="#rfc.iref.g.97"><b>9.5</b></a></li> 3802 <li><tt>tchar</tt> <a href="#rfc.iref.g.35"><b>3.2.3</b></a></li> 3803 <li><tt>TE</tt> <a href="#rfc.iref.g.96"><b>9.5</b></a></li> 3804 <li><tt>te-ext</tt> <a href="#rfc.iref.g.99"><b>9.5</b></a></li> 3805 <li><tt>te-params</tt> <a href="#rfc.iref.g.98"><b>9.5</b></a></li> 3806 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.56"><b>6.1</b></a></li> 3807 <li><tt>token</tt> <a href="#rfc.iref.g.34"><b>3.2.3</b></a></li> 3808 <li><tt>Trailer</tt> <a href="#rfc.iref.g.100"><b>9.6</b></a></li> 3809 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.84"><b>6.2.1</b></a></li> 3810 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.69"><b>6.2</b></a></li> 3811 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.101"><b>9.7</b></a></li> 3812 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.70"><b>6.2</b></a></li> 3813 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.71"><b>6.2</b></a></li> 3814 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.102"><b>9.8</b></a></li> 3807 <li><tt>special</tt> <a href="#rfc.iref.g.37"><b>3.2.3</b></a></li> 3808 <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> 3811 <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> 3813 <li><tt>TE</tt> <a href="#rfc.iref.g.97"><b>9.5</b></a></li> 3814 <li><tt>te-ext</tt> <a href="#rfc.iref.g.100"><b>9.5</b></a></li> 3815 <li><tt>te-params</tt> <a href="#rfc.iref.g.99"><b>9.5</b></a></li> 3816 <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> 3818 <li><tt>Trailer</tt> <a href="#rfc.iref.g.101"><b>9.6</b></a></li> 3819 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.85"><b>6.2.1</b></a></li> 3820 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.70"><b>6.2</b></a></li> 3821 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.102"><b>9.7</b></a></li> 3822 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.71"><b>6.2</b></a></li> 3823 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.72"><b>6.2</b></a></li> 3824 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.103"><b>9.8</b></a></li> 3815 3825 <li><tt>uri-host</tt> <a href="#rfc.iref.g.25"><b>2.7</b></a></li> 3816 3826 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3817 <li><tt>value</tt> <a href="#rfc.iref.g.7 3"><b>6.2</b></a></li>3827 <li><tt>value</tt> <a href="#rfc.iref.g.74"><b>6.2</b></a></li> 3818 3828 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3819 <li><tt>Via</tt> <a href="#rfc.iref.g.10 3"><b>9.9</b></a></li>3820 <li><tt>word</tt> <a href="#rfc.iref.g.3 3"><b>3.2.3</b></a></li>3821 <li><tt>year</tt> <a href="#rfc.iref.g.6 4"><b>6.1</b></a></li>3829 <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> 3831 <li><tt>year</tt> <a href="#rfc.iref.g.65"><b>6.1</b></a></li> 3822 3832 </ul> 3823 3833 </li> 3824 <li>gzip (Coding Format) <a href="#rfc.iref.g.8 7">6.2.2.3</a></li>3834 <li>gzip (Coding Format) <a href="#rfc.iref.g.88">6.2.2.3</a></li> 3825 3835 </ul> 3826 3836 </li> … … 3829 3839 <li>Header Fields 3830 3840 <ul> 3831 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4"> 3.5</a>, <a href="#rfc.xref.header.connection.5">7.1.2</a>, <a href="#rfc.xref.header.connection.6">7.1.3</a>, <a href="#rfc.xref.header.connection.7">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>3832 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc. iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>3833 <li>Date <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2"> 3.5</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li>3834 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc. iref.h.10"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>3835 <li>TE <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc. iref.h.11"><b>9.5</b></a>, <a href="#rfc.xref.header.te.4">10.1</a></li>3836 <li>Trailer <a href="#rfc.xref.header.trailer.1"> 3.5</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>3837 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2"> 3.5</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>3838 <li>Upgrade <a href="#rfc.xref.header.upgrade.1"> 3.5</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3839 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2"> 3.5</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>3841 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.xref.header.connection.7">9</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li> 3842 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">9</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.3">10.1</a></li> 3843 <li>Date <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">9</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li> 3844 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">9</a>, <a href="#rfc.iref.h.10"><b>9.4</b></a>, <a href="#rfc.xref.header.host.3">10.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3845 <li>TE <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.xref.header.te.4">9</a>, <a href="#rfc.iref.h.11"><b>9.5</b></a>, <a href="#rfc.xref.header.te.5">10.1</a></li> 3846 <li>Trailer <a href="#rfc.xref.header.trailer.1">6.2.1</a>, <a href="#rfc.xref.header.trailer.2">9</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li> 3847 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">6.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">9</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 3848 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">9</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3849 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">9</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 3840 3850 </ul> 3841 3851 </li> 3842 3852 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3843 3853 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3844 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc. iref.h.9"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>3854 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">9</a>, <a href="#rfc.iref.h.9"><b>9.4</b></a>, <a href="#rfc.xref.header.host.3">10.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3845 3855 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3846 3856 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3996 4006 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3997 4007 <li>target resource <a href="#rfc.iref.t.4"><b>4.3</b></a></li> 3998 <li>TE header field <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc. iref.t.5"><b>9.5</b></a>, <a href="#rfc.xref.header.te.4">10.1</a></li>4008 <li>TE header field <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.xref.header.te.4">9</a>, <a href="#rfc.iref.t.5"><b>9.5</b></a>, <a href="#rfc.xref.header.te.5">10.1</a></li> 3999 4009 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">7.1.1</a>, <a href="#Tou1998"><b>13.2</b></a></li> 4000 <li>Trailer header field <a href="#rfc.xref.header.trailer.1"> 3.5</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>4001 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2"> 3.5</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>4010 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">6.2.1</a>, <a href="#rfc.xref.header.trailer.2">9</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li> 4011 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">6.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">9</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 4002 4012 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.4</b></a></li> 4003 4013 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.4</b></a></li> … … 4006 4016 </li> 4007 4017 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 4008 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1"> 3.5</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>4018 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">9</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 4009 4019 <li>upstream <a href="#rfc.iref.u.2"><b>2.4</b></a></li> 4010 4020 <li>URI scheme … … 4014 4024 </ul> 4015 4025 </li> 4016 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3 .1</a>, <a href="#rfc.xref.USASCII.3">3.2.1</a>, <a href="#USASCII"><b>13.1</b></a></li>4026 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.1</a>, <a href="#USASCII"><b>13.1</b></a></li> 4017 4027 <li>user agent <a href="#rfc.iref.u.1"><b>2.1</b></a></li> 4018 4028 </ul> 4019 4029 </li> 4020 4030 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 4021 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2"> 3.5</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>4031 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">9</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 4022 4032 </ul> 4023 4033 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1427 r1431 478 478 </section> 479 479 480 <section title=" HTTP-related architecture" anchor="architecture">480 <section title="Architecture" anchor="architecture"> 481 481 <t> 482 482 HTTP was created for the World Wide Web architecture … … 1135 1135 indicating the end of the header section, and an optional message-body. 1136 1136 </t> 1137 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/> 1138 <x:ref>HTTP-message</x:ref> = <x:ref>start-line</x:ref> 1139 *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) 1140 <x:ref>CRLF</x:ref> 1141 [ <x:ref>message-body</x:ref> ] 1142 </artwork></figure> 1143 <t> 1144 The normal procedure for parsing an HTTP message is to read the 1145 start-line into a structure, read each header field into a hash 1146 table by field name until the empty line, and then use the parsed 1147 data to determine if a message-body is expected. If a message-body 1148 has been indicated, then it is read as a stream until an amount 1149 of octets equal to the message-body length is read or the connection 1150 is closed. 1151 </t> 1152 <t> 1153 Recipients &MUST; parse an HTTP message as a sequence of octets in an 1154 encoding that is a superset of US-ASCII <xref target="USASCII"/>. 1155 Parsing an HTTP message as a stream of Unicode characters, without regard 1156 for the specific encoding, creates security vulnerabilities due to the 1157 varying ways that string processing libraries handle invalid multibyte 1158 character sequences that contain the octet LF (%x0A). String-based 1159 parsers can only be safely used within protocol elements after the element 1160 has been extracted from the message, such as within a header field-value 1161 after message parsing has delineated the individual fields. 1162 </t> 1163 1164 <section anchor="start.line" title="Start Line"> 1137 1165 <t> 1138 1166 An HTTP message can either be a request from client to server or a … … 1147 1175 and clients are implemented to only expect a response. 1148 1176 </t> 1149 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/> 1150 <x:ref>HTTP-message</x:ref> = <x:ref>start-line</x:ref> 1151 *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) 1152 <x:ref>CRLF</x:ref> 1153 [ <x:ref>message-body</x:ref> ] 1177 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="start-line"/> 1154 1178 <x:ref>start-line</x:ref> = <x:ref>Request-Line</x:ref> / <x:ref>Status-Line</x:ref> 1155 1179 </artwork></figure> 1180 <t> 1181 </t> 1156 1182 <t> 1157 1183 Implementations &MUST-NOT; send whitespace between the start-line and … … 1163 1189 Likewise, the presence of such whitespace in a response might be 1164 1190 ignored by some clients or cause others to cease parsing. 1165 </t>1166 1167 <section title="Message Parsing and Robustness" anchor="message.robustness">1168 <t>1169 The normal procedure for parsing an HTTP message is to read the1170 start-line into a structure, read each header field into a hash1171 table by field name until the empty line, and then use the parsed1172 data to determine if a message-body is expected. If a message-body1173 has been indicated, then it is read as a stream until an amount1174 of octets equal to the message-body length is read or the connection1175 is closed.1176 </t>1177 <t>1178 Recipients &MUST; parse an HTTP message as a sequence of octets in an1179 encoding that is a superset of US-ASCII <xref target="USASCII"/>.1180 Parsing an HTTP message as a stream of Unicode characters, without regard1181 for the specific encoding, creates security vulnerabilities due to the1182 varying ways that string processing libraries handle invalid multibyte1183 character sequences that contain the octet LF (%x0A). String-based1184 parsers can only be safely used within protocol elements after the element1185 has been extracted from the message, such as within a header field-value1186 after message parsing has delineated the individual fields.1187 </t>1188 <t>1189 Older HTTP/1.0 client implementations might send an extra CRLF1190 after a POST request as a lame workaround for some early server1191 applications that failed to read message-body content that was1192 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;1193 preface or follow a request with an extra CRLF. If terminating1194 the request message-body with a line-ending is desired, then the1195 client &MUST; include the terminating CRLF octets as part of the1196 message-body length.1197 </t>1198 <t>1199 In the interest of robustness, servers &SHOULD; ignore at least one1200 empty line received where a Request-Line is expected. In other words, if1201 the server is reading the protocol stream at the beginning of a1202 message and receives a CRLF first, it &SHOULD; ignore the CRLF.1203 Likewise, although the line terminator for the start-line and header1204 fields is the sequence CRLF, we recommend that recipients recognize a1205 single LF as a line terminator and ignore any CR.1206 </t>1207 <t>1208 When a server listening only for HTTP request messages, or processing1209 what appears from the start-line to be an HTTP request message,1210 receives a sequence of octets that does not match the HTTP-message1211 grammar aside from the robustness exceptions listed above, the1212 server &MUST; respond with an HTTP/1.1 400 (Bad Request) response.1213 1191 </t> 1214 1192 </section> … … 1604 1582 </section> 1605 1583 1606 <section anchor="incomplete.messages" title=" Incomplete Messages">1584 <section anchor="incomplete.messages" title="Handling Incomplete Messages"> 1607 1585 <t> 1608 1586 Request messages that are prematurely terminated, possibly due to a … … 1647 1625 </section> 1648 1626 1649 <section title="General Header Fields" anchor="general.header.fields"> 1650 <x:anchor-alias value="general-header"/> 1651 <t> 1652 There are a few header fields which have general applicability for 1653 both request and response messages, but which do not apply to the 1654 payload being transferred. These header fields apply only to the 1655 message being transmitted. 1656 </t> 1657 <texttable align="left"> 1658 <ttcol>Header Field Name</ttcol> 1659 <ttcol>Defined in...</ttcol> 1660 1661 <c>Connection</c> <c><xref target="header.connection"/></c> 1662 <c>Date</c> <c><xref target="header.date"/></c> 1663 <c>Trailer</c> <c><xref target="header.trailer"/></c> 1664 <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c> 1665 <c>Upgrade</c> <c><xref target="header.upgrade"/></c> 1666 <c>Via</c> <c><xref target="header.via"/></c> 1667 </texttable> 1627 <section title="Message Parsing Robustness" anchor="message.robustness"> 1628 <t> 1629 Older HTTP/1.0 client implementations might send an extra CRLF 1630 after a POST request as a lame workaround for some early server 1631 applications that failed to read message-body content that was 1632 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT; 1633 preface or follow a request with an extra CRLF. If terminating 1634 the request message-body with a line-ending is desired, then the 1635 client &MUST; include the terminating CRLF octets as part of the 1636 message-body length. 1637 </t> 1638 <t> 1639 In the interest of robustness, servers &SHOULD; ignore at least one 1640 empty line received where a Request-Line is expected. In other words, if 1641 the server is reading the protocol stream at the beginning of a 1642 message and receives a CRLF first, it &SHOULD; ignore the CRLF. 1643 Likewise, although the line terminator for the start-line and header 1644 fields is the sequence CRLF, we recommend that recipients recognize a 1645 single LF as a line terminator and ignore any CR. 1646 </t> 1647 <t> 1648 When a server listening only for HTTP request messages, or processing 1649 what appears from the start-line to be an HTTP request message, 1650 receives a sequence of octets that does not match the HTTP-message 1651 grammar aside from the robustness exceptions listed above, the 1652 server &MUST; respond with an HTTP/1.1 400 (Bad Request) response. 1653 </t> 1668 1654 </section> 1669 1655 </section> … … 3081 3067 <t> 3082 3068 This section defines the syntax and semantics of HTTP header fields 3083 related to message framing and transport protocols. 3084 </t> 3069 related to message origination, framing, and routing. 3070 </t> 3071 <texttable align="left"> 3072 <ttcol>Header Field Name</ttcol> 3073 <ttcol>Defined in...</ttcol> 3074 3075 <c>Connection</c> <c><xref target="header.connection"/></c> 3076 <c>Content-Length</c> <c><xref target="header.content-length"/></c> 3077 <c>Date</c> <c><xref target="header.date"/></c> 3078 <c>Host</c> <c><xref target="header.host"/></c> 3079 <c>TE</c> <c><xref target="header.te"/></c> 3080 <c>Trailer</c> <c><xref target="header.trailer"/></c> 3081 <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c> 3082 <c>Upgrade</c> <c><xref target="header.upgrade"/></c> 3083 <c>Via</c> <c><xref target="header.via"/></c> 3084 </texttable> 3085 3085 3086 3086 <section title="Connection" anchor="header.connection">
Note: See TracChangeset
for help on using the changeset viewer.