Ignore:
Timestamp:
08/01/14 11:11:48 (7 years ago)
Author:
julian.reschke@…
Message:

Mention TLS in the context of CONNECT (see #532)

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2541 r2542  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 11, 2014";
     450       content: "Expires July 12, 2014";
    451451  }
    452452  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2014-01-07">
     495      <meta name="dct.issued" scheme="ISO8601" content="2014-01-08">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    521521            <tr>
    522522               <td class="left">Intended status: Standards Track</td>
    523                <td class="right">January 7, 2014</td>
     523               <td class="right">January 8, 2014</td>
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 11, 2014</td>
     526               <td class="left">Expires: July 12, 2014</td>
    527527               <td class="right"></td>
    528528            </tr>
     
    553553            in progress”.
    554554         </p>
    555          <p>This Internet-Draft will expire on July 11, 2014.</p>
     555         <p>This Internet-Draft will expire on July 12, 2014.</p>
    556556      </div>
    557557      <div id="rfc.copyrightnotice">
     
    16291629                  is closed.
    16301630               </p>
    1631                <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.
    1632                </p>
    1633                <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.
     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.
    16341636                  For example,
    16351637               </p>
     
    16371639Host: server.example.com:80
    16381640
    1639 </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
     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 another
    16401642                  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
    16411643                  concludes the successful response's header section; data received after that blank line is from the server identified by the
     
    16431645                  connection remains governed by HTTP.
    16441646               </p>
    1645                <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
     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 discard
    16461648                  any remaining data left undelivered.
    16471649               </p>
    1648                <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>
     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>
    16491651               <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    16501652Host: server.example.com:80
    16511653Proxy-Authorization: basic aGVsbG86d29ybGQ=
    16521654
    1653 </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
     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-known
    16541656                  or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25"
    16551657                  would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying
    16561658                  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.
    16571659               </p>
    1658                <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.
    1659                </p>
    1660                <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
     1660               <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.
     1661               </p>
     1662               <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
    16611663                  some existing implementations to reject the request.
    16621664               </p>
    1663                <p id="rfc.section.4.3.6.p.12">Responses to the CONNECT method are not cacheable.</p>
     1665               <p id="rfc.section.4.3.6.p.13">Responses to the CONNECT method are not cacheable.</p>
    16641666            </div>
    16651667            <div id="OPTIONS">
     
    43784380            <td class="reference"><b id="RFC5226">[RFC5226]</b></td>
    43794381            <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.
     4382            </td>
     4383         </tr>
     4384         <tr>
     4385            <td class="reference"><b id="RFC5246">[RFC5246]</b></td>
     4386            <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.
    43804387            </td>
    43814388         </tr>
     
    50945101                     </ul>
    50955102                  </li>
     5103                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">4.3.6</a>, <a href="#RFC5246"><b>11.2</b></a></li>
    50965104                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.6">7.1.1.2</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.7">A</a><ul>
    50975105                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a></li>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2541 r2542  
    16201620</t>
    16211621<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.
     1624</t>
     1625<t>
    16221626   CONNECT is intended only for use in requests to a proxy.
    16231627   An origin server that receives a CONNECT request for itself &MAY;
     
    56275631</reference>
    56285632
     5633<reference anchor='RFC5246'>
     5634   <front>
     5635      <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
     5636      <author initials='T.' surname='Dierks' fullname='T. Dierks'/>
     5637      <author initials='E.' surname='Rescorla' fullname='E. Rescorla'/>
     5638      <date year='2008' month='August' />
     5639   </front>
     5640   <seriesInfo name='RFC' value='5246' />
     5641</reference>
     5642
    56295643<reference anchor="RFC5322">
    56305644  <front>
Note: See TracChangeset for help on using the changeset viewer.