Changeset 2556

Timestamp:

18/01/14 01:43:52 (7 years ago)

Author:

fielding@…

Message:

(editorial) clarify that TLS occurs after the tunnel [2542]; see #532

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (3 diffs)
• p2-semantics.xml (modified) (1 diff)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1627 +1627 @@
                <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target
                   and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel
-                  is closed.
-               </p>
-               <p id="rfc.section.4.3.6.p.2">A common use for CONNECT is establishing a tunnel through a proxy for a TLS (Transport Layer Security, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) connection.
-               </p>
-               <p id="rfc.section.4.3.6.p.3">CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
-               </p>
-               <p id="rfc.section.4.3.6.p.4">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
+                  is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then
+                  be secured using TLS (Transport Layer Security, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>).
+               </p>
+               <p id="rfc.section.4.3.6.p.2">CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
+               </p>
+               <p id="rfc.section.4.3.6.p.3">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
                   For example,
                </p>
@@ -1639 +1638 @@
 Host: server.example.com:80
 
-</pre><p id="rfc.section.4.3.6.p.6">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another
+</pre><p id="rfc.section.4.3.6.p.5">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another
                   proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that
                   concludes the successful response's header section; data received after that blank line is from the server identified by the
@@ -1645 +1644 @@
                   connection remains governed by HTTP.
                </p>
-               <p id="rfc.section.4.3.6.p.7">A tunnel is closed when a tunnel intermediary detects that either side has closed its connection: the intermediary <em class="bcp14">MUST</em> attempt to send any outstanding data that came from the closed side to the other side, close both connections, and then discard
+               <p id="rfc.section.4.3.6.p.6">A tunnel is closed when a tunnel intermediary detects that either side has closed its connection: the intermediary <em class="bcp14">MUST</em> attempt to send any outstanding data that came from the closed side to the other side, close both connections, and then discard
                   any remaining data left undelivered.
                </p>
-               <p id="rfc.section.4.3.6.p.8">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p>
+               <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p>
                <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=
 
-</pre><p id="rfc.section.4.3.6.p.10">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known
+</pre><p id="rfc.section.4.3.6.p.9">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known
                   or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25"
                   would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying
                   spam email. Proxies that support CONNECT <em class="bcp14">SHOULD</em> restrict its use to a limited set of known ports or a configurable whitelist of safe request targets.
                </p>
-               <p id="rfc.section.4.3.6.p.11">A server <em class="bcp14">MUST NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to CONNECT. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.
-               </p>
-               <p id="rfc.section.4.3.6.p.12">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
+               <p id="rfc.section.4.3.6.p.10">A server <em class="bcp14">MUST NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to CONNECT. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.
+               </p>
+               <p id="rfc.section.4.3.6.p.11">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
                   some existing implementations to reject the request.
                </p>
-               <p id="rfc.section.4.3.6.p.13">Responses to the CONNECT method are not cacheable.</p>
+               <p id="rfc.section.4.3.6.p.12">Responses to the CONNECT method are not cacheable.</p>
             </div>
             <div id="OPTIONS">

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -1618 +1618 @@
    successful, thereafter restrict its behavior to blind forwarding of
    packets, in both directions, until the tunnel is closed.
-</t>
-<t>
-   A common use for CONNECT is establishing a tunnel through a proxy for a
-   TLS (Transport Layer Security, <xref target="RFC5246"/>) connection.
+   Tunnels are commonly used to create an end-to-end virtual connection,
+   through one or more proxies, which can then be secured using TLS
+   (Transport Layer Security, <xref target="RFC5246"/>).
 </t>
 <t>