![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 970
- Timestamp:
- Jul 31, 2010, 1:54:31 AM (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
-
p1-messaging.html (modified) (16 diffs)
-
p2-semantics.html (modified) (11 diffs)
-
p3-payload.html (modified) (9 diffs)
-
p4-conditional.html (modified) (8 diffs)
-
p5-range.html (modified) (8 diffs)
-
p6-cache.html (modified) (9 diffs)
-
p7-auth.html (modified) (6 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r968 r970 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 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 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: January 31, 2011</td>437 <td class="left">Expires: February 1, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">July 3 0, 2010</td>490 <td class="right">July 31, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire in January 31, 2011.</p>518 <p>This Internet-Draft will expire in February 1, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 724 724 <p id="rfc.section.1.p.4">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, 725 725 we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of 726 recipients. If the communication is considered in isolation, then successful actions shouldbe reflected in corresponding726 recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding 727 727 changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps 728 728 at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. … … 1144 1144 <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> 1145 1145 <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 1146 stream at the beginning of a message and receives a CRLF first, it shouldignore the CRLF.1146 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. 1147 1147 </p> 1148 1148 <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations generate an extra CRLF after a POST request as a lame workaround for some early server … … 1249 1249 <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding 1250 1250 overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of 1251 security-related checks on message routing or content) and thus shouldbe handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding1251 security-related checks on message routing or content) and thus ought to be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding 1252 1252 is decoded. 1253 1253 </p> … … 1379 1379 <div class="note" id="rfc.section.4.1.2.p.18"> 1380 1380 <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1381 a non-reserved URI character for a reserved purpose. Implementors shouldbe aware that some pre-HTTP/1.1 proxies have been1381 a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been 1382 1382 known to rewrite the request-target. 1383 1383 </p> … … 2222 2222 <h3 id="rfc.section.9.8.1"><a href="#rfc.section.9.8.1">9.8.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3> 2223 2223 <p id="rfc.section.9.8.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header 2224 field. Each registered token should be associated with one or a set of specifications, and with contact information. 2225 </p> 2226 <p id="rfc.section.9.8.1.p.2">Registrations should be 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>. These specifications need not be IETF documents or be subject to IESG review, but should obey the following rules: 2224 field. Each registered token is associated with contact information and an optional set of specifications that details how 2225 the connection will be processed after it has been upgraded. 2226 </p> 2227 <p id="rfc.section.9.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: 2227 2228 </p> 2228 2229 <ol> … … 2232 2233 <li>The registration <em class="bcp14">MUST</em> name a point of contact. 2233 2234 </li> 2234 <li>The registration <em class="bcp14">MAY</em> name the documentation required for the token.2235 <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available. 2235 2236 </li> 2236 2237 <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. … … 2241 2242 </li> 2242 2243 </ol> 2243 <p id="rfc.section.9.8.1.p.3">It is not required that specifications for upgrade tokens be made publicly available, but the contact information for the2244 registration should be.2245 </p>2246 2244 <div id="rfc.iref.v.1"></div> 2247 2245 <div id="rfc.iref.h.15"></div> … … 2290 2288 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2291 2289 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2292 <p id="rfc.section.10.1.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):2290 <p id="rfc.section.10.1.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 2293 2291 </p> 2294 2292 <div id="rfc.table.1"> … … 2372 2370 <p id="rfc.section.10.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2373 2371 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> 2374 <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> sh ouldbe updated to point to Sections <a href="#http.uri" title="http URI scheme">2.6.1</a> and <a href="#https.uri" title="https URI scheme">2.6.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).2372 <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.6.1</a> and <a href="#https.uri" title="https URI scheme">2.6.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>). 2375 2373 </p> 2376 2374 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2> … … 2491 2489 <p id="rfc.section.10.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 6.2.3</a> of this document. 2492 2490 </p> 2493 <p id="rfc.section.10.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>> sh ouldbe updated with the registrations below:2491 <p id="rfc.section.10.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: 2494 2492 </p> 2495 2493 <div id="rfc.table.2"> … … 2535 2533 <p id="rfc.section.10.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.1"><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 9.8.1</a> of this document. 2536 2534 </p> 2537 <p id="rfc.section.10.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>> sh ouldbe updated with the registration below:2535 <p id="rfc.section.10.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: 2538 2536 </p> 2539 2537 <div id="rfc.table.u.1"> … … 2607 2605 might be used in the commission of a wide range of potential attacks. 2608 2606 </p> 2609 <p id="rfc.section.11.5.p.2">Proxy operators shouldprotect the systems on which proxies run as they would protect any system that contains or transports2607 <p id="rfc.section.11.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports 2610 2608 sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, 2611 and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use should2612 be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section 11.2</a>).2613 </p> 2614 <p id="rfc.section.11.5.p.3">Proxy implementors shouldconsider the privacy and security implications of their design and coding decisions, and of the2609 and/or information about organizations. Log information needs to be carefully guarded, and appropriate guidelines for use 2610 need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section 11.2</a>). 2611 </p> 2612 <p id="rfc.section.11.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the 2615 2613 configuration options they provide to proxy operators (especially the default configuration). 2616 2614 </p> -
draft-ietf-httpbis/latest/p2-semantics.html
r968 r970 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <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 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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: January 31, 2011</td>436 <td class="left">Expires: February 1, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">July 3 0, 2010</td>489 <td class="right">July 31, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in January 31, 2011.</p>516 <p>This Internet-Draft will expire in February 1, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 938 938 <div id="rfc.iref.s.1"></div> 939 939 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 940 <p id="rfc.section.7.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be 941 careful to allow the user to be aware of any actions they take which might have an unexpected significance to themselves or 942 others. 940 <p id="rfc.section.7.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow 941 the user to be aware of any actions they take which might have an unexpected significance to themselves or others. 943 942 </p> 944 943 <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is … … 1225 1224 </p> 1226 1225 <div class="note" id="rfc.section.8.3.p.2"> 1227 <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers should be aware that there might be clients that implement such a fixed limitation.1226 <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation. 1228 1227 </p> 1229 1228 </div> … … 1635 1634 <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc. 1636 1635 It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 1637 where they allow links from (so-called "deep linking"), but it should be noted that legitimate requests are not required to 1638 contain a Referer header field. 1636 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 1639 1637 </p> 1640 1638 <p id="rfc.section.9.6.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), … … 1705 1703 <p id="rfc.section.10.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section 2.1</a> of this document. 1706 1704 </p> 1707 <p id="rfc.section.10.1.p.2">The HTTP Method Registry sh ouldbe created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below:1705 <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: 1708 1706 </p> 1709 1707 <div id="rfc.table.1"> … … 1772 1770 <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</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="#status.code.registry" title="Status Code Registry">Section 4.1</a> of this document. 1773 1771 </p> 1774 <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> sh ouldbe updated with the registrations below:1772 <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 1775 1773 </p> 1776 1774 <div id="rfc.table.2"> … … 2005 2003 </div> 2006 2004 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2007 <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):2005 <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 2008 2006 </p> 2009 2007 <div id="rfc.table.3"> … … 2128 2126 <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 2129 2127 </p> 2130 <p id="rfc.section.11.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded2131 in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it2132 might be visible to third parties.Such services can use POST-based form submission instead.2128 <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing 2129 servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. 2130 Such services can use POST-based form submission instead. 2133 2131 </p> 2134 2132 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2> -
draft-ietf-httpbis/latest/p3-payload.html
r968 r970 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <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 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."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: January 31, 2011</td>430 <td class="left">Expires: February 1, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 485 485 <tr> 486 486 <td class="left"></td> 487 <td class="right">July 3 0, 2010</td>487 <td class="right">July 31, 2010</td> 488 488 </tr> 489 489 </tbody> … … 511 511 in progress”. 512 512 </p> 513 <p>This Internet-Draft will expire in January 31, 2011.</p>513 <p>This Internet-Draft will expire in February 1, 2011.</p> 514 514 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 515 515 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 715 715 of the charset parameter can be quoted. 716 716 </p> 717 <p id="rfc.section.2.1.p.8">Implementors shouldbe aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.717 <p id="rfc.section.2.1.p.8">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>. 718 718 </p> 719 719 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="missing.charset" href="#missing.charset">Missing Charset</a></h3> … … 1206 1206 <div class="note" id="rfc.section.6.4.p.10"> 1207 1207 <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 1208 familiar with the details of language matching as described above, and should provideappropriate guidance. As an example,1208 familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example, 1209 1209 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 1210 1210 A user agent might suggest in such a case to add "en" to get the best matching behavior. … … 1355 1355 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1356 1356 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1357 <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1357 <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 1358 1358 </p> 1359 1359 <div id="rfc.table.1"> … … 1453 1453 <p id="rfc.section.7.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section 2.2.1</a> of this document. 1454 1454 </p> 1455 <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> sh ouldbe updated with the registration below:1455 <p id="rfc.section.7.2.p.2">The HTTP Content 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 registration below: 1456 1456 </p> 1457 1457 <div id="rfc.table.2"> … … 1744 1744 CR and LF, as is the case for some multi-byte character sets. 1745 1745 </p> 1746 <p id="rfc.section.A.2.p.3">Implementors should note that conversion will break any cryptographic checksums applied to the original content unless the 1747 original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such 1748 checksums in HTTP. 1746 <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in 1747 canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP. 1749 1748 </p> 1750 1749 <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> -
draft-ietf-httpbis/latest/p4-conditional.html
r968 r970 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <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 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."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: January 31, 2011</td>428 <td class="left">Expires: February 1, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">July 3 0, 2010</td>485 <td class="right">July 31, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 31, 2011.</p>511 <p>This Internet-Draft will expire in February 1, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 881 881 </p> 882 882 <ul class="empty"> 883 <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients shouldtransmit as much non-redundant information883 <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients ought to transmit as much non-redundant information 884 884 as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative 885 885 assumptions about the validators they receive. … … 989 989 </li> 990 990 <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for 991 the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time.992 The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the993 client and server. This includes the possibility of race conditions if the document has changed between the time it was first994 requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the995 If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different996 time bases between client andserver are at best approximate due to network latency.991 the same request, the client needs to be aware that this date is interpreted in the server's understanding of time. Unsynchronized 992 clocks and rounding problems, due to the different encodings of time between the client and server, are concerns. This includes 993 the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since 994 date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived 995 from the client's clock without correction to the server's clock. Corrections for different time bases between client and 996 server are at best approximate due to network latency. 997 997 </li> 998 998 </ul> … … 1086 1086 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1087 1087 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 1088 <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> sh ouldbe updated with the registrations below:1088 <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 1089 1089 </p> 1090 1090 <div id="rfc.table.1"> … … 1115 1115 </div> 1116 1116 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1117 <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1117 <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 1118 1118 </p> 1119 1119 <div id="rfc.table.2"> -
draft-ietf-httpbis/latest/p5-range.html
r968 r970 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <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 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."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: January 31, 2011</td>428 <td class="left">Expires: February 1, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">July 3 0, 2010</td>485 <td class="right">July 31, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 31, 2011.</p>511 <p>This Internet-Draft will expire in February 1, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 730 730 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.content-range" href="#header.content-range">Content-Range</a></h2> 731 731 <p id="rfc.section.5.2.p.1">The "Content-Range" header field is sent with a partial representation to specify where in the full representation the payload 732 body shouldbe applied.732 body is intended to be applied. 733 733 </p> 734 734 <p id="rfc.section.5.2.p.2">Range units are defined in <a href="#range.units" title="Range Units">Section 2</a>. … … 916 916 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 917 917 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 918 <p id="rfc.section.6.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> sh ouldbe updated with the registrations below:918 <p id="rfc.section.6.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 919 919 </p> 920 920 <div id="rfc.table.1"> … … 945 945 </div> 946 946 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 947 <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):947 <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 948 948 </p> 949 949 <div id="rfc.table.2"> … … 994 994 <p id="rfc.section.6.3.p.1">The registration procedure for HTTP Range Specifiers is defined by <a href="#range.specifier.registry" title="Range Specifier Registry">Section 2.1</a> of this document. 995 995 </p> 996 <p id="rfc.section.6.3.p.2">The HTTP Range Specifier Registry sh ouldbe created at <<a href="http://www.iana.org/assignments/http-range-specifiers">http://www.iana.org/assignments/http-range-specifiers</a>> and be populated with the registrations below:996 <p id="rfc.section.6.3.p.2">The HTTP Range Specifier Registry shall be created at <<a href="http://www.iana.org/assignments/http-range-specifiers">http://www.iana.org/assignments/http-range-specifiers</a>> and be populated with the registrations below: 997 997 </p> 998 998 <div id="rfc.table.3"> -
draft-ietf-httpbis/latest/p6-cache.html
r968 r970 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. 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."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: January 31, 2011</td>430 <td class="left">Expires: February 1, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">July 3 0, 2010</td>491 <td class="right">July 31, 2010</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire in January 31, 2011.</p>517 <p>This Internet-Draft will expire in February 1, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 641 641 </p> 642 642 <ul class="empty"> 643 <li>The time at which the origin server intends that a representation should no longer be returned by a cache without further 644 validation. 645 </li> 643 <li>The time at which the origin server intends that a representation no longer be returned by a cache without further validation.</li> 646 644 </ul> 647 645 <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> … … 798 796 is not likely to change in a semantically significant way before the expiration time is reached. 799 797 </p> 800 <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past. 801 This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="TODO-response-stale">[<a href="#TODO-response-stale" class="smpl">TODO-response-stale</a>: This wording might cause confusion, because the response might still be served stale.]</span> 798 <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past 799 to indicate that the response is already stale. Compliant caches will validate the cached response before reusing it for subsequent 800 requests. 802 801 </p> 803 802 <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other header values … … 1422 1421 <p id="rfc.section.5.1.p.1">The registration procedure for HTTP Cache Directives is defined by <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.3</a> of this document. 1423 1422 </p> 1424 <p id="rfc.section.5.1.p.2">The HTTP Cache Directive Registry sh ouldbe created at <<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>> and be populated with the registrations below:1423 <p id="rfc.section.5.1.p.2">The HTTP Cache Directive Registry shall be created at <<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>> and be populated with the registrations below: 1425 1424 </p> 1426 1425 <div id="rfc.table.1"> … … 1508 1507 </div> 1509 1508 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1510 <p id="rfc.section.5.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1509 <p id="rfc.section.5.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 1511 1510 </p> 1512 1511 <div id="rfc.table.2"> … … 1571 1570 <p id="rfc.section.6.p.1">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious 1572 1571 exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information 1573 long after a user believes that the information has been removed from the network. Therefore, cache contents shouldbe protected1572 long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected 1574 1573 as sensitive information. 1575 1574 </p> -
draft-ietf-httpbis/latest/p7-auth.html
r968 r970 393 393 <meta name="dct.creator" content="Reschke, J. F."> 394 394 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 395 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">395 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 396 396 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 397 397 <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 HTTP Authentication."> … … 424 424 </tr> 425 425 <tr> 426 <td class="left">Expires: January 31, 2011</td>426 <td class="left">Expires: February 1, 2011</td> 427 427 <td class="right">HP</td> 428 428 </tr> … … 477 477 <tr> 478 478 <td class="left"></td> 479 <td class="right">July 3 0, 2010</td>479 <td class="right">July 31, 2010</td> 480 480 </tr> 481 481 </tbody> … … 503 503 in progress”. 504 504 </p> 505 <p>This Internet-Draft will expire in January 31, 2011.</p>505 <p>This Internet-Draft will expire in February 1, 2011.</p> 506 506 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 507 507 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 693 693 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 694 694 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 695 <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> sh ouldbe updated with the registrations below:695 <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 696 696 </p> 697 697 <div id="rfc.table.1"> … … 722 722 </div> 723 723 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 724 <p id="rfc.section.4.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):724 <p id="rfc.section.4.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 725 725 </p> 726 726 <div id="rfc.table.2">
Note: See TracChangeset
for help on using the changeset viewer.
