Ignore:
Timestamp:
31/07/10 08:54:31 (11 years ago)
Author:
julian.reschke@…
Message:

regen HTML

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r968 r970  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: January 31, 2011</td>
     437               <td class="left">Expires: February 1, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">July 30, 2010</td>
     490               <td class="right">July 31, 2010</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </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>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    724724      <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,
    725725         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 should be reflected in corresponding
     726         recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding
    727727         changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps
    728728         at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
    … …  
    11441144      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    11451145      <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 should ignore the CRLF.
     1146         stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF.
    11471147      </p>
    11481148      <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
    … …  
    12491249            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
    12501250               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 should 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
     1251               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
    12521252               is decoded.
    12531253            </p>
    … …  
    13791379      <div class="note" id="rfc.section.4.1.2.p.18">
    13801380         <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 should be aware that some pre-HTTP/1.1 proxies have been
     1381            a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been
    13821382            known to rewrite the request-target.
    13831383         </p>
    … …  
    22222222      <h3 id="rfc.section.9.8.1"><a href="#rfc.section.9.8.1">9.8.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
    22232223      <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:
    22272228      </p>
    22282229      <ol>
    … …  
    22322233         <li>The registration <em class="bcp14">MUST</em> name a point of contact.
    22332234         </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.
    22352236         </li>
    22362237         <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.
    … …  
    22412242         </li>
    22422243      </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 the
    2244          registration should be.
    2245       </p>
    22462244      <div id="rfc.iref.v.1"></div>
    22472245      <div id="rfc.iref.h.15"></div>
    … …  
    22902288      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    22912289      <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<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 &lt;<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>&gt; should 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>):
     2290      <p id="rfc.section.10.1.p.1">The Message Header Field Registry located at &lt;<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>&gt; 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>):
    22932291      </p>
    22942292      <div id="rfc.table.1">
    … …  
    23722370      <p id="rfc.section.10.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    23732371      <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<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 &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; should 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>).
     2372      <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; 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>).
    23752373      </p>
    23762374      <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
    … …  
    24912489      <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&nbsp;6.2.3</a> of this document.
    24922490      </p>
    2493       <p id="rfc.section.10.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; should be updated with the registrations below:
     2491      <p id="rfc.section.10.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
    24942492      </p>
    24952493      <div id="rfc.table.2">
    … …  
    25352533      <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&nbsp;9.8.1</a> of this document.
    25362534      </p>
    2537       <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; should be updated with the registration below:
     2535      <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    25382536      </p>
    25392537      <div id="rfc.table.u.1">
    … …  
    26072605         might be used in the commission of a wide range of potential attacks.
    26082606      </p>
    2609       <p id="rfc.section.11.5.p.2">Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports
     2607      <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
    26102608         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 should
    2612          be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
    2613       </p>
    2614       <p id="rfc.section.11.5.p.3">Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the
     2609         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&nbsp;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
    26152613         configuration options they provide to proxy operators (especially the default configuration).
    26162614      </p>
Note: See TracChangeset for help on using the changeset viewer.