Changeset 1875 for draft-ietf-httpbis/latest/p1-messaging.html

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:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (12 diffs)

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

@@ -898 +898 @@
          for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
          are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
-         different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
+         different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
          for the sake of security, annotation services, or shared caching.
       </p>
@@ -921 +921 @@
          to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
          ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
-         when transport-layer security is used to establish confidential communication through a shared firewall proxy.
+         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.
       </p>
       <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
@@ -961 +961 @@
       <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
          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
-         or caches, depending on what behavior is being constrained by the requirement.
+         or caches, depending on what behavior is being constrained by the requirement. Additional (social) requirements are placed
+         on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.
       </p>
       <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
@@ -1158 +1159 @@
       </p>
       <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>
-</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
+</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
          attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
          result in a security vulnerability if other implementations within the request chain interpret the same message differently.
@@ -1473 +1474 @@
       </ol>
       <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
-         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
+         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
          with HTTP/1.0.
       </p>
@@ -2138 +2139 @@
       </p>
       <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
-         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
+         and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol chosen,
          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.
       </p>
@@ -2149 +2150 @@
          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.
       </p>
-      <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;
-         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>).
+      <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
+         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>).
       </p>
       <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
@@ -2533 +2534 @@
       </p>
       <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>
-      <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.
+      <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.
          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
          Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
          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
          to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access
-         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
-         bugs in such HTTP server implementations have turned into security risks.
+         control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information.
       </p>
       <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>
@@ -2569 +2569 @@
       <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>).
       </p>
-      <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.
+      <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
+         phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
       </p>
       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
@@ -2677 +2678 @@
       <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
       </h2>
-      <table>                                            
+      <table>                                              
          <tr>
             <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
@@ -2770 +2771 @@
             <td class="reference"><b id="RFC5226">[RFC5226]</b></td>
             <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.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC5246">[RFC5246]</b></td>
+            <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.
             </td>
          </tr>
@@ -3751 +3757 @@
                      </ul>
                   </li>
+                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#RFC5246"><b>10.2</b></a></li>
                   <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>
                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.7</a></li>