Changeset 970 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 31/07/10 08:54:31 (10 years ago)
- File:
-
- 1 edited
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>
Note: See TracChangeset
for help on using the changeset viewer.