![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1391 for draft-ietf-httpbis
- Timestamp:
- 08/08/11 19:38:01 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
-
p1-messaging.html (modified) (53 diffs)
-
p2-semantics.html (modified) (8 diffs)
-
p3-payload.html (modified) (7 diffs)
-
p4-conditional.html (modified) (5 diffs)
-
p5-range.html (modified) (5 diffs)
-
p6-cache.html (modified) (10 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1385 r1391 359 359 } 360 360 @bottom-center { 361 content: "Expires February 8, 2012";361 content: "Expires February 9, 2012"; 362 362 } 363 363 @bottom-right { … … 394 394 <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12"> 395 395 <link rel="Chapter" href="#rfc.section.13" title="13 References"> 396 <link rel="Appendix" title="A Tolerant Applications" href="#rfc.section.A"> 397 <link rel="Appendix" title="B HTTP Version History" href="#rfc.section.B"> 398 <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"> 399 <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D"> 396 <link rel="Appendix" title="A HTTP Version History" href="#rfc.section.A"> 397 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> 398 <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C"> 400 399 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.553, 2011-07-27 17:45:31, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 401 400 <link rel="schema.dct" href="http://purl.org/dc/terms/"> … … 410 409 <meta name="dct.creator" content="Reschke, J. F."> 411 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-08-0 7">411 <meta name="dct.issued" scheme="ISO8601" content="2011-08-08"> 413 412 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 414 413 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 442 441 </tr> 443 442 <tr> 444 <td class="left">Expires: February 8, 2012</td>443 <td class="left">Expires: February 9, 2012</td> 445 444 <td class="right">HP</td> 446 445 </tr> … … 495 494 <tr> 496 495 <td class="left"></td> 497 <td class="right">August 7, 2011</td>496 <td class="right">August 8, 2011</td> 498 497 </tr> 499 498 </tbody> … … 517 516 <p>The current issues list is at <<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>> and related documents (including fancy diffs) can be found at <<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>>. 518 517 </p> 519 <p>The changes in this draft are summarized in <a href="#changes.since.15" title="Since draft-ietf-httpbis-p1-messaging-15">Appendix D.17</a>.518 <p>The changes in this draft are summarized in <a href="#changes.since.15" title="Since draft-ietf-httpbis-p1-messaging-15">Appendix C.17</a>. 520 519 </p> 521 520 <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1> … … 528 527 in progress”. 529 528 </p> 530 <p>This Internet-Draft will expire on February 8, 2012.</p>529 <p>This Internet-Draft will expire on February 9, 2012.</p> 531 530 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 532 531 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 692 691 </li> 693 692 <li><a href="#rfc.authors">Authors' Addresses</a></li> 694 <li>A. <a href="#tolerant.applications">Tolerant Applications</a></li> 695 <li>B. <a href="#compatibility">HTTP Version History</a><ul> 696 <li>B.1 <a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul> 697 <li>B.1.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></li> 698 <li>B.1.2 <a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li> 693 <li>A. <a href="#compatibility">HTTP Version History</a><ul> 694 <li>A.1 <a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul> 695 <li>A.1.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></li> 696 <li>A.1.2 <a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li> 699 697 </ul> 700 698 </li> 701 <li> B.2 <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>699 <li>A.2 <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> 702 700 </ul> 703 701 </li> 704 <li> C. <a href="#collected.abnf">Collected ABNF</a></li>705 <li> D. <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>706 <li> D.1 <a href="#rfc.section.D.1">Since RFC 2616</a></li>707 <li> D.2 <a href="#rfc.section.D.2">Since draft-ietf-httpbis-p1-messaging-00</a></li>708 <li> D.3 <a href="#rfc.section.D.3">Since draft-ietf-httpbis-p1-messaging-01</a></li>709 <li> D.4 <a href="#changes.since.02">Since draft-ietf-httpbis-p1-messaging-02</a></li>710 <li> D.5 <a href="#changes.since.03">Since draft-ietf-httpbis-p1-messaging-03</a></li>711 <li> D.6 <a href="#changes.since.04">Since draft-ietf-httpbis-p1-messaging-04</a></li>712 <li> D.7 <a href="#changes.since.05">Since draft-ietf-httpbis-p1-messaging-05</a></li>713 <li> D.8 <a href="#changes.since.06">Since draft-ietf-httpbis-p1-messaging-06</a></li>714 <li> D.9 <a href="#changes.since.07">Since draft-ietf-httpbis-p1-messaging-07</a></li>715 <li> D.10 <a href="#changes.since.08">Since draft-ietf-httpbis-p1-messaging-08</a></li>716 <li> D.11 <a href="#changes.since.09">Since draft-ietf-httpbis-p1-messaging-09</a></li>717 <li> D.12 <a href="#changes.since.10">Since draft-ietf-httpbis-p1-messaging-10</a></li>718 <li> D.13 <a href="#changes.since.11">Since draft-ietf-httpbis-p1-messaging-11</a></li>719 <li> D.14 <a href="#changes.since.12">Since draft-ietf-httpbis-p1-messaging-12</a></li>720 <li> D.15 <a href="#changes.since.13">Since draft-ietf-httpbis-p1-messaging-13</a></li>721 <li> D.16 <a href="#changes.since.14">Since draft-ietf-httpbis-p1-messaging-14</a></li>722 <li> D.17 <a href="#changes.since.15">Since draft-ietf-httpbis-p1-messaging-15</a></li>702 <li>B. <a href="#collected.abnf">Collected ABNF</a></li> 703 <li>C. <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul> 704 <li>C.1 <a href="#rfc.section.C.1">Since RFC 2616</a></li> 705 <li>C.2 <a href="#rfc.section.C.2">Since draft-ietf-httpbis-p1-messaging-00</a></li> 706 <li>C.3 <a href="#rfc.section.C.3">Since draft-ietf-httpbis-p1-messaging-01</a></li> 707 <li>C.4 <a href="#changes.since.02">Since draft-ietf-httpbis-p1-messaging-02</a></li> 708 <li>C.5 <a href="#changes.since.03">Since draft-ietf-httpbis-p1-messaging-03</a></li> 709 <li>C.6 <a href="#changes.since.04">Since draft-ietf-httpbis-p1-messaging-04</a></li> 710 <li>C.7 <a href="#changes.since.05">Since draft-ietf-httpbis-p1-messaging-05</a></li> 711 <li>C.8 <a href="#changes.since.06">Since draft-ietf-httpbis-p1-messaging-06</a></li> 712 <li>C.9 <a href="#changes.since.07">Since draft-ietf-httpbis-p1-messaging-07</a></li> 713 <li>C.10 <a href="#changes.since.08">Since draft-ietf-httpbis-p1-messaging-08</a></li> 714 <li>C.11 <a href="#changes.since.09">Since draft-ietf-httpbis-p1-messaging-09</a></li> 715 <li>C.12 <a href="#changes.since.10">Since draft-ietf-httpbis-p1-messaging-10</a></li> 716 <li>C.13 <a href="#changes.since.11">Since draft-ietf-httpbis-p1-messaging-11</a></li> 717 <li>C.14 <a href="#changes.since.12">Since draft-ietf-httpbis-p1-messaging-12</a></li> 718 <li>C.15 <a href="#changes.since.13">Since draft-ietf-httpbis-p1-messaging-13</a></li> 719 <li>C.16 <a href="#changes.since.14">Since draft-ietf-httpbis-p1-messaging-14</a></li> 720 <li>C.17 <a href="#changes.since.15">Since draft-ietf-httpbis-p1-messaging-15</a></li> 723 721 </ul> 724 722 </li> … … 814 812 "," 815 813 ", ," 816 </pre><p id="rfc.section.1.2.1.p.15"> <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF, with the list rules expanded as explained above.814 </pre><p id="rfc.section.1.2.1.p.15"> <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rules expanded as explained above. 817 815 </p> 818 816 <h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h3> 819 <div id="rule.CRLF">820 <p id="rfc.section.1.2.2.p.1"> HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements other than the message-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for tolerant applications).821 </p>822 </div>823 817 <div id="rule.LWS"> 824 <p id="rfc.section.1.2.2.p. 2">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),818 <p id="rfc.section.1.2.2.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), 825 819 and BWS ("bad" whitespace). 826 820 </p> 827 821 </div> 828 822 <div id="rule.OWS"> 829 <p id="rfc.section.1.2.2.p. 3">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.823 <p id="rfc.section.1.2.2.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream. 830 824 </p> 831 825 </div> 832 826 <div id="rule.RWS"> 833 <p id="rfc.section.1.2.2.p. 4">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.827 <p id="rfc.section.1.2.2.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream. 834 828 </p> 835 829 </div> 836 830 <div id="rule.BWS"> 837 <p id="rfc.section.1.2.2.p. 5">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.831 <p id="rfc.section.1.2.2.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. 838 832 </p> 839 833 </div> 840 834 <div id="rule.whitespace"> 841 <p id="rfc.section.1.2.2.p. 6"> </p>835 <p id="rfc.section.1.2.2.p.5"> </p> 842 836 </div> 843 837 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> ) … … 850 844 ; see <a href="#header.fields" title="Header Fields">Section 3.2</a> 851 845 </pre><div id="rule.token.separators"> 852 <p id="rfc.section.1.2.2.p. 8"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.846 <p id="rfc.section.1.2.2.p.7"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. 853 847 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 6.2</a>). 854 848 </p> … … 867 861 / "]" / "?" / "=" / "{" / "}" 868 862 </pre><div id="rule.quoted-string"> 869 <p id="rfc.section.1.2.2.p. 10"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p>863 <p id="rfc.section.1.2.2.p.9"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 870 864 </div> 871 865 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#rule.quoted-string" class="smpl">quoted-string</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> … … 874 868 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF 875 869 </pre><div id="rule.quoted-pair"> 876 <p id="rfc.section.1.2.2.p.1 2"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p>870 <p id="rfc.section.1.2.2.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p> 877 871 </div> 878 872 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 879 </pre><p id="rfc.section.1.2.2.p.1 4">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.880 </p> 881 <p id="rfc.section.1.2.2.p.1 5">Senders <em class="bcp14">SHOULD NOT</em> escape octets that do not require escaping (i.e., other than DQUOTE and the backslash octet).873 </pre><p id="rfc.section.1.2.2.p.13">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 874 </p> 875 <p id="rfc.section.1.2.2.p.14">Senders <em class="bcp14">SHOULD NOT</em> escape octets that do not require escaping (i.e., other than DQUOTE and the backslash octet). 882 876 </p> 883 877 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP-related architecture</a></h1> … … 1218 1212 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> 1219 1213 <p id="rfc.section.3.1.p.1">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol 1220 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. 1214 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend 1215 that recipients recognize a single LF as a line terminator and ignore any CR. 1221 1216 </p> 1222 1217 <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations send an extra CRLF after a POST request as a lame workaround for some early server … … 1386 1381 <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number 1387 1382 of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received) 1388 cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST NOT</em> be stored by a cache.1383 cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error. 1389 1384 </p> 1390 1385 <p id="rfc.section.3.4.p.3">A message-body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding … … 1526 1521 field. 1527 1522 </p> 1528 <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix B.1.1</a> for other requirements on Host support in HTTP/1.1.)1523 <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix A.1.1</a> for other requirements on Host support in HTTP/1.1.) 1529 1524 </p> 1530 1525 <p id="rfc.section.4.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or … … 1620 1615 <div id="rfc.figure.u.42"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1621 1616 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1622 </pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for further information.1617 </pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. 1623 1618 </p> 1624 1619 <p id="rfc.section.6.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 … … 1909 1904 for the connection. 1910 1905 </p> 1911 <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix B.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.1906 <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 1912 1907 </p> 1913 1908 <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. … … 2080 2075 <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. 2081 2076 </li> 2082 <li>Proxies <em class="bcp14">SHOULD</em> maintain a cache recordingthe HTTP version numbers received from recently-referenced next-hop servers.2077 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. 2083 2078 </li> 2084 2079 <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 … … 2253 2248 message that contains more than one Host header field or a Host header field with an invalid field-value. 2254 2249 </p> 2255 <p id="rfc.section.9.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"> B.1.1</a> for other requirements relating to Host.2250 <p id="rfc.section.9.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. 2256 2251 </p> 2257 2252 <div id="rfc.iref.t.5"></div> … … 3014 3009 <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> 3015 3010 </div> 3016 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="tolerant.applications" href="#tolerant.applications">Tolerant Applications</a></h1> 3017 <p id="rfc.section.A.p.1">Although this document specifies the requirements for the generation of HTTP/1.1 messages, not all applications will be correct 3018 in their implementation. We therefore recommend that operational applications be tolerant of deviations whenever those deviations 3019 can be interpreted unambiguously. 3020 </p> 3021 <p id="rfc.section.A.p.2">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers 3022 fields, recognize a single LF as a line terminator and ignore the leading CR. 3023 </p> 3024 <p id="rfc.section.A.p.3">The character encoding of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that 3025 not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 3026 </p> 3027 <p id="rfc.section.A.p.4">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> 3028 <p id="rfc.section.A.p.5"> </p> 3029 <ul> 3030 <li>HTTP/1.1 clients and caches <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve 3031 the "year 2000" problem). 3032 </li> 3033 <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. 3034 </li> 3035 <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed Expires date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value. 3036 </li> 3037 <li>All expiration-related calculations <em class="bcp14">MUST</em> be done in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time. 3038 </li> 3039 <li>If an HTTP header field incorrectly carries a date value with a time zone other than GMT, it <em class="bcp14">MUST</em> be converted into GMT using the most conservative possible conversion. 3040 </li> 3041 </ul> 3042 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="compatibility" href="#compatibility">HTTP Version History</a></h1> 3043 <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred 3011 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">HTTP Version History</a></h1> 3012 <p id="rfc.section.A.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred 3044 3013 to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request method (GET) 3045 3014 and no metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers … … 3049 3018 to determine each other's true capabilities. 3050 3019 </p> 3051 <p id="rfc.section. B.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding3020 <p id="rfc.section.A.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding 3052 3021 only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a 3053 3022 party advertising compliance with HTTP/1.1. 3054 3023 </p> 3055 <p id="rfc.section. B.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately3024 <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately 3056 3025 designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand 3057 3026 any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood 3058 3027 (or safely ignored) by HTTP/1.0 clients. Likewise, would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response. 3059 3028 </p> 3060 <p id="rfc.section. B.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts3029 <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts 3061 3030 (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought 3062 3031 to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests 3063 3032 wherein a buggy client failed to properly encode linear whitespace found in a URI reference and placed in the request-target. 3064 3033 </p> 3065 <h2 id="rfc.section. B.1"><a href="#rfc.section.B.1">B.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>3066 <p id="rfc.section. B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>3067 <h3 id="rfc.section. B.1.1"><a href="#rfc.section.B.1.1">B.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>3068 <p id="rfc.section. B.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by HTTP/1.1.3069 </p> 3070 <p id="rfc.section. B.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 mechanism3034 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> 3035 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3036 <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> 3037 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by HTTP/1.1. 3038 </p> 3039 <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 3071 3040 for distinguishing the intended server of a request than the IP address to which that request was directed. The Host header 3072 3041 field was introduced during the development of HTTP/1.1 and, though it was quickly implemented by most HTTP/1.0 browsers, … … 3074 3043 most HTTP-based services are dependent upon the Host header field for targeting requests. 3075 3044 </p> 3076 <h3 id="rfc.section. B.1.2"><a href="#rfc.section.B.1.2">B.1.2</a> <a id="compatibility.with.http.1.0.persistent.connections" href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></h3>3077 <p id="rfc.section. B.1.2.p.1">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the3045 <h3 id="rfc.section.A.1.2"><a href="#rfc.section.A.1.2">A.1.2</a> <a id="compatibility.with.http.1.0.persistent.connections" href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></h3> 3046 <p id="rfc.section.A.1.2.p.1">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 3078 3047 server after sending the response. However, some implementations implement the Keep-Alive version of persistent connections 3079 3048 described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 3080 3049 </p> 3081 <p id="rfc.section. B.1.2.p.2">Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.03050 <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0 3082 3051 clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0 3083 3052 experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify … … 3087 3056 from using Keep-Alive when talking to proxies. 3088 3057 </p> 3089 <p id="rfc.section. B.1.2.p.3">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable.3058 <p id="rfc.section.A.1.2.p.3">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. 3090 3059 Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when 3091 3060 talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce 3092 3061 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 9.1</a>. 3093 3062 </p> 3094 <h2 id="rfc.section. B.2"><a href="#rfc.section.B.2">B.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>3095 <p id="rfc.section. B.2.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a>)3096 </p> 3097 <p id="rfc.section. B.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically3063 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 3064 <p id="rfc.section.A.2.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a>) 3065 </p> 3066 <p id="rfc.section.A.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically 3098 3067 pointed out in the ABNF. The NUL octet is no longer allowed in comment and quoted-string text. The quoted-pair rule no longer 3099 3068 allows escaping control characters other than HTAB. Non-ASCII content in header fields and reason phrase has been obsoleted 3100 3069 and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>) 3101 3070 </p> 3102 <p id="rfc.section. B.2.p.3">Clarify that the string "HTTP" in the HTTP-Version ABFN production is case sensitive. Restrict the version numbers to be single3071 <p id="rfc.section.A.2.p.3">Clarify that the string "HTTP" in the HTTP-Version ABFN production is case sensitive. Restrict the version numbers to be single 3103 3072 digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section 2.6</a>) 3104 3073 </p> 3105 <p id="rfc.section. B.2.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>)3106 </p> 3107 <p id="rfc.section. B.2.p.5">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>)3108 </p> 3109 <p id="rfc.section. B.2.p.6">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">6.2</a>)3110 </p> 3111 <p id="rfc.section. B.2.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk3074 <p id="rfc.section.A.2.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 3075 </p> 3076 <p id="rfc.section.A.2.p.5">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>) 3077 </p> 3078 <p id="rfc.section.A.2.p.6">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">6.2</a>) 3079 </p> 3080 <p id="rfc.section.A.2.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk 3112 3081 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section 4.1.2</a>) 3113 3082 </p> 3114 <p id="rfc.section. B.2.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore3083 <p id="rfc.section.A.2.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore 3115 3084 disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>) 3116 3085 </p> 3117 <p id="rfc.section. B.2.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 7.1.4</a>)3118 </p> 3119 <p id="rfc.section. B.2.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>)3120 </p> 3121 <p id="rfc.section. B.2.p.11">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section 9.1</a>)3122 </p> 3123 <p id="rfc.section. B.2.p.12">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 9.8</a>)3124 </p> 3125 <h1 id="rfc.section. C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>3086 <p id="rfc.section.A.2.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 7.1.4</a>) 3087 </p> 3088 <p id="rfc.section.A.2.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 3089 </p> 3090 <p id="rfc.section.A.2.p.11">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section 9.1</a>) 3091 </p> 3092 <p id="rfc.section.A.2.p.12">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 9.8</a>) 3093 </p> 3094 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3126 3095 <div id="rfc.figure.u.74"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3127 3096 … … 3309 3278 ; partial-URI defined but not used 3310 3279 ; special defined but not used 3311 </pre><h1 id="rfc.section. D"><a href="#rfc.section.D">D.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>3312 <h2 id="rfc.section. D.1"><a href="#rfc.section.D.1">D.1</a> Since RFC 26163280 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> 3281 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> Since RFC 2616 3313 3282 </h2> 3314 <p id="rfc.section. D.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.3315 </p> 3316 <h2 id="rfc.section. D.2"><a href="#rfc.section.D.2">D.2</a> Since draft-ietf-httpbis-p1-messaging-003283 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 3284 </p> 3285 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> Since draft-ietf-httpbis-p1-messaging-00 3317 3286 </h2> 3318 <p id="rfc.section. D.2.p.1">Closed issues: </p>3287 <p id="rfc.section.C.2.p.1">Closed issues: </p> 3319 3288 <ul> 3320 3289 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/1">http://tools.ietf.org/wg/httpbis/trac/ticket/1</a>>: "HTTP Version should be case sensitive" (<<a href="http://purl.org/NET/http-errata#verscase">http://purl.org/NET/http-errata#verscase</a>>) … … 3357 3326 </li> 3358 3327 </ul> 3359 <p id="rfc.section. D.2.p.2">Other changes: </p>3328 <p id="rfc.section.C.2.p.2">Other changes: </p> 3360 3329 <ul> 3361 3330 <li>Update media type registrations to use RFC4288 template.</li> … … 3363 3332 </li> 3364 3333 </ul> 3365 <h2 id="rfc.section. D.3"><a href="#rfc.section.D.3">D.3</a> Since draft-ietf-httpbis-p1-messaging-013334 <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a> Since draft-ietf-httpbis-p1-messaging-01 3366 3335 </h2> 3367 <p id="rfc.section. D.3.p.1">Closed issues: </p>3336 <p id="rfc.section.C.3.p.1">Closed issues: </p> 3368 3337 <ul> 3369 3338 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/19">http://tools.ietf.org/wg/httpbis/trac/ticket/19</a>>: "Bodies on GET (and other) requests" … … 3376 3345 </li> 3377 3346 </ul> 3378 <p id="rfc.section. D.3.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):3347 <p id="rfc.section.C.3.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 3379 3348 </p> 3380 3349 <ul> … … 3391 3360 <li>Rewrite prose rule "token" in terms of "tchar", rewrite prose rule "TEXT".</li> 3392 3361 </ul> 3393 <h2 id="rfc.section. D.4"><a href="#rfc.section.D.4">D.4</a> <a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p1-messaging-02</a></h2>3394 <p id="rfc.section. D.4.p.1">Closed issues: </p>3362 <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a> <a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p1-messaging-02</a></h2> 3363 <p id="rfc.section.C.4.p.1">Closed issues: </p> 3395 3364 <ul> 3396 3365 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/51">http://tools.ietf.org/wg/httpbis/trac/ticket/51</a>>: "HTTP-date vs. rfc1123-date" … … 3399 3368 </li> 3400 3369 </ul> 3401 <p id="rfc.section. D.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):3370 <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 3402 3371 </p> 3403 3372 <ul> 3404 3373 <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li> 3405 3374 </ul> 3406 <p id="rfc.section. D.4.p.3">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):3375 <p id="rfc.section.C.4.p.3">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 3407 3376 </p> 3408 3377 <ul> 3409 3378 <li>Replace string literals when the string really is case-sensitive (HTTP-Version).</li> 3410 3379 </ul> 3411 <h2 id="rfc.section. D.5"><a href="#rfc.section.D.5">D.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p1-messaging-03</a></h2>3412 <p id="rfc.section. D.5.p.1">Closed issues: </p>3380 <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p1-messaging-03</a></h2> 3381 <p id="rfc.section.C.5.p.1">Closed issues: </p> 3413 3382 <ul> 3414 3383 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/28">http://tools.ietf.org/wg/httpbis/trac/ticket/28</a>>: "Connection closing" … … 3425 3394 </li> 3426 3395 </ul> 3427 <p id="rfc.section. D.5.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):3396 <p id="rfc.section.C.5.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 3428 3397 </p> 3429 3398 <ul> … … 3431 3400 <li>Replace HEX by HEXDIG for future consistence with RFC 5234's core rules.</li> 3432 3401 </ul> 3433 <h2 id="rfc.section. D.6"><a href="#rfc.section.D.6">D.6</a> <a id="changes.since.04" href="#changes.since.04">Since draft-ietf-httpbis-p1-messaging-04</a></h2>3434 <p id="rfc.section. D.6.p.1">Closed issues: </p>3402 <h2 id="rfc.section.C.6"><a href="#rfc.section.C.6">C.6</a> <a id="changes.since.04" href="#changes.since.04">Since draft-ietf-httpbis-p1-messaging-04</a></h2> 3403 <p id="rfc.section.C.6.p.1">Closed issues: </p> 3435 3404 <ul> 3436 3405 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/34">http://tools.ietf.org/wg/httpbis/trac/ticket/34</a>>: "Out-of-date reference for URIs" … … 3439 3408 </li> 3440 3409 </ul> 3441 <p id="rfc.section. D.6.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):3410 <p id="rfc.section.C.6.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 3442 3411 </p> 3443 3412 <ul> … … 3448 3417 <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li> 3449 3418 </ul> 3450 <h2 id="rfc.section. D.7"><a href="#rfc.section.D.7">D.7</a> <a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p1-messaging-05</a></h2>3451 <p id="rfc.section. D.7.p.1">Closed issues: </p>3419 <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a> <a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p1-messaging-05</a></h2> 3420 <p id="rfc.section.C.7.p.1">Closed issues: </p> 3452 3421 <ul> 3453 3422 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/30">http://tools.ietf.org/wg/httpbis/trac/ticket/30</a>>: "Header LWS" … … 3472 3441 </li> 3473 3442 </ul> 3474 <p id="rfc.section. D.7.p.2">Final work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):3443 <p id="rfc.section.C.7.p.2">Final work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 3475 3444 </p> 3476 3445 <ul> … … 3478 3447 <li>Add appendix containing collected and expanded ABNF.</li> 3479 3448 </ul> 3480 <p id="rfc.section. D.7.p.3">Other changes: </p>3449 <p id="rfc.section.C.7.p.3">Other changes: </p> 3481 3450 <ul> 3482 3451 <li>Rewrite introduction; add mostly new Architecture Section.</li> … … 3485 3454 </li> 3486 3455 </ul> 3487 <h2 id="rfc.section. D.8"><a href="#rfc.section.D.8">D.8</a> <a id="changes.since.06" href="#changes.since.06">Since draft-ietf-httpbis-p1-messaging-06</a></h2>3488 <p id="rfc.section. D.8.p.1">Closed issues: </p>3456 <h2 id="rfc.section.C.8"><a href="#rfc.section.C.8">C.8</a> <a id="changes.since.06" href="#changes.since.06">Since draft-ietf-httpbis-p1-messaging-06</a></h2> 3457 <p id="rfc.section.C.8.p.1">Closed issues: </p> 3489 3458 <ul> 3490 3459 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/161">http://tools.ietf.org/wg/httpbis/trac/ticket/161</a>>: "base for numeric protocol elements" … … 3493 3462 </li> 3494 3463 </ul> 3495 <p id="rfc.section. D.8.p.2">Partly resolved issues: </p>3464 <p id="rfc.section.C.8.p.2">Partly resolved issues: </p> 3496 3465 <ul> 3497 3466 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>>: "205 Bodies" (took out language that implied that there might be methods for which a request body MUST NOT be included) … … 3500 3469 </li> 3501 3470 </ul> 3502 <h2 id="rfc.section. D.9"><a href="#rfc.section.D.9">D.9</a> <a id="changes.since.07" href="#changes.since.07">Since draft-ietf-httpbis-p1-messaging-07</a></h2>3503 <p id="rfc.section. D.9.p.1">Closed issues: </p>3471 <h2 id="rfc.section.C.9"><a href="#rfc.section.C.9">C.9</a> <a id="changes.since.07" href="#changes.since.07">Since draft-ietf-httpbis-p1-messaging-07</a></h2> 3472 <p id="rfc.section.C.9.p.1">Closed issues: </p> 3504 3473 <ul> 3505 3474 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/93">http://tools.ietf.org/wg/httpbis/trac/ticket/93</a>>: "Repeating single-value headers" … … 3522 3491 </li> 3523 3492 </ul> 3524 <p id="rfc.section. D.9.p.2">Partly resolved issues: </p>3493 <p id="rfc.section.C.9.p.2">Partly resolved issues: </p> 3525 3494 <ul> 3526 3495 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/148">http://tools.ietf.org/wg/httpbis/trac/ticket/148</a>>: "update IANA requirements wrt Transfer-Coding values" (add the IANA Considerations subsection) 3527 3496 </li> 3528 3497 </ul> 3529 <h2 id="rfc.section. D.10"><a href="#rfc.section.D.10">D.10</a> <a id="changes.since.08" href="#changes.since.08">Since draft-ietf-httpbis-p1-messaging-08</a></h2>3530 <p id="rfc.section. D.10.p.1">Closed issues: </p>3498 <h2 id="rfc.section.C.10"><a href="#rfc.section.C.10">C.10</a> <a id="changes.since.08" href="#changes.since.08">Since draft-ietf-httpbis-p1-messaging-08</a></h2> 3499 <p id="rfc.section.C.10.p.1">Closed issues: </p> 3531 3500 <ul> 3532 3501 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/201">http://tools.ietf.org/wg/httpbis/trac/ticket/201</a>>: "header parsing, treatment of leading and trailing OWS" 3533 3502 </li> 3534 3503 </ul> 3535 <p id="rfc.section. D.10.p.2">Partly resolved issues: </p>3504 <p id="rfc.section.C.10.p.2">Partly resolved issues: </p> 3536 3505 <ul> 3537 3506 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/60">http://tools.ietf.org/wg/httpbis/trac/ticket/60</a>>: "Placement of 13.5.1 and 13.5.2" … … 3540 3509 </li> 3541 3510 </ul> 3542 <h2 id="rfc.section. D.11"><a href="#rfc.section.D.11">D.11</a> <a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-p1-messaging-09</a></h2>3543 <p id="rfc.section. D.11.p.1">Closed issues: </p>3511 <h2 id="rfc.section.C.11"><a href="#rfc.section.C.11">C.11</a> <a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-p1-messaging-09</a></h2> 3512 <p id="rfc.section.C.11.p.1">Closed issues: </p> 3544 3513 <ul> 3545 3514 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/73">http://tools.ietf.org/wg/httpbis/trac/ticket/73</a>>: "Clarification of the term 'deflate'" … … 3556 3525 </li> 3557 3526 </ul> 3558 <p id="rfc.section. D.11.p.2">Partly resolved issues: </p>3527 <p id="rfc.section.C.11.p.2">Partly resolved issues: </p> 3559 3528 <ul> 3560 3529 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 3561 3530 </li> 3562 3531 </ul> 3563 <h2 id="rfc.section. D.12"><a href="#rfc.section.D.12">D.12</a> <a id="changes.since.10" href="#changes.since.10">Since draft-ietf-httpbis-p1-messaging-10</a></h2>3564 <p id="rfc.section. D.12.p.1">Closed issues: </p>3532 <h2 id="rfc.section.C.12"><a href="#rfc.section.C.12">C.12</a> <a id="changes.since.10" href="#changes.since.10">Since draft-ietf-httpbis-p1-messaging-10</a></h2> 3533 <p id="rfc.section.C.12.p.1">Closed issues: </p> 3565 3534 <ul> 3566 3535 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/28">http://tools.ietf.org/wg/httpbis/trac/ticket/28</a>>: "Connection Closing" … … 3575 3544 </li> 3576 3545 </ul> 3577 <p id="rfc.section. D.12.p.2">Partly resolved issues: </p>3546 <p id="rfc.section.C.12.p.2">Partly resolved issues: </p> 3578 3547 <ul> 3579 3548 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/159">http://tools.ietf.org/wg/httpbis/trac/ticket/159</a>>: "HTTP(s) URI scheme definitions" 3580 3549 </li> 3581 3550 </ul> 3582 <h2 id="rfc.section. D.13"><a href="#rfc.section.D.13">D.13</a> <a id="changes.since.11" href="#changes.since.11">Since draft-ietf-httpbis-p1-messaging-11</a></h2>3583 <p id="rfc.section. D.13.p.1">Closed issues: </p>3551 <h2 id="rfc.section.C.13"><a href="#rfc.section.C.13">C.13</a> <a id="changes.since.11" href="#changes.since.11">Since draft-ietf-httpbis-p1-messaging-11</a></h2> 3552 <p id="rfc.section.C.13.p.1">Closed issues: </p> 3584 3553 <ul> 3585 3554 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/193">http://tools.ietf.org/wg/httpbis/trac/ticket/193</a>>: "Trailer requirements" … … 3592 3561 </li> 3593 3562 </ul> 3594 <p id="rfc.section. D.13.p.2">Partly resolved issues: </p>3563 <p id="rfc.section.C.13.p.2">Partly resolved issues: </p> 3595 3564 <ul> 3596 3565 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length headers" 3597 3566 </li> 3598 3567 </ul> 3599 <h2 id="rfc.section. D.14"><a href="#rfc.section.D.14">D.14</a> <a id="changes.since.12" href="#changes.since.12">Since draft-ietf-httpbis-p1-messaging-12</a></h2>3600 <p id="rfc.section. D.14.p.1">Closed issues: </p>3568 <h2 id="rfc.section.C.14"><a href="#rfc.section.C.14">C.14</a> <a id="changes.since.12" href="#changes.since.12">Since draft-ietf-httpbis-p1-messaging-12</a></h2> 3569 <p id="rfc.section.C.14.p.1">Closed issues: </p> 3601 3570 <ul> 3602 3571 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/75">http://tools.ietf.org/wg/httpbis/trac/ticket/75</a>>: "RFC2145 Normative" … … 3617 3586 </li> 3618 3587 </ul> 3619 <h2 id="rfc.section. D.15"><a href="#rfc.section.D.15">D.15</a> <a id="changes.since.13" href="#changes.since.13">Since draft-ietf-httpbis-p1-messaging-13</a></h2>3620 <p id="rfc.section. D.15.p.1">Closed issues: </p>3588 <h2 id="rfc.section.C.15"><a href="#rfc.section.C.15">C.15</a> <a id="changes.since.13" href="#changes.since.13">Since draft-ietf-httpbis-p1-messaging-13</a></h2> 3589 <p id="rfc.section.C.15.p.1">Closed issues: </p> 3621 3590 <ul> 3622 3591 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/53">http://tools.ietf.org/wg/httpbis/trac/ticket/53</a>>: "Allow is not in 13.5.2" … … 3629 3598 </li> 3630 3599 </ul> 3631 <h2 id="rfc.section. D.16"><a href="#rfc.section.D.16">D.16</a> <a id="changes.since.14" href="#changes.since.14">Since draft-ietf-httpbis-p1-messaging-14</a></h2>3632 <p id="rfc.section. D.16.p.1">Closed issues: </p>3600 <h2 id="rfc.section.C.16"><a href="#rfc.section.C.16">C.16</a> <a id="changes.since.14" href="#changes.since.14">Since draft-ietf-httpbis-p1-messaging-14</a></h2> 3601 <p id="rfc.section.C.16.p.1">Closed issues: </p> 3633 3602 <ul> 3634 3603 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/273">http://tools.ietf.org/wg/httpbis/trac/ticket/273</a>>: "HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT" … … 3641 3610 </li> 3642 3611 </ul> 3643 <h2 id="rfc.section. D.17"><a href="#rfc.section.D.17">D.17</a> <a id="changes.since.15" href="#changes.since.15">Since draft-ietf-httpbis-p1-messaging-15</a></h2>3644 <p id="rfc.section. D.17.p.1">Closed issues: </p>3612 <h2 id="rfc.section.C.17"><a href="#rfc.section.C.17">C.17</a> <a id="changes.since.15" href="#changes.since.15">Since draft-ietf-httpbis-p1-messaging-15</a></h2> 3613 <p id="rfc.section.C.17.p.1">Closed issues: </p> 3645 3614 <ul> 3646 3615 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/100">http://tools.ietf.org/wg/httpbis/trac/ticket/100</a>>: "DNS Spoofing / DNS Binding advice" … … 3687 3656 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3688 3657 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3689 <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.5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11"> B.1.2</a>, <a href="#rfc.xref.header.connection.12">B.2</a></li>3658 <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.5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">A.1.2</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3690 3659 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3691 3660 </ul> … … 3820 3789 <li>Header Fields 3821 3790 <ul> 3822 <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.5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11"> B.1.2</a>, <a href="#rfc.xref.header.connection.12">B.2</a></li>3791 <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.5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">A.1.2</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3823 3792 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3824 3793 <li>Date <a href="#rfc.xref.header.date.1">3.5</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li> 3825 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.iref.h.10"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3"> B.1.1</a></li>3794 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.iref.h.10"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> 3826 3795 <li>TE <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.iref.h.11"><b>9.5</b></a>, <a href="#rfc.xref.header.te.4">10.1</a></li> 3827 3796 <li>Trailer <a href="#rfc.xref.header.trailer.1">3.5</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li> 3828 3797 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.5</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 3829 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">3.5</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3"> B.2</a></li>3798 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">3.5</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3830 3799 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">3.5</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 3831 3800 </ul> … … 3833 3802 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3834 3803 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3835 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.iref.h.9"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3"> B.1.1</a></li>3804 <li>Host header field <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.iref.h.9"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> 3836 3805 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3837 3806 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3886 3855 </ul> 3887 3856 </li> 3888 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.3">6.4</a>, <a href="#rfc.xref.Part3.4">7.1.3.2</a>, <a href="#rfc.xref.Part3.5">9.7</a>, <a href="#Part3"><b>13.1</b></a> , <a href="#rfc.xref.Part3.6">A</a><ul>3857 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.3">6.4</a>, <a href="#rfc.xref.Part3.4">7.1.3.2</a>, <a href="#rfc.xref.Part3.5">9.7</a>, <a href="#Part3"><b>13.1</b></a><ul> 3889 3858 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.5">9.7</a></li> 3890 3859 <li><em>Section 5</em> <a href="#rfc.xref.Part3.3">6.4</a></li> … … 3913 3882 </li> 3914 3883 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>13.2</b></a></li> 3915 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.2"> B</a></li>3884 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li> 3916 3885 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1950.2">10.4</a>, <a href="#RFC1950"><b>13.1</b></a></li> 3917 3886 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1951.2">10.4</a>, <a href="#RFC1951"><b>13.1</b></a></li> … … 3922 3891 </li> 3923 3892 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li> 3924 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.4">7.2.3</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8"> B.1.2</a><ul>3925 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.8"> B.1.2</a></li>3893 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.4">7.2.3</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a><ul> 3894 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a></li> 3926 3895 </ul> 3927 3896 </li> 3928 3897 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>13.1</b></a></li> 3929 3898 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">§</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#RFC2145"><b>13.2</b></a></li> 3930 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.6</a>, <a href="#rfc.xref.RFC2616.4">12</a>, <a href="#rfc.xref.RFC2616.5">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.6"> D.1</a><ul>3899 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.6</a>, <a href="#rfc.xref.RFC2616.4">12</a>, <a href="#rfc.xref.RFC2616.5">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.6">C.1</a><ul> 3931 3900 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.5">12</a></li> 3932 3901 </ul> 3933 3902 </li> 3934 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.3"> B.2</a><ul>3903 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul> 3935 3904 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">10.5</a></li> 3936 3905 </ul> … … 3995 3964 </li> 3996 3965 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3997 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">3.5</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3"> B.2</a></li>3966 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">3.5</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li> 3998 3967 <li>upstream <a href="#rfc.iref.u.2"><b>2.4</b></a></li> 3999 3968 <li>URI scheme -
draft-ietf-httpbis/latest/p2-semantics.html
r1375 r1391 359 359 } 360 360 @bottom-center { 361 content: "Expires February 4, 2012";361 content: "Expires February 9, 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-08-0 3">411 <meta name="dct.issued" scheme="ISO8601" content="2011-08-08"> 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: February 4, 2012</td>442 <td class="left">Expires: February 9, 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">August 3, 2011</td>495 <td class="right">August 8, 2011</td> 496 496 </tr> 497 497 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on February 4, 2012.</p>525 <p>This Internet-Draft will expire on February 9, 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> … … 1217 1217 <tr> 1218 1218 <td class="left">ETag</td> 1219 <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2. 2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>1219 <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 1220 1220 </tr> 1221 1221 <tr> … … 1586 1586 </p> 1587 1587 <p id="rfc.section.8.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 1588 just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2. 2</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).1588 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>). 1589 1589 </p> 1590 1590 <div id="rfc.iref.26"></div> … … 3256 3256 </li> 3257 3257 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3</a>, <a href="#rfc.xref.Part4.2">3</a>, <a href="#rfc.xref.Part4.3">3</a>, <a href="#rfc.xref.Part4.4">3</a>, <a href="#rfc.xref.Part4.5">4.1</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">5</a>, <a href="#rfc.xref.Part4.9">8.2.2</a>, <a href="#rfc.xref.Part4.10">8.3.5</a>, <a href="#rfc.xref.Part4.11">8.4.13</a>, <a href="#Part4"><b>13.1</b></a>, <a href="#rfc.xref.Part4.12">C.2</a><ul> 3258 <li><em>Section 2. 2</em> <a href="#rfc.xref.Part4.8">5</a>, <a href="#rfc.xref.Part4.9">8.2.2</a></li>3258 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.8">5</a>, <a href="#rfc.xref.Part4.9">8.2.2</a></li> 3259 3259 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3</a></li> 3260 3260 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.3">3</a></li> -
draft-ietf-httpbis/latest/p3-payload.html
r1373 r1391 359 359 } 360 360 @bottom-center { 361 content: "Expires February 4, 2012";361 content: "Expires February 9, 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-08-0 3">410 <meta name="dct.issued" scheme="ISO8601" content="2011-08-08"> 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: February 4, 2012</td>436 <td class="left">Expires: February 9, 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">August 3, 2011</td>493 <td class="right">August 8, 2011</td> 494 494 </tr> 495 495 </tbody> … … 519 519 in progress”. 520 520 </p> 521 <p>This Internet-Draft will expire on February 4, 2012.</p>521 <p>This Internet-Draft will expire on February 9, 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> … … 912 912 <tr> 913 913 <td class="left">Last-Modified</td> 914 <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2. 1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>914 <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> 915 915 </tr> 916 916 </tbody> … … 2147 2147 </li> 2148 2148 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">4.1</a>, <a href="#Part4"><b>10.1</b></a><ul> 2149 <li><em>Section 2. 1</em> <a href="#rfc.xref.Part4.1">4.1</a></li>2149 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">4.1</a></li> 2150 2150 </ul> 2151 2151 </li> -
draft-ietf-httpbis/latest/p4-conditional.html
r1381 r1391 359 359 } 360 360 @bottom-center { 361 content: "Expires February 6, 2012";361 content: "Expires February 9, 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-08-0 5">406 <meta name="dct.issued" scheme="ISO8601" content="2011-08-08"> 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: February 6, 2012</td>432 <td class="left">Expires: February 9, 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">August 5, 2011</td>489 <td class="right">August 8, 2011</td> 490 490 </tr> 491 491 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on February 6, 2012.</p>519 <p>This Internet-Draft will expire on February 9, 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/p5-range.html
r1383 r1391 359 359 } 360 360 @bottom-center { 361 content: "Expires February 7, 2012";361 content: "Expires February 9, 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-08-0 6">408 <meta name="dct.issued" scheme="ISO8601" content="2011-08-08"> 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: February 7, 2012</td>434 <td class="left">Expires: February 9, 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">August 6, 2011</td>491 <td class="right">August 8, 2011</td> 492 492 </tr> 493 493 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on February 7, 2012.</p>519 <p>This Internet-Draft will expire on February 9, 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/p6-cache.html
r1376 r1391 362 362 } 363 363 @bottom-center { 364 content: "Expires February 5, 2012";364 content: "Expires February 9, 2012"; 365 365 } 366 366 @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-p6-cache-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-08-0 4">410 <meta name="dct.issued" scheme="ISO8601" content="2011-08-08"> 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 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: February 5, 2012</td>436 <td class="left">Expires: February 9, 2012</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">August 4, 2011</td>497 <td class="right">August 8, 2011</td> 498 498 </tr> 499 499 </tbody> … … 525 525 in progress”. 526 526 </p> 527 <p>This Internet-Draft will expire on February 5, 2012.</p>527 <p>This Internet-Draft will expire on February 9, 2012.</p> 528 528 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 529 529 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 710 710 <ul class="empty"> 711 711 <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response is an 712 equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2. 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.712 equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 713 713 </li> 714 714 </ul> … … 717 717 <ul class="empty"> 718 718 <li>A validator that is defined by the origin server such that its current value will change if the representation body changes; 719 i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2. 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.1.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.719 i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 720 720 </li> 721 721 </ul> … … 898 898 is not already present. 899 899 </p> 900 <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2. 1</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), a cache <em class="bcp14">SHOULD NOT</em> use a heuristic expiration value that is more than some fraction of the interval since that time. A typical setting of this900 <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), a cache <em class="bcp14">SHOULD NOT</em> use a heuristic expiration value that is more than some fraction of the interval since that time. A typical setting of this 901 901 fraction might be 10%. 902 902 </p> … … 963 963 <div id="rfc.figure.u.7"></div><pre class="text"> resident_time = now - response_time; 964 964 current_age = corrected_initial_age + resident_time; 965 </pre><h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3> 965 </pre><p id="rfc.section.2.3.2.p.13">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> 966 <p id="rfc.section.2.3.2.p.14"> </p> 967 <ul> 968 <li>HTTP/1.1 clients and caches <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve 969 the "year 2000" problem). 970 </li> 971 <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. 972 </li> 973 <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed Expires date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value. 974 </li> 975 <li>All expiration-related calculations <em class="bcp14">MUST</em> be done in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time. 976 </li> 977 <li>If an HTTP header field incorrectly carries a date value with a time zone other than GMT, it <em class="bcp14">MUST</em> be converted into GMT using the most conservative possible conversion. 978 </li> 979 </ul> 980 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3> 966 981 <p id="rfc.section.2.3.3.p.1">A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but 967 982 is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section 2.3</a>. … … 2178 2193 </li> 2179 2194 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1.2</a>, <a href="#rfc.xref.Part4.2">1.2</a>, <a href="#rfc.xref.Part4.3">1.2</a>, <a href="#rfc.xref.Part4.4">2.3.1.1</a>, <a href="#rfc.xref.Part4.5">2.4</a>, <a href="#Part4"><b>8.1</b></a><ul> 2180 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4. 4">2.3.1.1</a></li>2181 <li><em>Section 2. 1.2</em> <a href="#rfc.xref.Part4.3">1.2</a></li>2182 <li><em>Section 2.2 </em> <a href="#rfc.xref.Part4.2">1.2</a></li>2183 <li><em>Section 2. 2.2</em> <a href="#rfc.xref.Part4.1">1.2</a></li>2195 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.1">1.2</a></li> 2196 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.4">2.3.1.1</a></li> 2197 <li><em>Section 2.2.2</em> <a href="#rfc.xref.Part4.3">1.2</a></li> 2198 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.2">1.2</a></li> 2184 2199 </ul> 2185 2200 </li>
Note: See TracChangeset
for help on using the changeset viewer.
