Changeset 1875 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 10/09/12 02:46:17 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1874 r1875 898 898 for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations 899 899 are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely 900 different application-l ayerprotocols. Proxies are often used to group an organization's HTTP requests through a common intermediary900 different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary 901 901 for the sake of security, annotation services, or shared caching. 902 902 </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 922 922 ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 923 when transport-layer securityis 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. 924 924 </p> 925 925 <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 962 962 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. 964 965 </p> 965 966 <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> 1159 1160 <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 an1161 </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 1161 1162 attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might 1162 1163 result in a security vulnerability if other implementations within the request chain interpret the same message differently. … … 1473 1474 </ol> 1474 1475 <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 compatibility1476 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 1476 1477 with HTTP/1.0. 1477 1478 </p> … … 2138 2139 </p> 2139 2140 <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-l ayercommunication 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, 2141 2142 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. 2142 2143 </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. 2150 2151 </p> 2151 <p id="rfc.section.6.3.p.9">The Upgrade header field only applies to switching application-l ayer protocols on the existing transport-layer connection;2152 it cannot be usedto 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>). 2153 2154 </p> 2154 2155 <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> 2534 2535 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <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. 2536 2537 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 2537 2538 Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On 2538 2539 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 2539 2540 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. 2542 2542 </p> 2543 2543 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <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>). 2570 2570 </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. 2572 2573 </p> 2573 2574 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <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 2678 2679 </h2> 2679 <table> 2680 <table> 2680 2681 <tr> 2681 2682 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> … … 2770 2771 <td class="reference"><b id="RFC5226">[RFC5226]</b></td> 2771 2772 <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 26, RFC 5226, May 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 5246, August 2008. 2772 2778 </td> 2773 2779 </tr> … … 3751 3757 </ul> 3752 3758 </li> 3759 <li><em>RFC5246</em> <a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#RFC5246"><b>10.2</b></a></li> 3753 3760 <li><em>RFC5322</em> <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> 3754 3761 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">5.7</a></li>
Note: See TracChangeset
for help on using the changeset viewer.