Changeset 2556
- Timestamp:
- 18/01/14 01:43:52 (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2554 r2556 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 1628 1628 and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel 1629 is closed. 1630 </p> 1631 <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. 1632 </p> 1633 <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. 1634 </p> 1635 <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. 1629 is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then 1630 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>). 1631 </p> 1632 <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. 1633 </p> 1634 <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. 1636 1635 For example, 1637 1636 </p> … … 1639 1638 Host: server.example.com:80 1640 1639 1641 </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 another1640 </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 1642 1641 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 1643 1642 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. 1646 1645 </p> 1647 <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 discard1646 <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 1648 1647 any remaining data left undelivered. 1649 1648 </p> 1650 <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>1649 <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> 1651 1650 <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1652 1651 Host: server.example.com:80 1653 1652 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1654 1653 1655 </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-known1654 </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 1656 1655 or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25" 1657 1656 would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying 1658 1657 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. 1659 1658 </p> 1660 <p id="rfc.section.4.3.6.p.1 1">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.1661 </p> 1662 <p id="rfc.section.4.3.6.p.1 2">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause1659 <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. 1660 </p> 1661 <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 1663 1662 some existing implementations to reject the request. 1664 1663 </p> 1665 <p id="rfc.section.4.3.6.p.1 3">Responses to the CONNECT method are not cacheable.</p>1664 <p id="rfc.section.4.3.6.p.12">Responses to the CONNECT method are not cacheable.</p> 1666 1665 </div> 1667 1666 <div id="OPTIONS"> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2554 r2556 1618 1618 successful, thereafter restrict its behavior to blind forwarding of 1619 1619 packets, in both directions, until the tunnel is closed. 1620 </t> 1621 <t> 1622 A common use for CONNECT is establishing a tunnel through a proxy for a 1623 TLS (Transport Layer Security, <xref target="RFC5246"/>) connection. 1620 Tunnels are commonly used to create an end-to-end virtual connection, 1621 through one or more proxies, which can then be secured using TLS 1622 (Transport Layer Security, <xref target="RFC5246"/>). 1624 1623 </t> 1625 1624 <t>
Note: See TracChangeset
for help on using the changeset viewer.