Ignore:
Timestamp:
Sep 9, 2012, 7:46:17 PM (7 years ago)
Author:
fielding@…
Message:

Be more consistent regarding targeting conformance requirements.
Only define conformance criteria once, but repeat required nits.

Remove antiquated requirement about media type parameters not being
recognized by 1993-era browsers.

Add reference to TLS in p1.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1874 r1875  
    898898         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
    899899         are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
    900          different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
     900         different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
    901901         for the sake of security, annotation services, or shared caching.
    902902      </p>
     
    921921         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    922922         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    923          when transport-layer security is used to establish confidential communication through a shared firewall proxy.
     923         when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy.
    924924      </p>
    925925      <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span>  <span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
     
    961961      <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    962962         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    963          or caches, depending on what behavior is being constrained by the requirement.
     963         or caches, depending on what behavior is being constrained by the requirement. Additional (social) requirements are placed
     964         on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.
    964965      </p>
    965966      <p id="rfc.section.2.5.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     
    11581159      </p>
    11591160      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#http.message" class="smpl">start-line</a>     = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a>
    1160 </pre><p id="rfc.section.3.1.p.3">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
     1161</pre><p id="rfc.section.3.1.p.3">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
    11611162         attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
    11621163         result in a security vulnerability if other implementations within the request chain interpret the same message differently.
     
    14731474      </ol>
    14741475      <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
    1475          by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
     1476         by network failure, a server <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
    14761477         with HTTP/1.0.
    14771478      </p>
     
    21382139      </p>
    21392140      <p id="rfc.section.6.3.p.6">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    2140          and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
     2141         and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol chosen,
    21412142         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field.
    21422143      </p>
     
    21492150         that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request.
    21502151      </p>
    2151       <p id="rfc.section.6.3.p.9">The Upgrade header field only applies to switching application-layer protocols on the existing transport-layer connection;
    2152          it cannot be used to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2152      <p id="rfc.section.6.3.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used
     2153         to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    21532154      </p>
    21542155      <p id="rfc.section.6.3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     
    25332534      </p>
    25342535      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
    2535       <p id="rfc.section.8.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
     2536      <p id="rfc.section.8.3.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
    25362537         If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft
    25372538         Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    25382539         such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the request-target if it would otherwise allow access to a resource outside those intended
    25392540         to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access
    2540          control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor
    2541          bugs in such HTTP server implementations have turned into security risks.
     2541         control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information.
    25422542      </p>
    25432543      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
     
    25692569      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    25702570      </p>
    2571       <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
     2571      <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
     2572         phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
    25722573      </p>
    25732574      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     
    26772678      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    26782679      </h2>
    2679       <table>                                           
     2680      <table>                                             
    26802681         <tr>
    26812682            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
     
    27702771            <td class="reference"><b id="RFC5226">[RFC5226]</b></td>
    27712772            <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008.
     2773            </td>
     2774         </tr>
     2775         <tr>
     2776            <td class="reference"><b id="RFC5246">[RFC5246]</b></td>
     2777            <td class="top">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>”, RFC&nbsp;5246, August&nbsp;2008.
    27722778            </td>
    27732779         </tr>
     
    37513757                     </ul>
    37523758                  </li>
     3759                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#RFC5246"><b>10.2</b></a></li>
    37533760                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
    37543761                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.7</a></li>
Note: See TracChangeset for help on using the changeset viewer.