Changeset 1440 for draft-ietf-httpbis
- Timestamp:
- 09/09/11 11:04:01 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 11 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1435 r1440 359 359 } 360 360 @bottom-center { 361 content: "Expires March 5, 2012";361 content: "Expires March 12, 2012"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-09-0 2">410 <meta name="dct.issued" scheme="ISO8601" content="2011-09-09"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: March 5, 2012</td>442 <td class="left">Expires: March 12, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">September 2, 2011</td>495 <td class="right">September 9, 2011</td> 496 496 </tr> 497 497 </tbody> … … 526 526 in progress”. 527 527 </p> 528 <p>This Internet-Draft will expire on March 5, 2012.</p>528 <p>This Internet-Draft will expire on March 12, 2012.</p> 529 529 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 530 530 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 600 600 </li> 601 601 <li>5. <a href="#protocol.parameters">Protocol Parameters</a><ul> 602 <li>5.1 <a href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></li> 603 <li>5.2 <a href="#transfer.codings">Transfer Codings</a><ul> 604 <li>5.2.1 <a href="#chunked.encoding">Chunked Transfer Coding</a></li> 605 <li>5.2.2 <a href="#compression.codings">Compression Codings</a><ul> 606 <li>5.2.2.1 <a href="#compress.coding">Compress Coding</a></li> 607 <li>5.2.2.2 <a href="#deflate.coding">Deflate Coding</a></li> 608 <li>5.2.2.3 <a href="#gzip.coding">Gzip Coding</a></li> 602 <li>5.1 <a href="#transfer.codings">Transfer Codings</a><ul> 603 <li>5.1.1 <a href="#chunked.encoding">Chunked Transfer Coding</a></li> 604 <li>5.1.2 <a href="#compression.codings">Compression Codings</a><ul> 605 <li>5.1.2.1 <a href="#compress.coding">Compress Coding</a></li> 606 <li>5.1.2.2 <a href="#deflate.coding">Deflate Coding</a></li> 607 <li>5.1.2.3 <a href="#gzip.coding">Gzip Coding</a></li> 609 608 </ul> 610 609 </li> 611 <li>5. 2.3 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li>610 <li>5.1.3 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 612 611 </ul> 613 612 </li> 614 <li>5. 3 <a href="#product.tokens">Product Tokens</a></li>615 <li>5. 4 <a href="#quality.values">Quality Values</a></li>613 <li>5.2 <a href="#product.tokens">Product Tokens</a></li> 614 <li>5.3 <a href="#quality.values">Quality Values</a></li> 616 615 </ul> 617 616 </li> … … 652 651 <li>8.1 <a href="#header.connection">Connection</a></li> 653 652 <li>8.2 <a href="#header.content-length">Content-Length</a></li> 654 <li>8.3 <a href="#header.date">Date</a><ul> 655 <li>8.3.1 <a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li> 653 <li>8.3 <a href="#header.host">Host</a></li> 654 <li>8.4 <a href="#header.te">TE</a></li> 655 <li>8.5 <a href="#header.trailer">Trailer</a></li> 656 <li>8.6 <a href="#header.transfer-encoding">Transfer-Encoding</a></li> 657 <li>8.7 <a href="#header.upgrade">Upgrade</a><ul> 658 <li>8.7.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 656 659 </ul> 657 660 </li> 658 <li>8.4 <a href="#header.host">Host</a></li> 659 <li>8.5 <a href="#header.te">TE</a></li> 660 <li>8.6 <a href="#header.trailer">Trailer</a></li> 661 <li>8.7 <a href="#header.transfer-encoding">Transfer-Encoding</a></li> 662 <li>8.8 <a href="#header.upgrade">Upgrade</a><ul> 663 <li>8.8.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 664 </ul> 665 </li> 666 <li>8.9 <a href="#header.via">Via</a></li> 661 <li>8.8 <a href="#header.via">Via</a></li> 667 662 </ul> 668 663 </li> … … 909 904 <span id="exbody">Hello World! 910 905 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="message-orientation-and-buffering" href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2> 911 <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5. 2.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations906 <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations 912 907 only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some 913 908 amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide … … 973 968 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 974 969 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 975 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8. 9</a>) header fields for both connections.970 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.8</a>) header fields for both connections. 976 971 </p> 977 972 <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party … … 1248 1243 <a href="#header.fields" class="smpl">field-content</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> ) 1249 1244 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1250 the Date header field is defined in <a href=" #header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> as containing the origination timestamp for the message in which it appears.1245 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1251 1246 </p> 1252 1247 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1256 1251 them. 1257 1252 </p> 1258 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1253 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1259 1254 </p> 1260 1255 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1301 1296 <div id="rule.token.separators"> 1302 1297 <p id="rfc.section.3.2.3.p.1"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. 1303 These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 5. 2</a>).1298 These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). 1304 1299 </p> 1305 1300 </div> … … 1348 1343 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET 1349 1344 </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 1350 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8. 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.1345 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8.6</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. 1351 1346 </p> 1352 1347 <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header 1353 field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section 5. 2</a>.1348 field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>. 1354 1349 </p> 1355 1350 <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 8.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing … … 1377 1372 </li> 1378 1373 <li> 1379 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5. 2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding1374 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding 1380 1375 indicates the data is complete. 1381 1376 </p> … … 1481 1476 <p id="rfc.section.4.1.p.7">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1482 1477 </p> 1483 <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1478 <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1484 1479 </p> 1485 1480 <p id="rfc.section.4.1.p.9"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case, … … 1551 1546 </li> 1552 1547 <li>the octet sequence "://",</li> 1553 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8. 4</a>), and1548 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8.3</a>), and 1554 1549 </li> 1555 1550 <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> … … 1574 1569 </p> 1575 1570 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 1576 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2> 1577 <p id="rfc.section.5.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is 1578 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>: 1579 </p> 1580 <div id="rfc.figure.u.41"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1581 </pre><p id="rfc.section.5.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> 1582 <div id="rfc.figure.u.42"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1583 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1584 </pre><p id="rfc.section.5.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. 1585 </p> 1586 <p id="rfc.section.5.1.p.6">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 1587 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for 1588 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. 1589 </p> 1590 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></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> 1591 </pre><div id="preferred.date.format"> 1592 <p id="rfc.section.5.1.p.8"> Preferred format:</p> 1593 </div> 1594 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><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> <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> 1595 ; fixed length subset of the format defined in 1596 ; <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> 1597 1598 <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; "Mon", case-sensitive 1599 / %x54.75.65 ; "Tue", case-sensitive 1600 / %x57.65.64 ; "Wed", case-sensitive 1601 / %x54.68.75 ; "Thu", case-sensitive 1602 / %x46.72.69 ; "Fri", case-sensitive 1603 / %x53.61.74 ; "Sat", case-sensitive 1604 / %x53.75.6E ; "Sun", case-sensitive 1605 1606 <a href="#obsolete.date.formats" class="smpl">date1</a> = <a href="#preferred.date.format" class="smpl">day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 1607 ; e.g., 02 Jun 1982 1608 1609 <a href="#preferred.date.format" class="smpl">day</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1610 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; "Jan", case-sensitive 1611 / %x46.65.62 ; "Feb", case-sensitive 1612 / %x4D.61.72 ; "Mar", case-sensitive 1613 / %x41.70.72 ; "Apr", case-sensitive 1614 / %x4D.61.79 ; "May", case-sensitive 1615 / %x4A.75.6E ; "Jun", case-sensitive 1616 / %x4A.75.6C ; "Jul", case-sensitive 1617 / %x41.75.67 ; "Aug", case-sensitive 1618 / %x53.65.70 ; "Sep", case-sensitive 1619 / %x4F.63.74 ; "Oct", case-sensitive 1620 / %x4E.6F.76 ; "Nov", case-sensitive 1621 / %x44.65.63 ; "Dec", case-sensitive 1622 <a href="#preferred.date.format" class="smpl">year</a> = 4<a href="#core.rules" class="smpl">DIGIT</a> 1623 1624 <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; "GMT", case-sensitive 1625 1626 <a href="#preferred.date.format" class="smpl">time-of-day</a> = <a href="#preferred.date.format" class="smpl">hour</a> ":" <a href="#preferred.date.format" class="smpl">minute</a> ":" <a href="#preferred.date.format" class="smpl">second</a> 1627 ; 00:00:00 - 23:59:59 1628 1629 <a href="#preferred.date.format" class="smpl">hour</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1630 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1631 <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1632 </pre><p id="rfc.section.5.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>). 1633 </p> 1634 <div id="obsolete.date.formats"> 1635 <p id="rfc.section.5.1.p.11"> Obsolete formats:</p> 1636 </div> 1637 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.65"></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> 1638 </pre><div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.66"></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> 1639 <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> 1640 ; day-month-year (e.g., 02-Jun-82) 1641 1642 <a href="#obsolete.date.formats" class="smpl">day-name-l</a> = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1643 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1644 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1645 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1646 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1647 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1648 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1649 </pre><div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.67"></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> 1650 <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> )) 1651 ; month day (e.g., Jun 2) 1652 </pre><div class="note" id="rfc.section.5.1.p.15"> 1653 <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications, 1654 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 1655 </p> 1656 </div> 1657 <div class="note" id="rfc.section.5.1.p.16"> 1658 <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers 1659 are not required to use these formats for user presentation, request logging, etc. 1660 </p> 1661 </div> 1662 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2> 1663 <p id="rfc.section.5.2.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied 1571 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2> 1572 <p id="rfc.section.5.1.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied 1664 1573 to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the 1665 1574 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1666 1575 </p> 1667 <div id="rfc.figure.u.4 8"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.2.1</a>1668 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 5. 2.2.1</a>1669 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 5. 2.2.2</a>1670 / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section 5. 2.2.3</a>1576 <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="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> 1577 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 5.1.2.1</a> 1578 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> 1579 / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> 1671 1580 / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1672 1581 <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> ) 1673 1582 </pre><div id="rule.parameter"> 1674 <p id="rfc.section.5. 2.p.3"> Parameters are in the form of attribute/value pairs.</p>1583 <p id="rfc.section.5.1.p.3"> Parameters are in the form of attribute/value pairs.</p> 1675 1584 </div> 1676 <div id="rfc.figure.u.4 9"></div><pre class="inline"><span id="rfc.iref.g.70"></span><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> <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>1585 <div id="rfc.figure.u.42"></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> <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> 1677 1586 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1678 1587 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1679 </pre><p id="rfc.section.5. 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 8.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 8.7</a>).1680 </p> 1681 <p id="rfc.section.5. 2.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport1588 </pre><p id="rfc.section.5.1.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 8.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.6</a>). 1589 </p> 1590 <p id="rfc.section.5.1.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport 1682 1591 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic 1683 1592 of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section 3.3</a>), or the desire to encrypt data over a shared transport. 1684 1593 </p> 1685 <p id="rfc.section.5. 2.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.1594 <p id="rfc.section.5.1.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. 1686 1595 </p> 1687 1596 <div id="rfc.iref.c.6"></div> 1688 1597 <div id="rfc.iref.c.7"></div> 1689 <h3 id="rfc.section.5. 2.1"><a href="#rfc.section.5.2.1">5.2.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>1690 <p id="rfc.section.5. 2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size1598 <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3> 1599 <p id="rfc.section.5.1.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size 1691 1600 indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary 1692 1601 for the recipient to verify that it has received the full message. 1693 1602 </p> 1694 <div id="rfc.figure.u. 50"></div><pre class="inline"><span id="rfc.iref.g.75"></span><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> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1603 <div id="rfc.figure.u.43"></div><pre class="inline"><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><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1695 1604 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1696 1605 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1712 1621 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding 1713 1622 <a href="#chunked.encoding" class="smpl">qdtext-nf</a> = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1714 </pre><p id="rfc.section.5. 2.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended1623 </pre><p id="rfc.section.5.1.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended 1715 1624 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1716 1625 </p> 1717 <p id="rfc.section.5. 2.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field1718 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 8. 6</a>).1719 </p> 1720 <p id="rfc.section.5. 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:1626 <p id="rfc.section.5.1.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field 1627 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 8.5</a>). 1628 </p> 1629 <p id="rfc.section.5.1.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: 1721 1630 </p> 1722 1631 <ol> 1723 1632 <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as 1724 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 8. 5</a>; or,1633 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 8.4</a>; or, 1725 1634 </li> 1726 1635 <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable … … 1730 1639 </li> 1731 1640 </ol> 1732 <p id="rfc.section.5. 2.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and1641 <p id="rfc.section.5.1.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and 1733 1642 forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly 1734 1643 infinite buffer on the proxy. 1735 1644 </p> 1736 <p id="rfc.section.5. 2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>1737 <div id="rfc.figure.u. 51"></div><pre class="text"> length := 01645 <p id="rfc.section.5.1.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1646 <div id="rfc.figure.u.44"></div><pre class="text"> length := 0 1738 1647 read chunk-size, chunk-ext (if any) and CRLF 1739 1648 while (chunk-size > 0) { … … 1750 1659 Content-Length := length 1751 1660 Remove "chunked" from Transfer-Encoding 1752 </pre><p id="rfc.section.5. 2.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.1753 </p> 1754 <p id="rfc.section.5. 2.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting1661 </pre><p id="rfc.section.5.1.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1662 </p> 1663 <p id="rfc.section.5.1.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting 1755 1664 messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding 1756 1665 applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. 1757 1666 </p> 1758 <h3 id="rfc.section.5. 2.2"><a href="#rfc.section.5.2.2">5.2.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>1759 <p id="rfc.section.5. 2.2.p.1">The codings defined below can be used to compress the payload of a message.</p>1760 <div class="note" id="rfc.section.5. 2.2.p.2">1667 <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h3> 1668 <p id="rfc.section.5.1.2.p.1">The codings defined below can be used to compress the payload of a message.</p> 1669 <div class="note" id="rfc.section.5.1.2.p.2"> 1761 1670 <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. 1762 1671 Their use here is representative of historical practice, not good design. 1763 1672 </p> 1764 1673 </div> 1765 <div class="note" id="rfc.section.5. 2.2.p.3">1674 <div class="note" id="rfc.section.5.1.2.p.3"> 1766 1675 <p> <b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. 1767 1676 </p> … … 1769 1678 <div id="rfc.iref.c.8"></div> 1770 1679 <div id="rfc.iref.c.9"></div> 1771 <h4 id="rfc.section.5. 2.2.1"><a href="#rfc.section.5.2.2.1">5.2.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h4>1772 <p id="rfc.section.5. 2.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch1680 <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h4> 1681 <p id="rfc.section.5.1.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch 1773 1682 coding (LZW). 1774 1683 </p> 1775 1684 <div id="rfc.iref.d.2"></div> 1776 1685 <div id="rfc.iref.c.10"></div> 1777 <h4 id="rfc.section.5. 2.2.2"><a href="#rfc.section.5.2.2.2">5.2.2.2</a> <a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>1778 <p id="rfc.section.5. 2.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).1779 </p> 1780 <div class="note" id="rfc.section.5. 2.2.2.p.2">1686 <h4 id="rfc.section.5.1.2.2"><a href="#rfc.section.5.1.2.2">5.1.2.2</a> <a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4> 1687 <p id="rfc.section.5.1.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>). 1688 </p> 1689 <div class="note" id="rfc.section.5.1.2.2.p.2"> 1781 1690 <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper. 1782 1691 </p> 1783 1692 </div> 1784 <div id="rfc.iref.g. 86"></div>1693 <div id="rfc.iref.g.70"></div> 1785 1694 <div id="rfc.iref.c.11"></div> 1786 <h4 id="rfc.section.5. 2.2.3"><a href="#rfc.section.5.2.2.3">5.2.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>1787 <p id="rfc.section.5. 2.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.1788 </p> 1789 <h3 id="rfc.section.5. 2.3"><a href="#rfc.section.5.2.3">5.2.3</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3>1790 <p id="rfc.section.5. 2.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>1791 <p id="rfc.section.5. 2.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:1695 <h4 id="rfc.section.5.1.2.3"><a href="#rfc.section.5.1.2.3">5.1.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4> 1696 <p id="rfc.section.5.1.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. 1697 </p> 1698 <h3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3> 1699 <p id="rfc.section.5.1.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p> 1700 <p id="rfc.section.5.1.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 1792 1701 </p> 1793 1702 <ul> … … 1796 1705 <li>Pointer to specification text</li> 1797 1706 </ul> 1798 <p id="rfc.section.5. 2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 5.2.2</a>).1799 </p> 1800 <p id="rfc.section.5. 2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.1801 </p> 1802 <p id="rfc.section.5. 2.3.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.1803 </p> 1804 <h2 id="rfc.section.5. 3"><a href="#rfc.section.5.3">5.3</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>1805 <p id="rfc.section.5. 3.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields1707 <p id="rfc.section.5.1.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 5.1.2</a>). 1708 </p> 1709 <p id="rfc.section.5.1.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. 1710 </p> 1711 <p id="rfc.section.5.1.3.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 1712 </p> 1713 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> 1714 <p id="rfc.section.5.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields 1806 1715 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. 1807 1716 By convention, the products are listed in order of their significance for identifying the application. 1808 1717 </p> 1809 <div id="rfc.figure.u. 52"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></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>]1718 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></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>] 1810 1719 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1811 </pre><p id="rfc.section.5. 3.p.3">Examples:</p>1812 <div id="rfc.figure.u. 53"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31720 </pre><p id="rfc.section.5.2.p.3">Examples:</p> 1721 <div id="rfc.figure.u.46"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1813 1722 Server: Apache/0.8.4 1814 </pre><p id="rfc.section.5. 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).1815 </p> 1816 <h2 id="rfc.section.5. 4"><a href="#rfc.section.5.4">5.4</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2>1817 <p id="rfc.section.5. 4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 8.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1723 </pre><p id="rfc.section.5.2.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). 1724 </p> 1725 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2> 1726 <p id="rfc.section.5.3.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 8.4</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1818 1727 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1819 1728 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. 1820 1729 </p> 1821 <div id="rfc.figure.u. 54"></div><pre class="inline"><span id="rfc.iref.g.89"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1730 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.73"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1822 1731 / ( "1" [ "." 0*3("0") ] ) 1823 </pre><div class="note" id="rfc.section.5. 4.p.3">1732 </pre><div class="note" id="rfc.section.5.3.p.3"> 1824 1733 <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality. 1825 1734 </p> … … 1879 1788 <p id="rfc.section.6.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1880 1789 </p> 1881 <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1790 <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1882 1791 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 1883 1792 </p> … … 1949 1858 </p> 1950 1859 </div> 1951 <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5. 2</a>).1860 <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). 1952 1861 </p> 1953 1862 <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 1965 1874 </p> 1966 1875 <p id="rfc.section.6.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1967 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding1876 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1968 1877 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1969 1878 </p> … … 1989 1898 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> 1990 1899 <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 1991 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 5. 2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.1900 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection. 1992 1901 </p> 1993 1902 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 1994 <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing1903 <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 1995 1904 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 1996 1905 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 1999 1908 <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 2000 1909 <ul> 2001 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2002 </li> 2003 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.1910 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1911 </li> 1912 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 2004 1913 </li> 2005 1914 </ul> … … 2045 1954 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2046 1955 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2047 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1956 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2048 1957 </li> 2049 1958 </ul> … … 2109 2018 </tr> 2110 2019 <tr> 2111 <td class="left">Date</td>2112 <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 8.3</a></td>2113 </tr>2114 <tr>2115 2020 <td class="left">Host</td> 2116 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8. 4</a></td>2021 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8.3</a></td> 2117 2022 </tr> 2118 2023 <tr> 2119 2024 <td class="left">TE</td> 2120 <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 8. 5</a></td>2025 <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 8.4</a></td> 2121 2026 </tr> 2122 2027 <tr> 2123 2028 <td class="left">Trailer</td> 2124 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8. 6</a></td>2029 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.5</a></td> 2125 2030 </tr> 2126 2031 <tr> 2127 2032 <td class="left">Transfer-Encoding</td> 2128 <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8. 7</a></td>2033 <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.6</a></td> 2129 2034 </tr> 2130 2035 <tr> 2131 2036 <td class="left">Upgrade</td> 2132 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8. 8</a></td>2037 <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.7</a></td> 2133 2038 </tr> 2134 2039 <tr> 2135 2040 <td class="left">Via</td> 2136 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8. 9</a></td>2041 <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8.8</a></td> 2137 2042 </tr> 2138 2043 </tbody> … … 2150 2055 </p> 2151 2056 <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p> 2152 <div id="rfc.figure.u. 55"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a>2057 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2153 2058 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 2154 2059 </pre><p id="rfc.section.8.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 … … 2173 2078 of the response. For example, 2174 2079 </p> 2175 <div id="rfc.figure.u. 56"></div><pre class="text"> Connection: close2080 <div id="rfc.figure.u.49"></div><pre class="text"> Connection: close 2176 2081 </pre><p id="rfc.section.8.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 6.1</a>) after the current request/response is complete. 2177 2082 </p> … … 2189 2094 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 2190 2095 </p> 2191 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.92"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>2096 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 2192 2097 </pre><p id="rfc.section.8.2.p.3">An example is</p> 2193 <div id="rfc.figure.u.5 8"></div><pre class="text"> Content-Length: 34952098 <div id="rfc.figure.u.51"></div><pre class="text"> Content-Length: 3495 2194 2099 </pre><p id="rfc.section.8.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 2195 2100 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. … … 2199 2104 an optional field used within the "message/external-body" content-type. 2200 2105 </p> 2201 <div id="rfc.iref.d.3"></div>2202 2106 <div id="rfc.iref.h.8"></div> 2203 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.date" href="#header.date">Date</a></h2>2204 <p id="rfc.section.8.3.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the2205 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 5.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.2206 </p>2207 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.93"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>2208 </pre><p id="rfc.section.8.3.p.3">An example is</p>2209 <div id="rfc.figure.u.60"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2210 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:2211 </p>2212 <ol>2213 <li>If the response status code is 100 (Continue) or 101 (Switching Protocols), the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.2214 </li>2215 <li>If the response status code conveys a server error, e.g., 500 (Internal Server Error) or 503 (Service Unavailable), and it2216 is inconvenient or impossible to generate a valid Date.2217 </li>2218 <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 8.3.1</a> <em class="bcp14">MUST</em> be followed.2219 </li>2220 </ol>2221 <p id="rfc.section.8.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.2222 </p>2223 <p id="rfc.section.8.3.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it2224 when it doesn't convey any useful information (as it is usually the case for requests that do not contain a payload).2225 </p>2226 <p id="rfc.section.8.3.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means2227 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload2228 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic2229 value.2230 </p>2231 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>2232 <p id="rfc.section.8.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or2233 user with a reliable clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration"2234 of responses without storing separate Expires values for each resource).2235 </p>2236 2107 <div id="rfc.iref.h.9"></div> 2237 <div id="rfc.iref.h.10"></div> 2238 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.host" href="#header.host">Host</a></h2> 2239 <p id="rfc.section.8.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin 2108 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.host" href="#header.host">Host</a></h2> 2109 <p id="rfc.section.8.3.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin 2240 2110 server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the 2241 2111 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. 2242 2112 </p> 2243 <div id="rfc.figure.u. 61"></div><pre class="inline"><span id="rfc.iref.g.94"></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>2244 </pre><p id="rfc.section.8. 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, then2113 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.77"></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> 2114 </pre><p id="rfc.section.8.3.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 2245 2115 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. 2246 2116 </p> 2247 <p id="rfc.section.8. 4.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p>2248 <div id="rfc.figure.u. 62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12117 <p id="rfc.section.8.3.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 2118 <div id="rfc.figure.u.53"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2249 2119 Host: www.example.org 2250 </pre><p id="rfc.section.8. 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 information2120 </pre><p id="rfc.section.8.3.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 2251 2121 to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. 2252 2122 </p> 2253 <p id="rfc.section.8. 4.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When2123 <p id="rfc.section.8.3.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When 2254 2124 a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host. 2255 2125 </p> 2256 <p id="rfc.section.8. 4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to2126 <p id="rfc.section.8.3.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to 2257 2127 poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it 2258 2128 relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared 2259 2129 cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. 2260 2130 </p> 2261 <p id="rfc.section.8. 4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request2131 <p id="rfc.section.8.3.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request 2262 2132 message that contains more than one Host header field or a Host header field with an invalid field-value. 2263 2133 </p> 2264 <p id="rfc.section.8. 4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.2134 <p id="rfc.section.8.3.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host. 2265 2135 </p> 2266 2136 <div id="rfc.iref.t.5"></div> 2267 <div id="rfc.iref.h.1 1"></div>2268 <h2 id="rfc.section.8. 5"><a href="#rfc.section.8.5">8.5</a> <a id="header.te" href="#header.te">TE</a></h2>2269 <p id="rfc.section.8. 5.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not2137 <div id="rfc.iref.h.10"></div> 2138 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.te" href="#header.te">TE</a></h2> 2139 <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not 2270 2140 it is willing to accept trailer fields in a chunked transfer-coding. 2271 2141 </p> 2272 <p id="rfc.section.8. 5.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional2273 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 5. 2</a>).2274 </p> 2275 <div id="rfc.figure.u. 63"></div><pre class="inline"><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>2142 <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional 2143 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>). 2144 </p> 2145 <div id="rfc.figure.u.54"></div><pre class="inline"><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> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 2276 2146 <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> ] ) 2277 2147 <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> ) 2278 2148 <a href="#header.te" class="smpl">te-ext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ] 2279 </pre><p id="rfc.section.8. 5.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,2280 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5. 2.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.2281 </p> 2282 <p id="rfc.section.8. 5.p.5">Examples of its use are:</p>2283 <div id="rfc.figure.u. 64"></div><pre class="text"> TE: deflate2149 </pre><p id="rfc.section.8.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, 2150 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding. 2151 </p> 2152 <p id="rfc.section.8.4.p.5">Examples of its use are:</p> 2153 <div id="rfc.figure.u.55"></div><pre class="text"> TE: deflate 2284 2154 TE: 2285 2155 TE: trailers, deflate;q=0.5 2286 </pre><p id="rfc.section.8. 5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a>) whenever TE is present in an HTTP/1.1 message.2287 </p> 2288 <p id="rfc.section.8. 5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>2156 </pre><p id="rfc.section.8.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a>) whenever TE is present in an HTTP/1.1 message. 2157 </p> 2158 <p id="rfc.section.8.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> 2289 2159 <ol> 2290 2160 <li> … … 2300 2170 <li> 2301 2171 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 2302 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 5. 4</a>, a qvalue of 0 means "not acceptable".)2172 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 5.3</a>, a qvalue of 0 means "not acceptable".) 2303 2173 </p> 2304 2174 </li> … … 2309 2179 </li> 2310 2180 </ol> 2311 <p id="rfc.section.8. 5.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding2181 <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding 2312 2182 is always acceptable. 2313 2183 </p> 2314 2184 <div id="rfc.iref.t.6"></div> 2315 <div id="rfc.iref.h.1 2"></div>2316 <h2 id="rfc.section.8. 6"><a href="#rfc.section.8.6">8.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2>2317 <p id="rfc.section.8. 6.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with2185 <div id="rfc.iref.h.11"></div> 2186 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 2187 <p id="rfc.section.8.5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with 2318 2188 chunked transfer-coding. 2319 2189 </p> 2320 <div id="rfc.figure.u. 65"></div><pre class="inline"><span id="rfc.iref.g.99"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>2321 </pre><p id="rfc.section.8. 6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient2190 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.82"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 2191 </pre><p id="rfc.section.8.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 2322 2192 to know which header fields to expect in the trailer. 2323 2193 </p> 2324 <p id="rfc.section.8. 6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.2.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.2325 </p> 2326 <p id="rfc.section.8. 6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:2194 <p id="rfc.section.8.5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding. 2195 </p> 2196 <p id="rfc.section.8.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields: 2327 2197 </p> 2328 2198 <ul> … … 2332 2202 </ul> 2333 2203 <div id="rfc.iref.t.7"></div> 2334 <div id="rfc.iref.h.1 3"></div>2335 <h2 id="rfc.section.8. 7"><a href="#rfc.section.8.7">8.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>2336 <p id="rfc.section.8. 7.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs2204 <div id="rfc.iref.h.12"></div> 2205 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2206 <p id="rfc.section.8.6.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs 2337 2207 from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings 2338 2208 are not. 2339 2209 </p> 2340 <div id="rfc.figure.u. 66"></div><pre class="inline"><span id="rfc.iref.g.100"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>2341 </pre><p id="rfc.section.8. 7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.2</a>. An example is:2342 </p> 2343 <div id="rfc.figure.u. 67"></div><pre class="text"> Transfer-Encoding: chunked2344 </pre><p id="rfc.section.8. 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.2345 </p> 2346 <p id="rfc.section.8. 7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>2210 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.83"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 2211 </pre><p id="rfc.section.8.6.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 5.1</a>. An example is: 2212 </p> 2213 <div id="rfc.figure.u.58"></div><pre class="text"> Transfer-Encoding: chunked 2214 </pre><p id="rfc.section.8.6.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. 2215 </p> 2216 <p id="rfc.section.8.6.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p> 2347 2217 <div id="rfc.iref.u.5"></div> 2348 <div id="rfc.iref.h.1 4"></div>2349 <h2 id="rfc.section.8. 8"><a href="#rfc.section.8.8">8.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>2350 <p id="rfc.section.8. 8.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the2218 <div id="rfc.iref.h.13"></div> 2219 <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2220 <p id="rfc.section.8.7.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the 2351 2221 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2352 2222 </p> 2353 <div id="rfc.figure.u. 68"></div><pre class="inline"><span id="rfc.iref.g.101"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>2354 </pre><p id="rfc.section.8. 8.p.3">For example,</p>2355 <div id="rfc.figure.u.6 9"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112356 </pre><p id="rfc.section.8. 8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible2223 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.84"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a> 2224 </pre><p id="rfc.section.8.7.p.3">For example,</p> 2225 <div id="rfc.figure.u.60"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2226 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 2357 2227 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2358 2228 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2361 2231 the server, possibly according to the nature of the request method or target resource). 2362 2232 </p> 2363 <p id="rfc.section.8. 8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.2233 <p id="rfc.section.8.7.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. 2364 2234 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2365 2235 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 2366 2236 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2367 2237 </p> 2368 <p id="rfc.section.8. 8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2369 </p> 2370 <p id="rfc.section.8. 8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it2371 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2372 </p> 2373 <p id="rfc.section.8. 8.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched2238 <p id="rfc.section.8.7.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2239 </p> 2240 <p id="rfc.section.8.7.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2241 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2242 </p> 2243 <p id="rfc.section.8.7.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched 2374 2244 to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. 2375 2245 </p> 2376 <p id="rfc.section.8. 8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2246 <p id="rfc.section.8.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2377 2247 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2378 2248 below. 2379 2249 </p> 2380 <h3 id="rfc.section.8. 8.1"><a href="#rfc.section.8.8.1">8.8.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>2381 <p id="rfc.section.8. 8.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header2250 <h3 id="rfc.section.8.7.1"><a href="#rfc.section.8.7.1">8.7.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3> 2251 <p id="rfc.section.8.7.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header 2382 2252 field. Each registered token is associated with contact information and an optional set of specifications that details how 2383 2253 the connection will be processed after it has been upgraded. 2384 2254 </p> 2385 <p id="rfc.section.8. 8.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:2255 <p id="rfc.section.8.7.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules: 2386 2256 </p> 2387 2257 <ol> … … 2401 2271 </ol> 2402 2272 <div id="rfc.iref.v.1"></div> 2403 <div id="rfc.iref.h.1 5"></div>2404 <h2 id="rfc.section.8. 9"><a href="#rfc.section.8.9">8.9</a> <a id="header.via" href="#header.via">Via</a></h2>2405 <p id="rfc.section.8. 9.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server2273 <div id="rfc.iref.h.14"></div> 2274 <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="header.via" href="#header.via">Via</a></h2> 2275 <p id="rfc.section.8.8.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server 2406 2276 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email 2407 systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322. 5"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities2277 systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 2408 2278 of all senders along the request/response chain. 2409 2279 </p> 2410 <div id="rfc.figure.u. 70"></div><pre class="inline"><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></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>2280 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></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> 2411 2281 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2412 2282 <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> … … 2415 2285 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 2416 2286 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 2417 </pre><p id="rfc.section.8. 9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of2287 </pre><p id="rfc.section.8.8.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of 2418 2288 the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded 2419 2289 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 2420 2290 </p> 2421 <p id="rfc.section.8. 9.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port2291 <p id="rfc.section.8.8.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port 2422 2292 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 2423 2293 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 2424 2294 </p> 2425 <p id="rfc.section.8. 9.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.2426 </p> 2427 <p id="rfc.section.8. 9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header2295 <p id="rfc.section.8.8.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 2296 </p> 2297 <p id="rfc.section.8.8.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header 2428 2298 fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 2429 2299 </p> 2430 <p id="rfc.section.8. 9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses2300 <p id="rfc.section.8.8.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses 2431 2301 HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin 2432 2302 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2433 2303 </p> 2434 <div id="rfc.figure.u. 71"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2435 </pre><p id="rfc.section.8. 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,2304 <div id="rfc.figure.u.62"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2305 </pre><p id="rfc.section.8.8.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, 2436 2306 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 2437 2307 </p> 2438 <p id="rfc.section.8. 9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.2308 <p id="rfc.section.8.8.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. 2439 2309 For example, 2440 2310 </p> 2441 <div id="rfc.figure.u. 72"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2442 </pre><p id="rfc.section.8. 9.p.12">could be collapsed to</p>2443 <div id="rfc.figure.u. 73"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2444 </pre><p id="rfc.section.8. 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 replaced2311 <div id="rfc.figure.u.63"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2312 </pre><p id="rfc.section.8.8.p.12">could be collapsed to</p> 2313 <div id="rfc.figure.u.64"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2314 </pre><p id="rfc.section.8.8.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 2445 2315 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 2446 2316 </p> … … 2476 2346 </tr> 2477 2347 <tr> 2478 <td class="left">Date</td>2479 <td class="left">http</td>2480 <td class="left">standard</td>2481 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section 8.3</a>2482 </td>2483 </tr>2484 <tr>2485 2348 <td class="left">Host</td> 2486 2349 <td class="left">http</td> 2487 2350 <td class="left">standard</td> 2488 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 8. 4</a>2351 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 8.3</a> 2489 2352 </td> 2490 2353 </tr> … … 2493 2356 <td class="left">http</td> 2494 2357 <td class="left">standard</td> 2495 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section 8. 5</a>2358 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section 8.4</a> 2496 2359 </td> 2497 2360 </tr> … … 2500 2363 <td class="left">http</td> 2501 2364 <td class="left">standard</td> 2502 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 8. 6</a>2365 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 8.5</a> 2503 2366 </td> 2504 2367 </tr> … … 2507 2370 <td class="left">http</td> 2508 2371 <td class="left">standard</td> 2509 <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8. 7</a>2372 <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8.6</a> 2510 2373 </td> 2511 2374 </tr> … … 2514 2377 <td class="left">http</td> 2515 2378 <td class="left">standard</td> 2516 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 8. 8</a>2379 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 8.7</a> 2517 2380 </td> 2518 2381 </tr> … … 2521 2384 <td class="left">http</td> 2522 2385 <td class="left">standard</td> 2523 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 8. 9</a>2386 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 8.8</a> 2524 2387 </td> 2525 2388 </tr> … … 2670 2533 </dl> 2671 2534 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2> 2672 <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 5. 2.3</a> of this document.2535 <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 5.1.3</a> of this document. 2673 2536 </p> 2674 2537 <p id="rfc.section.9.4.p.2">The HTTP Transfer Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> shall be updated with the registrations below: … … 2688 2551 <td class="left">chunked</td> 2689 2552 <td class="left">Transfer in a series of chunks</td> 2690 <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5. 2.1</a>2553 <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> 2691 2554 </td> 2692 2555 </tr> … … 2694 2557 <td class="left">compress</td> 2695 2558 <td class="left">UNIX "compress" program method</td> 2696 <td class="left"> <a href="#compress.coding" title="Compress Coding">Section 5. 2.2.1</a>2559 <td class="left"> <a href="#compress.coding" title="Compress Coding">Section 5.1.2.1</a> 2697 2560 </td> 2698 2561 </tr> … … 2701 2564 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.2"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.2"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 2702 2565 </td> 2703 <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section 5. 2.2.2</a>2566 <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> 2704 2567 </td> 2705 2568 </tr> … … 2707 2570 <td class="left">gzip</td> 2708 2571 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.2"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 2709 <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section 5. 2.2.3</a>2572 <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> 2710 2573 </td> 2711 2574 </tr> … … 2714 2577 </div> 2715 2578 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2> 2716 <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8. 8.1</a> of this document.2579 <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.7.1</a> of this document. 2717 2580 </p> 2718 2581 <p id="rfc.section.9.5.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>> shall be updated with the registration below: … … 2797 2660 that most implementations will choose substantially higher limits. 2798 2661 </p> 2799 <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2662 <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2800 2663 </p> 2801 2664 <p id="rfc.section.10.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. … … 2831 2694 <tr> 2832 2695 <td class="reference"><b id="Part6">[Part6]</b></td> 2833 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" >Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011.2696 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011. 2834 2697 </td> 2835 2698 </tr> … … 2874 2737 <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References 2875 2738 </h2> 2876 <table> 2739 <table> 2877 2740 <tr> 2878 2741 <td class="reference"><b id="BCP97">[BCP97]</b></td> … … 2894 2757 <td class="reference"><b id="Pad1995">[Pad1995]</b></td> 2895 2758 <td class="top">Padmanabhan, V. and J. Mogul, “<a href="http://portal.acm.org/citation.cfm?id=219094">Improving HTTP Latency</a>”, Computer Networks and ISDN Systems v. 28, pp. 25-35, December 1995, <<a href="http://portal.acm.org/citation.cfm?id=219094">http://portal.acm.org/citation.cfm?id=219094</a>>. 2896 </td>2897 </tr>2898 <tr>2899 <td class="reference"><b id="RFC1123">[RFC1123]</b></td>2900 <td class="top"><a href="mailto:Braden@ISI.EDU" title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD 3, RFC 1123, October 1989.2901 2759 </td> 2902 2760 </tr> … … 3051 2909 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3052 2910 <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> 3053 <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 8. 4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.2911 <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 8.3</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 3.1.1.2</a>) are among the most important changes defined by HTTP/1.1. 3054 2912 </p> 3055 2913 <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 … … 3094 2952 <p id="rfc.section.A.2.p.6">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>) 3095 2953 </p> 3096 <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5. 2</a>)2954 <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5.1</a>) 3097 2955 </p> 3098 2956 <p id="rfc.section.A.2.p.8">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk … … 3100 2958 </p> 3101 2959 <p id="rfc.section.A.2.p.9">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore 3102 disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5. 2.1</a>)2960 disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a>) 3103 2961 </p> 3104 2962 <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 6.1.4</a>) … … 3108 2966 <p id="rfc.section.A.2.p.12">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section 8.1</a>) 3109 2967 </p> 3110 <p id="rfc.section.A.2.p.13">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 8. 8</a>)2968 <p id="rfc.section.A.2.p.13">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 8.7</a>) 3111 2969 </p> 3112 2970 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3113 <div id="rfc.figure.u. 74"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS2971 <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3114 2972 3115 2973 <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF … … 3118 2976 <a href="#header.content-length" class="smpl">Content-Length</a> = 1*DIGIT 3119 2977 3120 <a href="#header.date" class="smpl">Date</a> = HTTP-date3121 3122 <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; GMT3123 3124 2978 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; HTTP 3125 2979 <a href="#http.version" class="smpl">HTTP-Version</a> = HTTP-Prot-Name "/" DIGIT "." DIGIT 3126 <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date3127 2980 <a href="#http.message" class="smpl">HTTP-message</a> = start-line *( header-field CRLF ) CRLF [ message-body 3128 2981 ] … … 3153 3006 3154 3007 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in [RFC3986], Section 4.3> 3155 <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = day-name SP date3 SP time-of-day SP year3156 3008 <a href="#rule.parameter" class="smpl">attribute</a> = token 3157 3009 <a href="#uri" class="smpl">authority</a> = <authority, defined in [RFC3986], Section 3.2> … … 3170 3022 / obs-text 3171 3023 3172 <a href="#obsolete.date.formats" class="smpl">date1</a> = day SP month SP year3173 <a href="#obsolete.date.formats" class="smpl">date2</a> = day "-" month "-" 2DIGIT3174 <a href="#obsolete.date.formats" class="smpl">date3</a> = month SP ( 2DIGIT / ( SP DIGIT ) )3175 <a href="#preferred.date.format" class="smpl">day</a> = 2DIGIT3176 <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; Mon3177 / %x54.75.65 ; Tue3178 / %x57.65.64 ; Wed3179 / %x54.68.75 ; Thu3180 / %x46.72.69 ; Fri3181 / %x53.61.74 ; Sat3182 / %x53.75.6E ; Sun3183 <a href="#obsolete.date.formats" class="smpl">day-name-l</a> = %x4D.6F.6E.64.61.79 ; Monday3184 / %x54.75.65.73.64.61.79 ; Tuesday3185 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday3186 / %x54.68.75.72.73.64.61.79 ; Thursday3187 / %x46.72.69.64.61.79 ; Friday3188 / %x53.61.74.75.72.64.61.79 ; Saturday3189 / %x53.75.6E.64.61.79 ; Sunday3190 3191 3024 <a href="#header.fields" class="smpl">field-content</a> = *( HTAB / SP / VCHAR / obs-text ) 3192 3025 <a href="#header.fields" class="smpl">field-name</a> = token … … 3194 3027 3195 3028 <a href="#header.fields" class="smpl">header-field</a> = field-name ":" OWS field-value BWS 3196 <a href="#preferred.date.format" class="smpl">hour</a> = 2DIGIT3197 3029 <a href="#http.uri" class="smpl">http-URI</a> = "http://" authority path-abempty [ "?" query ] 3198 3030 <a href="#https.uri" class="smpl">https-URI</a> = "https://" authority path-abempty [ "?" query ] … … 3201 3033 3202 3034 <a href="#message.body" class="smpl">message-body</a> = *OCTET 3203 <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT3204 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan3205 / %x46.65.62 ; Feb3206 / %x4D.61.72 ; Mar3207 / %x41.70.72 ; Apr3208 / %x4D.61.79 ; May3209 / %x4A.75.6E ; Jun3210 / %x4A.75.6C ; Jul3211 / %x41.75.67 ; Aug3212 / %x53.65.70 ; Sep3213 / %x4F.63.74 ; Oct3214 / %x4E.6F.76 ; Nov3215 / %x44.65.63 ; Dec3216 3035 3217 <a href="#obsolete.date.formats" class="smpl">obs-date</a> = rfc850-date / asctime-date3218 3036 <a href="#rule.whitespace" class="smpl">obs-fold</a> = CRLF ( SP / HTAB ) 3219 3037 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF … … 3247 3065 <a href="#request-target" class="smpl">request-target</a> = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3248 3066 / authority 3249 <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT3250 <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT3251 3067 3252 <a href="#preferred.date.format" class="smpl">second</a> = 2DIGIT3253 3068 <a href="#rule.token.separators" class="smpl">special</a> = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3254 3069 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" … … 3260 3075 <a href="#header.te" class="smpl">te-ext</a> = OWS ";" OWS token [ "=" word ] 3261 3076 <a href="#header.te" class="smpl">te-params</a> = OWS ";" OWS "q=" qvalue *te-ext 3262 <a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second3263 3077 <a href="#rule.token.separators" class="smpl">token</a> = 1*tchar 3264 3078 <a href="#chunked.encoding" class="smpl">trailer-part</a> = *( header-field CRLF ) … … 3273 3087 3274 3088 <a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string 3275 3276 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3277 </pre> <div id="rfc.figure.u.75"></div> 3089 </pre> <div id="rfc.figure.u.66"></div> 3278 3090 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3279 3091 ; Connection defined but not used 3280 3092 ; Content-Length defined but not used 3281 ; Date defined but not used3282 3093 ; HTTP-message defined but not used 3283 3094 ; Host defined but not used … … 3666 3477 <li>cacheable <a href="#rfc.iref.c.5"><b>2.5</b></a></li> 3667 3478 <li>captive portal <a href="#rfc.iref.c.3"><b>2.4</b></a></li> 3668 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">5. 2.1</a></li>3479 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">5.1.1</a></li> 3669 3480 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3670 3481 <li>Coding Format 3671 3482 <ul> 3672 <li>chunked <a href="#rfc.iref.c.7">5. 2.1</a></li>3673 <li>compress <a href="#rfc.iref.c.9">5. 2.2.1</a></li>3674 <li>deflate <a href="#rfc.iref.c.10">5. 2.2.2</a></li>3675 <li>gzip <a href="#rfc.iref.c.11">5. 2.2.3</a></li>3483 <li>chunked <a href="#rfc.iref.c.7">5.1.1</a></li> 3484 <li>compress <a href="#rfc.iref.c.9">5.1.2.1</a></li> 3485 <li>deflate <a href="#rfc.iref.c.10">5.1.2.2</a></li> 3486 <li>gzip <a href="#rfc.iref.c.11">5.1.2.3</a></li> 3676 3487 </ul> 3677 3488 </li> 3678 <li>compress (Coding Format) <a href="#rfc.iref.c.8">5. 2.2.1</a></li>3489 <li>compress (Coding Format) <a href="#rfc.iref.c.8">5.1.2.1</a></li> 3679 3490 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3680 <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">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8. 5</a>, <a href="#rfc.xref.header.connection.9">8.8</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>3491 <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">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li> 3681 3492 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3682 3493 </ul> 3683 3494 </li> 3684 3495 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3685 <li>Date header field <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">8</a>, <a href="#rfc.iref.d.3"><b>8.3</b></a>, <a href="#rfc.xref.header.date.3">9.1</a></li> 3686 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">5.2.2.2</a></li> 3496 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">5.1.2.2</a></li> 3687 3497 <li>downstream <a href="#rfc.iref.d.1"><b>2.4</b></a></li> 3688 3498 </ul> … … 3698 3508 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3699 3509 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3700 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.67"><b>5.1</b></a></li> 3701 <li><tt>attribute</tt> <a href="#rfc.iref.g.71"><b>5.2</b></a></li> 3510 <li><tt>attribute</tt> <a href="#rfc.iref.g.55"><b>5.1</b></a></li> 3702 3511 <li><tt>authority</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3703 3512 <li><tt>BWS</tt> <a href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 3704 <li><tt>chunk</tt> <a href="#rfc.iref.g. 76"><b>5.2.1</b></a></li>3705 <li><tt>chunk-data</tt> <a href="#rfc.iref.g. 82"><b>5.2.1</b></a></li>3706 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g. 79"><b>5.2.1</b></a></li>3707 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g. 80"><b>5.2.1</b></a></li>3708 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g. 81"><b>5.2.1</b></a></li>3709 <li><tt>chunk-size</tt> <a href="#rfc.iref.g. 77"><b>5.2.1</b></a></li>3710 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g. 75"><b>5.2.1</b></a></li>3513 <li><tt>chunk</tt> <a href="#rfc.iref.g.60"><b>5.1.1</b></a></li> 3514 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.66"><b>5.1.1</b></a></li> 3515 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.63"><b>5.1.1</b></a></li> 3516 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.64"><b>5.1.1</b></a></li> 3517 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.65"><b>5.1.1</b></a></li> 3518 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.61"><b>5.1.1</b></a></li> 3519 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g.59"><b>5.1.1</b></a></li> 3711 3520 <li><tt>comment</tt> <a href="#rfc.iref.g.48"><b>3.2.3</b></a></li> 3712 <li><tt>Connection</tt> <a href="#rfc.iref.g. 90"><b>8.1</b></a></li>3713 <li><tt>connection-token</tt> <a href="#rfc.iref.g. 91"><b>8.1</b></a></li>3714 <li><tt>Content-Length</tt> <a href="#rfc.iref.g. 92"><b>8.2</b></a></li>3521 <li><tt>Connection</tt> <a href="#rfc.iref.g.74"><b>8.1</b></a></li> 3522 <li><tt>connection-token</tt> <a href="#rfc.iref.g.75"><b>8.1</b></a></li> 3523 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.76"><b>8.2</b></a></li> 3715 3524 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3716 3525 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3717 3526 <li><tt>ctext</tt> <a href="#rfc.iref.g.49"><b>3.2.3</b></a></li> 3718 3527 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3719 <li><tt>Date</tt> <a href="#rfc.iref.g.93"><b>8.3</b></a></li> 3720 <li><tt>date1</tt> <a href="#rfc.iref.g.54"><b>5.1</b></a></li> 3721 <li><tt>date2</tt> <a href="#rfc.iref.g.73"><b>5.2</b></a></li> 3722 <li><tt>date3</tt> <a href="#rfc.iref.g.74"><b>5.2</b></a></li> 3723 <li><tt>day</tt> <a href="#rfc.iref.g.61"><b>5.1</b></a></li> 3724 <li><tt>day-name</tt> <a href="#rfc.iref.g.59"><b>5.1</b></a></li> 3725 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.60"><b>5.1</b></a></li> 3528 <li><tt>date2</tt> <a href="#rfc.iref.g.57"><b>5.1</b></a></li> 3529 <li><tt>date3</tt> <a href="#rfc.iref.g.58"><b>5.1</b></a></li> 3726 3530 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3727 3531 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> … … 3729 3533 <li><tt>field-name</tt> <a href="#rfc.iref.g.37"><b>3.2</b></a></li> 3730 3534 <li><tt>field-value</tt> <a href="#rfc.iref.g.38"><b>3.2</b></a></li> 3731 <li><tt>GMT</tt> <a href="#rfc.iref.g.64"><b>5.1</b></a></li>3732 3535 <li><tt>header-field</tt> <a href="#rfc.iref.g.36"><b>3.2</b></a></li> 3733 3536 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3734 <li><tt>Host</tt> <a href="#rfc.iref.g.94"><b>8.4</b></a></li> 3735 <li><tt>hour</tt> <a href="#rfc.iref.g.56"><b>5.1</b></a></li> 3537 <li><tt>Host</tt> <a href="#rfc.iref.g.77"><b>8.3</b></a></li> 3736 3538 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3737 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.52"><b>5.1</b></a></li>3738 3539 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.28"><b>3</b></a></li> 3739 3540 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g.18"><b>2.6</b></a></li> … … 3741 3542 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.17"><b>2.6</b></a></li> 3742 3543 <li><tt>https-URI</tt> <a href="#rfc.iref.g.27"><b>2.7.2</b></a></li> 3743 <li><tt>last-chunk</tt> <a href="#rfc.iref.g. 78"><b>5.2.1</b></a></li>3544 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.62"><b>5.1.1</b></a></li> 3744 3545 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3745 3546 <li><tt>message-body</tt> <a href="#rfc.iref.g.51"><b>3.3</b></a></li> 3746 3547 <li><tt>Method</tt> <a href="#rfc.iref.g.31"><b>3.1.1.1</b></a></li> 3747 <li><tt>minute</tt> <a href="#rfc.iref.g.57"><b>5.1</b></a></li>3748 <li><tt>month</tt> <a href="#rfc.iref.g.62"><b>5.1</b></a></li>3749 <li><tt>obs-date</tt> <a href="#rfc.iref.g.65"><b>5.1</b></a></li>3750 3548 <li><tt>obs-text</tt> <a href="#rfc.iref.g.46"><b>3.2.3</b></a></li> 3751 3549 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> … … 3753 3551 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3754 3552 <li><tt>port</tt> <a href="#rfc.iref.g.23"><b>2.7</b></a></li> 3755 <li><tt>product</tt> <a href="#rfc.iref.g. 87"><b>5.3</b></a></li>3756 <li><tt>product-version</tt> <a href="#rfc.iref.g. 88"><b>5.3</b></a></li>3757 <li><tt>protocol-name</tt> <a href="#rfc.iref.g. 104"><b>8.9</b></a></li>3758 <li><tt>protocol-version</tt> <a href="#rfc.iref.g. 105"><b>8.9</b></a></li>3759 <li><tt>pseudonym</tt> <a href="#rfc.iref.g. 107"><b>8.9</b></a></li>3553 <li><tt>product</tt> <a href="#rfc.iref.g.71"><b>5.2</b></a></li> 3554 <li><tt>product-version</tt> <a href="#rfc.iref.g.72"><b>5.2</b></a></li> 3555 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.87"><b>8.8</b></a></li> 3556 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>8.8</b></a></li> 3557 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.90"><b>8.8</b></a></li> 3760 3558 <li><tt>qdtext</tt> <a href="#rfc.iref.g.45"><b>3.2.3</b></a></li> 3761 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g. 85"><b>5.2.1</b></a></li>3559 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.69"><b>5.1.1</b></a></li> 3762 3560 <li><tt>query</tt> <a href="#rfc.iref.g.24"><b>2.7</b></a></li> 3763 3561 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.50"><b>3.2.3</b></a></li> 3764 3562 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.47"><b>3.2.3</b></a></li> 3765 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g. 84"><b>5.2.1</b></a></li>3563 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.68"><b>5.1.1</b></a></li> 3766 3564 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.44"><b>3.2.3</b></a></li> 3767 <li><tt>qvalue</tt> <a href="#rfc.iref.g. 89"><b>5.4</b></a></li>3565 <li><tt>qvalue</tt> <a href="#rfc.iref.g.73"><b>5.3</b></a></li> 3768 3566 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.35"><b>3.1.2.2</b></a></li> 3769 <li><tt>received-by</tt> <a href="#rfc.iref.g. 106"><b>8.9</b></a></li>3770 <li><tt>received-protocol</tt> <a href="#rfc.iref.g. 103"><b>8.9</b></a></li>3567 <li><tt>received-by</tt> <a href="#rfc.iref.g.89"><b>8.8</b></a></li> 3568 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.86"><b>8.8</b></a></li> 3771 3569 <li><tt>Request-Line</tt> <a href="#rfc.iref.g.30"><b>3.1.1</b></a></li> 3772 3570 <li><tt>request-target</tt> <a href="#rfc.iref.g.32"><b>3.1.1.2</b></a></li> 3773 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.53"><b>5.1</b></a></li>3774 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.66"><b>5.1</b></a></li>3775 3571 <li><tt>RWS</tt> <a href="#rfc.iref.g.14"><b>1.2.2</b></a></li> 3776 <li><tt>second</tt> <a href="#rfc.iref.g.58"><b>5.1</b></a></li>3777 3572 <li>SP <a href="#rfc.iref.g.11"><b>1.2</b></a></li> 3778 3573 <li><tt>special</tt> <a href="#rfc.iref.g.43"><b>3.2.3</b></a></li> … … 3780 3575 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.34"><b>3.1.2.1</b></a></li> 3781 3576 <li><tt>Status-Line</tt> <a href="#rfc.iref.g.33"><b>3.1.2</b></a></li> 3782 <li><tt>t-codings</tt> <a href="#rfc.iref.g. 96"><b>8.5</b></a></li>3577 <li><tt>t-codings</tt> <a href="#rfc.iref.g.79"><b>8.4</b></a></li> 3783 3578 <li><tt>tchar</tt> <a href="#rfc.iref.g.42"><b>3.2.3</b></a></li> 3784 <li><tt>TE</tt> <a href="#rfc.iref.g.95"><b>8.5</b></a></li> 3785 <li><tt>te-ext</tt> <a href="#rfc.iref.g.98"><b>8.5</b></a></li> 3786 <li><tt>te-params</tt> <a href="#rfc.iref.g.97"><b>8.5</b></a></li> 3787 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.55"><b>5.1</b></a></li> 3579 <li><tt>TE</tt> <a href="#rfc.iref.g.78"><b>8.4</b></a></li> 3580 <li><tt>te-ext</tt> <a href="#rfc.iref.g.81"><b>8.4</b></a></li> 3581 <li><tt>te-params</tt> <a href="#rfc.iref.g.80"><b>8.4</b></a></li> 3788 3582 <li><tt>token</tt> <a href="#rfc.iref.g.41"><b>3.2.3</b></a></li> 3789 <li><tt>Trailer</tt> <a href="#rfc.iref.g. 99"><b>8.6</b></a></li>3790 <li><tt>trailer-part</tt> <a href="#rfc.iref.g. 83"><b>5.2.1</b></a></li>3791 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g. 68"><b>5.2</b></a></li>3792 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g. 100"><b>8.7</b></a></li>3793 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g. 69"><b>5.2</b></a></li>3794 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g. 70"><b>5.2</b></a></li>3795 <li><tt>Upgrade</tt> <a href="#rfc.iref.g. 101"><b>8.8</b></a></li>3583 <li><tt>Trailer</tt> <a href="#rfc.iref.g.82"><b>8.5</b></a></li> 3584 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.67"><b>5.1.1</b></a></li> 3585 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.52"><b>5.1</b></a></li> 3586 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.83"><b>8.6</b></a></li> 3587 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.53"><b>5.1</b></a></li> 3588 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.54"><b>5.1</b></a></li> 3589 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.84"><b>8.7</b></a></li> 3796 3590 <li><tt>uri-host</tt> <a href="#rfc.iref.g.25"><b>2.7</b></a></li> 3797 3591 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3798 <li><tt>value</tt> <a href="#rfc.iref.g. 72"><b>5.2</b></a></li>3592 <li><tt>value</tt> <a href="#rfc.iref.g.56"><b>5.1</b></a></li> 3799 3593 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3800 <li><tt>Via</tt> <a href="#rfc.iref.g. 102"><b>8.9</b></a></li>3594 <li><tt>Via</tt> <a href="#rfc.iref.g.85"><b>8.8</b></a></li> 3801 3595 <li><tt>word</tt> <a href="#rfc.iref.g.40"><b>3.2.3</b></a></li> 3802 <li><tt>year</tt> <a href="#rfc.iref.g.63"><b>5.1</b></a></li>3803 3596 </ul> 3804 3597 </li> 3805 <li>gzip (Coding Format) <a href="#rfc.iref.g. 86">5.2.2.3</a></li>3598 <li>gzip (Coding Format) <a href="#rfc.iref.g.70">5.1.2.3</a></li> 3806 3599 </ul> 3807 3600 </li> … … 3810 3603 <li>Header Fields 3811 3604 <ul> 3812 <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">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8. 5</a>, <a href="#rfc.xref.header.connection.9">8.8</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>3605 <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">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li> 3813 3606 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3814 <li>Date <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">8</a>, <a href="#rfc.iref.h.8"><b>8.3</b></a>, <a href="#rfc.xref.header.date.3">9.1</a></li> 3815 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.10"><b>8.4</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3816 <li>TE <a href="#rfc.xref.header.te.1">5.2</a>, <a href="#rfc.xref.header.te.2">5.2.1</a>, <a href="#rfc.xref.header.te.3">5.4</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.h.11"><b>8.5</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3817 <li>Trailer <a href="#rfc.xref.header.trailer.1">5.2.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> 3818 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3819 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3820 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.15"><b>8.9</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3607 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3608 <li>TE <a href="#rfc.xref.header.te.1">5.1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.h.10"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3609 <li>Trailer <a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.h.11"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> 3610 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3611 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3612 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 3821 3613 </ul> 3822 3614 </li> 3823 3615 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3824 3616 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3825 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h. 9"><b>8.4</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>3617 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.8"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3826 3618 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3827 3619 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3863 3655 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3864 3656 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3865 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7"> 4.1</a>, <a href="#rfc.xref.Part2.8">6.1.2.2</a>, <a href="#rfc.xref.Part2.9">6.1.4</a>, <a href="#rfc.xref.Part2.10">6.2.3</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">8.8</a>, <a href="#rfc.xref.Part2.15">10.6</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>3657 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">8.7</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3866 3658 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li> 3867 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2. 6">3.2</a></li>3659 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3868 3660 <li><em>Section 4</em> <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li> 3869 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2. 8">6.1.2.2</a>, <a href="#rfc.xref.Part2.9">6.1.4</a></li>3870 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2. 7">4.1</a></li>3871 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.1 0">6.2.3</a></li>3872 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.1 3">6.2.3</a></li>3661 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a></li> 3662 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.8">4.1</a></li> 3663 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.11">6.2.3</a></li> 3664 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.14">6.2.3</a></li> 3873 3665 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.4</a></li> 3874 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.14">8.8</a></li> 3875 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.16">10.6</a></li> 3876 <li><em>Section 7.4.15</em> <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.15">10.6</a></li> 3877 <li><em>Section 8.2</em> <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a></li> 3666 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.15">8.7</a></li> 3667 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.17">10.6</a></li> 3668 <li><em>Section 7.4.15</em> <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.16">10.6</a></li> 3669 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.6">3.2</a></li> 3670 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a></li> 3878 3671 </ul> 3879 3672 </li> 3880 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">5. 2.3</a>, <a href="#rfc.xref.Part3.3">5.4</a>, <a href="#rfc.xref.Part3.4">6.1.3.2</a>, <a href="#rfc.xref.Part3.5">8.7</a>, <a href="#Part3"><b>12.1</b></a><ul>3881 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2">5. 2.3</a>, <a href="#rfc.xref.Part3.5">8.7</a></li>3882 <li><em>Section 5</em> <a href="#rfc.xref.Part3.3">5. 4</a></li>3673 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">5.1.3</a>, <a href="#rfc.xref.Part3.3">5.3</a>, <a href="#rfc.xref.Part3.4">6.1.3.2</a>, <a href="#rfc.xref.Part3.5">8.6</a>, <a href="#Part3"><b>12.1</b></a><ul> 3674 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2">5.1.3</a>, <a href="#rfc.xref.Part3.5">8.6</a></li> 3675 <li><em>Section 5</em> <a href="#rfc.xref.Part3.3">5.3</a></li> 3883 3676 <li><em>Appendix A</em> <a href="#rfc.xref.Part3.1">1</a></li> 3884 3677 </ul> … … 3900 3693 <li>response <a href="#rfc.iref.r.3"><b>2.1</b></a></li> 3901 3694 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2.4</b></a></li> 3902 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">5.1</a>, <a href="#rfc.xref.RFC1123.2">5.1</a>, <a href="#RFC1123"><b>12.2</b></a><ul>3903 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">5.1</a></li>3904 </ul>3905 </li>3906 3695 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>12.2</b></a></li> 3907 3696 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li> 3908 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">5. 2.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>3909 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">5. 2.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>3910 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">5. 2.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>3911 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5. 2</a>, <a href="#RFC2045"><b>12.2</b></a><ul>3912 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">5. 2</a></li>3697 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li> 3698 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li> 3699 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">5.1.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li> 3700 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul> 3701 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">5.1</a></li> 3913 3702 </ul> 3914 3703 </li> … … 3951 3740 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li> 3952 3741 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.2</a>, <a href="#RFC4559"><b>12.2</b></a></li> 3953 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">5. 2.3</a>, <a href="#rfc.xref.RFC5226.2">8.8.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>3954 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">5. 2.3</a>, <a href="#rfc.xref.RFC5226.2">8.8.1</a></li>3742 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul> 3743 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a></li> 3955 3744 </ul> 3956 3745 </li> … … 3959 3748 </ul> 3960 3749 </li> 3961 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.1</a>, <a href="#rfc.xref.RFC5322.4">8.3</a>, <a href="#rfc.xref.RFC5322.5">8.9</a>, <a href="#RFC5322"><b>12.2</b></a><ul> 3962 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.3">5.1</a></li> 3963 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.4">8.3</a></li> 3964 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.5">8.9</a></li> 3750 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8.8</a>, <a href="#RFC5322"><b>12.2</b></a><ul> 3751 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">8.8</a></li> 3965 3752 </ul> 3966 3753 </li> … … 3977 3764 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3978 3765 <li>target resource <a href="#rfc.iref.t.4"><b>4.3</b></a></li> 3979 <li>TE header field <a href="#rfc.xref.header.te.1">5. 2</a>, <a href="#rfc.xref.header.te.2">5.2.1</a>, <a href="#rfc.xref.header.te.3">5.4</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.t.5"><b>8.5</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>3766 <li>TE header field <a href="#rfc.xref.header.te.1">5.1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.t.5"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3980 3767 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li> 3981 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">5. 2.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.6</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>3982 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5. 2</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>3768 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> 3769 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li> 3983 3770 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.4</b></a></li> 3984 3771 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.4</b></a></li> … … 3987 3774 </li> 3988 3775 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3989 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8. 8</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>3776 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3990 3777 <li>upstream <a href="#rfc.iref.u.2"><b>2.4</b></a></li> 3991 3778 <li>URI scheme … … 4000 3787 </li> 4001 3788 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 4002 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8. 9</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>3789 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li> 4003 3790 </ul> 4004 3791 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1436 r1440 4248 4248 </author> 4249 4249 <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> 4250 <organization>Rackspace</organization> 4250 4251 <address><email>mnot@mnot.net</email></address> 4251 4252 </author> -
draft-ietf-httpbis/latest/p2-semantics.html
r1436 r1440 359 359 } 360 360 @bottom-center { 361 content: "Expires March 5, 2012";361 content: "Expires March 12, 2012"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-09-0 2">411 <meta name="dct.issued" scheme="ISO8601" content="2011-09-09"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: March 5, 2012</td>442 <td class="left">Expires: March 12, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">September 2, 2011</td>495 <td class="right">September 9, 2011</td> 496 496 </tr> 497 497 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on March 5, 2012.</p>525 <p>This Internet-Draft will expire on March 12, 2012.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 931 931 <tr> 932 932 <td class="left">If-Match</td> 933 <td class="left"><a href="p4-conditional.html#header.if-match" title=" ERROR: Anchor 'header.if-match' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-match' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>933 <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 934 934 </tr> 935 935 <tr> 936 936 <td class="left">If-Modified-Since</td> 937 <td class="left"><a href="p4-conditional.html#header.if-modified-since" title=" ERROR: Anchor 'header.if-modified-since' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-modified-since' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>937 <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 938 938 </tr> 939 939 <tr> 940 940 <td class="left">If-None-Match</td> 941 <td class="left"><a href="p4-conditional.html#header.if-none-match" title=" ERROR: Anchor 'header.if-none-match' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-none-match' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>941 <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 942 942 </tr> 943 943 <tr> … … 947 947 <tr> 948 948 <td class="left">If-Unmodified-Since</td> 949 <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title=" ERROR: Anchor 'header.if-unmodified-since' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.if-unmodified-since' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>949 <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 950 950 </tr> 951 951 <tr> … … 1007 1007 <tr> 1008 1008 <td class="left">ETag</td> 1009 <td class="left"><a href="p4-conditional.html#header.etag" title="E RROR: Anchor 'header.etag' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.etag' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>1009 <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 1010 1010 </tr> 1011 1011 <tr> … … 1050 1050 </p> 1051 1051 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> 1052 <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title=" ERROR: Anchor 'status.code.definitions' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.code.definitions' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the1052 <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the 1053 1053 protocol. 1054 1054 </p> … … 1131 1131 <td class="left">304</td> 1132 1132 <td class="left">Not Modified</td> 1133 <td class="left"><a href="p4-conditional.html#status.304" title=" ERROR: Anchor 'status.304' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.304' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>1133 <td class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 1134 1134 </tr> 1135 1135 <tr> … … 1206 1206 <td class="left">412</td> 1207 1207 <td class="left">Precondition Failed</td> 1208 <td class="left"><a href="p4-conditional.html#status.412" title=" ERROR: Anchor 'status.412' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.412' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>1208 <td class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 1209 1209 </tr> 1210 1210 <tr> … … 1645 1645 </p> 1646 1646 <p id="rfc.section.7.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource 1647 just created (see <a href="p4-conditional.html#header.etag" title="E RROR: Anchor 'header.etag' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'header.etag' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).1647 just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1648 1648 </p> 1649 1649 <div id="rfc.iref.26"></div> … … 1821 1821 <h3 id="rfc.section.7.3.5"><a href="#rfc.section.7.3.5">7.3.5</a> <a id="status.304" href="#status.304">304 Not Modified</a></h3> 1822 1822 <p id="rfc.section.7.3.5.p.1">The response to the request has not been modified since the conditions indicated by the client's conditional GET request, 1823 as defined in <a href="p4-conditional.html#status.304" title=" ERROR: Anchor 'status.304' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.304' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.1823 as defined in <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 1824 1824 </p> 1825 1825 <div id="rfc.iref.36"></div> … … 1954 1954 <h3 id="rfc.section.7.4.13"><a href="#rfc.section.7.4.13">7.4.13</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h3> 1955 1955 <p id="rfc.section.7.4.13.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server, as defined 1956 in <a href="p4-conditional.html#status.412" title=" ERROR: Anchor 'status.412' not found in p4-conditional.xml.">Appendix ERROR: Anchor 'status.412' in Part4 not found in source file 'p4-conditional.xml'.</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.1956 in <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 1957 1957 </p> 1958 1958 <div id="rfc.iref.52"></div> … … 2836 2836 <tr> 2837 2837 <td class="reference"><b id="Part6">[Part6]</b></td> 2838 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" >Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011.2838 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011. 2839 2839 </td> 2840 2840 </tr> … … 3565 3565 </li> 3566 3566 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3.5</a>, <a href="#rfc.xref.Part4.11">7.4.13</a>, <a href="#Part4"><b>13.1</b></a>, <a href="#rfc.xref.Part4.12">C.2</a><ul> 3567 <li><em> Appendix </em> <a href="#rfc.xref.Part4.1">3.2</a></li>3568 <li><em> Appendix </em> <a href="#rfc.xref.Part4.2">3.2</a></li>3569 <li><em> Appendix</em> <a href="#rfc.xref.Part4.3">3.2</a></li>3570 <li><em> Appendix </em> <a href="#rfc.xref.Part4.4">3.2</a></li>3571 <li><em> Appendix </em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li>3572 <li><em> Appendix</em> <a href="#rfc.xref.Part4.6">4.1</a></li>3573 <li><em> Appendix</em> <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10">7.3.5</a></li>3574 <li><em> Appendix</em> <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.11">7.4.13</a></li>3567 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li> 3568 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3.2</a></li> 3569 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.3">3.2</a></li> 3570 <li><em>Section 3.3</em> <a href="#rfc.xref.Part4.2">3.2</a></li> 3571 <li><em>Section 3.4</em> <a href="#rfc.xref.Part4.4">3.2</a></li> 3572 <li><em>Section 4</em> <a href="#rfc.xref.Part4.6">4.1</a></li> 3573 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10">7.3.5</a></li> 3574 <li><em>Section 4.2</em> <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.11">7.4.13</a></li> 3575 3575 </ul> 3576 3576 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1436 r1440 3570 3570 </author> 3571 3571 <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> 3572 <organization>Rackspace</organization> 3572 3573 <address><email>mnot@mnot.net</email></address> 3573 3574 </author> -
draft-ietf-httpbis/latest/p3-payload.html
r1426 r1440 359 359 } 360 360 @bottom-center { 361 content: "Expires March 4, 2012";361 content: "Expires March 12, 2012"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-09-0 1">410 <meta name="dct.issued" scheme="ISO8601" content="2011-09-09"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: March 4, 2012</td>436 <td class="left">Expires: March 12, 2012</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 491 491 <tr> 492 492 <td class="left"></td> 493 <td class="right">September 1, 2011</td>493 <td class="right">September 9, 2011</td> 494 494 </tr> 495 495 </tbody> … … 519 519 in progress”. 520 520 </p> 521 <p>This Internet-Draft will expire on March 4, 2012.</p>521 <p>This Internet-Draft will expire on March 12, 2012.</p> 522 522 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 523 523 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 685 685 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 686 686 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 687 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a>>687 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a>> 688 688 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 689 689 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2> … … 717 717 </p> 718 718 <ul class="empty"> 719 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.719 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 720 720 </li> 721 721 </ul> … … 723 723 </p> 724 724 <ul class="empty"> 725 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.725 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 726 726 </li> 727 727 </ul> … … 729 729 </p> 730 730 <ul class="empty"> 731 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.731 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 732 732 </li> 733 733 </ul> … … 741 741 <li>Pointer to specification text</li> 742 742 </ul> 743 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 6.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).743 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 744 744 </p> 745 745 <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section. … … 841 841 <tr> 842 842 <td class="left">Content-Length</td> 843 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>843 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 844 844 </tr> 845 845 <tr> … … 987 987 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 988 988 </p> 989 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.989 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. 990 990 </p> 991 991 <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 992 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information992 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 993 993 within extension header fields not defined by this specification. 994 994 </p> … … 1040 1040 <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 1041 1041 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 1042 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.1042 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 1043 1043 </p> 1044 1044 <div class="note" id="rfc.section.6.1.p.5"> … … 1170 1170 </li> 1171 1171 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 1172 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)1172 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".) 1173 1173 </li> 1174 1174 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> … … 1432 1432 <td class="left">compress</td> 1433 1433 <td class="left">UNIX "compress" program method</td> 1434 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1434 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1435 1435 </td> 1436 1436 </tr> … … 1439 1439 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 1440 1440 </td> 1441 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1441 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1442 1442 </td> 1443 1443 </tr> … … 1445 1445 <td class="left">gzip</td> 1446 1446 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 1447 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1447 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1448 1448 </td> 1449 1449 </tr> … … 1482 1482 </p> 1483 1483 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1484 <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 1 2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1484 <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1485 1485 </p> 1486 1486 <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References … … 1511 1511 <tr> 1512 1512 <td class="reference"><b id="Part6">[Part6]</b></td> 1513 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" >Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011.1513 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011. 1514 1514 </td> 1515 1515 </tr> … … 1703 1703 </p> 1704 1704 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2> 1705 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p 1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.1705 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary. 1706 1706 </p> 1707 1707 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> … … 1720 1720 </p> 1721 1721 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 1722 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.1722 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 1723 1723 </p> 1724 1724 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 1797 1797 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in [Part1], Section 2.7> 1798 1798 1799 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in [Part1], Section 6.4>1799 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in [Part1], Section 5.3> 1800 1800 1801 1801 <a href="#media.types" class="smpl">subtype</a> = token … … 2121 2121 </li> 2122 2122 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2123 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.24">A. 3</a>, <a href="#rfc.xref.Part1.25">A.6</a><ul>2123 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.24">A.6</a><ul> 2124 2124 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.3</a></li> 2125 2125 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.3.1</a></li> … … 2128 2128 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.15">3.2</a></li> 2129 2129 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.19">6.7</a></li> 2130 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.24">A.3</a></li> 2131 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.12">2.2.1</a></li> 2132 <li><em>Section 6.2.2.1</em> <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li> 2133 <li><em>Section 6.2.2</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2134 <li><em>Section 6.2.2.2</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li> 2135 <li><em>Section 6.2.2.3</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li> 2136 <li><em>Section 6.4</em> <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li> 2137 <li><em>Section 9.2</em> <a href="#rfc.xref.Part1.14">3.1</a></li> 2138 <li><em>Section 9.7</em> <a href="#rfc.xref.Part1.25">A.6</a></li> 2139 <li><em>Section 12</em> <a href="#rfc.xref.Part1.23">9</a></li> 2130 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.12">2.2.1</a></li> 2131 <li><em>Section 5.1.2.1</em> <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li> 2132 <li><em>Section 5.1.2</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2133 <li><em>Section 5.1.2.2</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li> 2134 <li><em>Section 5.1.2.3</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li> 2135 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li> 2136 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.14">3.1</a></li> 2137 <li><em>Section 8.6</em> <a href="#rfc.xref.Part1.24">A.6</a></li> 2138 <li><em>Section 11</em> <a href="#rfc.xref.Part1.23">9</a></li> 2140 2139 </ul> 2141 2140 </li> 2142 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a><ul> 2143 <li><em>Section 8.9</em> <a href="#rfc.xref.Part2.1">5.1</a></li> 2141 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.2">A.3</a><ul> 2142 <li><em>Section 8</em> <a href="#rfc.xref.Part2.2">A.3</a></li> 2143 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.1">5.1</a></li> 2144 2144 </ul> 2145 2145 </li> -
draft-ietf-httpbis/latest/p3-payload.xml
r1436 r1440 1843 1843 </author> 1844 1844 <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> 1845 <organization>Rackspace</organization> 1845 1846 <address><email>mnot@mnot.net</email></address> 1846 1847 </author> -
draft-ietf-httpbis/latest/p4-conditional.html
r1437 r1440 359 359 } 360 360 @bottom-center { 361 content: "Expires March 6, 2012";361 content: "Expires March 12, 2012"; 362 362 } 363 363 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-09-0 3">406 <meta name="dct.issued" scheme="ISO8601" content="2011-09-09"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 430 430 </tr> 431 431 <tr> 432 <td class="left">Expires: March 6, 2012</td>432 <td class="left">Expires: March 12, 2012</td> 433 433 <td class="right">J. Mogul</td> 434 434 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">September 3, 2011</td>489 <td class="right">September 9, 2011</td> 490 490 </tr> 491 491 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on March 6, 2012.</p>519 <p>This Internet-Draft will expire on March 12, 2012.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1220 1220 <tr> 1221 1221 <td class="reference"><b id="Part6">[Part6]</b></td> 1222 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" >Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011.1222 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011. 1223 1223 </td> 1224 1224 </tr> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1437 r1440 1421 1421 </author> 1422 1422 <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> 1423 <organization>Rackspace</organization> 1423 1424 <address><email>mnot@mnot.net</email></address> 1424 1425 </author> -
draft-ietf-httpbis/latest/p5-range.html
r1436 r1440 359 359 } 360 360 @bottom-center { 361 content: "Expires March 5, 2012";361 content: "Expires March 12, 2012"; 362 362 } 363 363 @bottom-right { … … 406 406 <meta name="dct.creator" content="Reschke, J. F."> 407 407 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 408 <meta name="dct.issued" scheme="ISO8601" content="2011-09-0 2">408 <meta name="dct.issued" scheme="ISO8601" content="2011-09-09"> 409 409 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 410 410 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 432 432 </tr> 433 433 <tr> 434 <td class="left">Expires: March 5, 2012</td>434 <td class="left">Expires: March 12, 2012</td> 435 435 <td class="right">J. Mogul</td> 436 436 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">September 2, 2011</td>491 <td class="right">September 9, 2011</td> 492 492 </tr> 493 493 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on March 5, 2012.</p>519 <p>This Internet-Draft will expire on March 12, 2012.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r1426 r1440 359 359 } 360 360 @bottom-center { 361 content: "Expires March 4, 2012";361 content: "Expires March 12, 2012"; 362 362 } 363 363 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-09-0 1">406 <meta name="dct.issued" scheme="ISO8601" content="2011-09-09"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: March 4, 2012</td>437 <td class="left">Expires: March 12, 2012</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">September 1, 2011</td>490 <td class="right">September 9, 2011</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on March 4, 2012.</p>518 <p>This Internet-Draft will expire on March 12, 2012.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 944 944 Lawrence C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements. 945 945 </p> 946 <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 1 2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision.946 <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision. 947 947 </p> 948 948 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 958 958 <tr> 959 959 <td class="reference"><b id="Part6">[Part6]</b></td> 960 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" >Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011.960 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 2011. 961 961 </td> 962 962 </tr> … … 1235 1235 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li> 1236 1236 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.7">2.2</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a></li> 1237 <li><em>Section 1 2</em> <a href="#rfc.xref.Part1.11">7</a></li>1237 <li><em>Section 11</em> <a href="#rfc.xref.Part1.11">7</a></li> 1238 1238 </ul> 1239 1239 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r1426 r1440 911 911 </author> 912 912 <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> 913 <organization>Rackspace</organization> 913 914 <address><email>mnot@mnot.net</email></address> 914 915 </author>
Note: See TracChangeset
for help on using the changeset viewer.