Ignore:
Timestamp:
27/10/10 00:13:12 (9 years ago)
Author:
mnot@…
Message:

Move CONNECT text from RFC2817; fixes #239.

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

Legend:

Unmodified
Added
Removed

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

    r1058 r1061  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-10-26">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-10-27">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: April 29, 2011</td>
     436               <td class="left">Expires: April 30, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">October 26, 2010</td>
     489               <td class="right">October 27, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire on April 29, 2011.</p>
     516      <p>This Internet-Draft will expire on April 30, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    574574               <li class="tocline1">7.7&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
    575575               <li class="tocline1">7.8&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
    576                <li class="tocline1">7.9&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
     576               <li class="tocline1">7.9&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a><ul class="toc">
     577                     <li class="tocline1">7.9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.9.1">Establishing a Tunnel with CONNECT</a></li>
     578                  </ul>
     579               </li>
    577580            </ul>
    578581         </li>
    … …  
    658661               <li class="tocline1">11.2&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
    659662               <li class="tocline1">11.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing">Location Headers and Spoofing</a></li>
     663               <li class="tocline1">11.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li>
    660664            </ul>
    661665         </li>
    … …  
    727731      <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p>
    728732      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
    729   <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    730   <a href="#abnf.dependencies" class="smpl">Host</a>          = &lt;Host, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
    731   <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
    732   <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
    733   <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a>&gt;
    734   <a href="#abnf.dependencies" class="smpl">TE</a>            = &lt;TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>&gt;
    735   <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
     733  authority     = &lt;authority, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
     734  <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
     735  <a href="#abnf.dependencies" class="smpl">Host</a>          = &lt;Host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
     736  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
     737  <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
     738  <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a>&gt;
     739  <a href="#abnf.dependencies" class="smpl">TE</a>            = &lt;TE, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>&gt;
     740  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
    736741</pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Accept</a>        = &lt;Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
    737742  <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> =
    … …  
    761766             &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>&gt;
    762767</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    763       <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     768      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    764769      </p>
    765770      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a>
    … …  
    801806         to a single application, so that this is clear.
    802807      </p>
    803       <p id="rfc.section.2.1.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message
     808      <p id="rfc.section.2.1.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message
    804809         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
    805810         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    … …  
    820825                 / <a href="#header.expect" class="smpl">Expect</a>                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.2</a>
    821826                 / <a href="#header.from" class="smpl">From</a>                     ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;9.3</a>
    822                  / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a>
     827                 / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a>
    823828                 / <a href="#abnf.dependencies" class="smpl">If-Match</a>                 ; <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a>
    824829                 / <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a>        ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a>
    … …  
    830835                 / <a href="#abnf.dependencies" class="smpl">Range</a>                    ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a>
    831836                 / <a href="#header.referer" class="smpl">Referer</a>                  ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;9.6</a>
    832                  / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>
     837                 / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>
    833838                 / <a href="#header.user-agent" class="smpl">User-Agent</a>               ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;9.9</a>
    834839</pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    … …  
    921926      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
    922927      <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
    923          Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     928         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    924929      </p>
    925930      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a>
    … …  
    942947         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    943948      </p>
    944       <p id="rfc.section.6.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
     949      <p id="rfc.section.6.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
    945950         to ensure safe and proper transfer of the message.
    946951      </p>
    … …  
    948953      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    949954      <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    950       <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     955      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    951956         rules are used (with the first applicable one being selected):
    952957      </p>
    … …  
    11311136      </p>
    11321137      <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1133          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     1138         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    11341139         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    11351140         infinite loop.
    11361141      </p>
    1137       <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1142      <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    11381143      </p>
    11391144      <div id="rfc.iref.c.1"></div>
    11401145      <div id="rfc.iref.m.8"></div>
    11411146      <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h2>
    1142       <p id="rfc.section.7.9.p.1">This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g.,
    1143          SSL tunneling <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>).
     1147      <p id="rfc.section.7.9.p.1">The CONNECT method is used with a proxy to dynamically switch the connection to a tunnel.</p>
     1148      <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> be an authority; i.e., the host name and port number destination of the requested connection separated by a colon:
     1149      </p>
     1150      <div id="rfc.figure.u.12"></div><pre class="text">    CONNECT server.example.com:80 HTTP/1.1
     1151    Host: server.example.com:80
     1152</pre><p id="rfc.section.7.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method -- except end-to-end protocol Upgrade requests, since the
     1153         tunnel must be established first.
     1154      </p>
     1155      <p id="rfc.section.7.9.p.5">For example, proxy authentication might be used to establish the authority to create a tunnel:</p>
     1156      <div id="rfc.figure.u.13"></div><pre class="text">    CONNECT server.example.com:80 HTTP/1.1
     1157    Host: server.example.com:80
     1158    Proxy-Authorization: basic aGVsbG86d29ybGQ=
     1159</pre><p id="rfc.section.7.9.p.7">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats
     1160         also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if
     1161         more than one TCP segment is outstanding.
     1162      </p>
     1163      <h3 id="rfc.section.7.9.1"><a href="#rfc.section.7.9.1">7.9.1</a>&nbsp;Establishing a Tunnel with CONNECT
     1164      </h3>
     1165      <p id="rfc.section.7.9.1.p.1">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested
     1166         host and port, and has switched to tunneling the current connection to that server connection.
     1167      </p>
     1168      <p id="rfc.section.7.9.1.p.2">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the
     1169         first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority.
     1170      </p>
     1171      <p id="rfc.section.7.9.1.p.3">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established.
     1172      </p>
     1173      <p id="rfc.section.7.9.1.p.4">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
     1174         the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
     1175         peer undelivered, that data will be discarded.
    11441176      </p>
    11451177      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="status.codes" href="#status.codes">Status Code Definitions</a></h1>
    … …  
    11621194      <p id="rfc.section.8.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    11631195         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    1164          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     1196         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    11651197      </p>
    11661198      <div id="rfc.iref.26"></div>
    11671199      <div id="rfc.iref.s.3"></div>
    11681200      <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    1169       <p id="rfc.section.8.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     1201      <p id="rfc.section.8.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    11701202         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    11711203      </p>
    … …  
    12471279         another input action.
    12481280      </p>
    1249       <p id="rfc.section.8.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1281      <p id="rfc.section.8.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    12501282      </p>
    12511283      <div id="rfc.iref.33"></div>
    … …  
    15541586      <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    15551587         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    1556          in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
     1588         in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
    15571589      </p>
    15581590      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    15641596         this field is strictly to inform the recipient of valid methods associated with the resource.
    15651597      </p>
    1566       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
     1598      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
    15671599  <a href="#header.allow" class="smpl">Allow-v</a> = #<a href="#method" class="smpl">Method</a>
    15681600</pre><p id="rfc.section.9.1.p.3">Example of use:</p>
    1569       <div id="rfc.figure.u.13"></div><pre class="text">  Allow: GET, HEAD, PUT
     1601      <div id="rfc.figure.u.15"></div><pre class="text">  Allow: GET, HEAD, PUT
    15701602</pre><p id="rfc.section.9.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
    15711603      <p id="rfc.section.9.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other
    … …  
    15761608      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
    15771609      <p id="rfc.section.9.2.p.1">The "Expect" request-header field is used to indicate that particular server behaviors are required by the client.</p>
    1578       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.expect" class="smpl">Expect</a>       = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a>
     1610      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.expect" class="smpl">Expect</a>       = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a>
    15791611  <a href="#header.expect" class="smpl">Expect-v</a>     = 1#<a href="#header.expect" class="smpl">expectation</a>
    15801612 
    … …  
    15961628      </p>
    15971629      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    1598       <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
     1630      <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
    15991631      </p>
    16001632      <div id="rfc.iref.f.1"></div>
    … …  
    16031635      <p id="rfc.section.9.3.p.1">The "From" request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
    16041636      </p>
    1605       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.from" class="smpl">From</a>    = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a>
     1637      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.from" class="smpl">From</a>    = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a>
    16061638  <a href="#header.from" class="smpl">From-v</a>  = <a href="#header.from" class="smpl">mailbox</a>
    16071639 
    16081640  <a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>&gt;
    16091641</pre><p id="rfc.section.9.3.p.3">An example is:</p>
    1610       <div id="rfc.figure.u.16"></div><pre class="text">  From: webmaster@example.org
     1642      <div id="rfc.figure.u.18"></div><pre class="text">  From: webmaster@example.org
    16111643</pre><p id="rfc.section.9.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    16121644         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving
    … …  
    16311663      <p id="rfc.section.9.4.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>).
    16321664      </p>
    1633       <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.location" class="smpl">Location</a>       = "Location" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.location" class="smpl">Location-v</a>
     1665      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.location" class="smpl">Location</a>       = "Location" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.location" class="smpl">Location-v</a>
    16341666  <a href="#header.location" class="smpl">Location-v</a>     = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
    1635 </pre><div id="rfc.figure.u.18"></div>
     1667</pre><div id="rfc.figure.u.20"></div>
    16361668      <p>Examples are:</p>  <pre class="text">  Location: http://www.example.org/pub/WWW/People.html#tim
    1637 </pre><div id="rfc.figure.u.19"></div><pre class="text">  Location: /index.html
     1669</pre><div id="rfc.figure.u.21"></div><pre class="text">  Location: /index.html
    16381670</pre><p id="rfc.section.9.4.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p>
    16391671      <ul>
    … …  
    16571689         is attempting to trace a request which appears to be failing or looping in mid-chain.
    16581690      </p>
    1659       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a>   = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a>
     1691      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a>   = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a>
    16601692  <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    16611693</pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    … …  
    16791711         non-HTTP URIs (e.g., FTP).
    16801712      </p>
    1681       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.referer" class="smpl">Referer</a>        = "Referer" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.referer" class="smpl">Referer-v</a>
     1713      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.referer" class="smpl">Referer</a>        = "Referer" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.referer" class="smpl">Referer-v</a>
    16821714  <a href="#header.referer" class="smpl">Referer-v</a>      = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    16831715</pre><p id="rfc.section.9.6.p.5">Example:</p>
    1684       <div id="rfc.figure.u.22"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
     1716      <div id="rfc.figure.u.24"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    16851717</pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
    16861718      </p>
    … …  
    16931725      </p>
    16941726      <p id="rfc.section.9.7.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
    1695       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a>   = "Retry-After" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.retry-after" class="smpl">Retry-After-v</a>
     1727      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a>   = "Retry-After" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.retry-after" class="smpl">Retry-After-v</a>
    16961728  <a href="#header.retry-after" class="smpl">Retry-After-v</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    16971729</pre><div id="rule.delta-seconds">
    16981730         <p id="rfc.section.9.7.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
    16991731      </div>
    1700       <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.26"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
     1732      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.26"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    17011733</pre><p id="rfc.section.9.7.p.6">Two examples of its use are</p>
    1702       <div id="rfc.figure.u.25"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
     1734      <div id="rfc.figure.u.27"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
    17031735  Retry-After: 120
    17041736</pre><p id="rfc.section.9.7.p.8">In the latter example, the delay is 2 minutes.</p>
    … …  
    17071739      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    17081740      <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p>
    1709       <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     1741      <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    17101742         identifying the application.
    17111743      </p>
    1712       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.server" class="smpl">Server</a>         = "Server" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.server" class="smpl">Server-v</a>
     1744      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.server" class="smpl">Server</a>         = "Server" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.server" class="smpl">Server-v</a>
    17131745  <a href="#header.server" class="smpl">Server-v</a>       = <a href="#abnf.dependencies" class="smpl">product</a>
    17141746                   *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    17151747</pre><p id="rfc.section.9.8.p.4">Example:</p>
    1716       <div id="rfc.figure.u.27"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    1717 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1748      <div id="rfc.figure.u.29"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
     1749</pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    17181750      </p>
    17191751      <div class="note" id="rfc.section.9.8.p.7">
    … …  
    17311763         user agent limitations.
    17321764      </p>
    1733       <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     1765      <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    17341766         for identifying the application.
    17351767      </p>
    … …  
    17421774         doing so makes the field value more difficult to parse.
    17431775      </p>
    1744       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a>     = "User-Agent" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.user-agent" class="smpl">User-Agent-v</a>
     1776      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a>     = "User-Agent" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.user-agent" class="smpl">User-Agent-v</a>
    17451777  <a href="#header.user-agent" class="smpl">User-Agent-v</a>   = <a href="#abnf.dependencies" class="smpl">product</a>
    17461778                   *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    17471779</pre><p id="rfc.section.9.9.p.7">Example:</p>
    1748       <div id="rfc.figure.u.29"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     1780      <div id="rfc.figure.u.31"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    17491781</pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    17501782      <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
    … …  
    18161848      </div>
    18171849      <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>
    1818       <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a> of this document.
     1850      <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a> of this document.
    18191851      </p>
    18201852      <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    … …  
    21852217      <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
    21862218         to make sure that they do not attempt to invalidate resources over which they have no authority.
     2219      </p>
     2220      <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;Security Considerations for CONNECT
     2221      </h2>
     2222      <p id="rfc.section.11.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
     2223         A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.
    21872224      </p>
    21882225      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    … …  
    22962333      </div>
    22972334      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    2298       <p id="rfc.section.A.p.1">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a>)
     2335      <p id="rfc.section.A.p.1">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a>)
    22992336      </p>
    23002337      <p id="rfc.section.A.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;7.5</a>)
    … …  
    23172354      </p>
    23182355      <p id="rfc.section.A.p.8">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    2319          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
     2356         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
    23202357      </p>
    23212358      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    2322       <div id="rfc.figure.u.30"></div> <pre class="inline"><a href="#abnf.dependencies" class="smpl">Accept</a> = &lt;Accept, defined in [Part3], Section 6.1&gt;
     2359      <div id="rfc.figure.u.32"></div> <pre class="inline"><a href="#abnf.dependencies" class="smpl">Accept</a> = &lt;Accept, defined in [Part3], Section 6.1&gt;
    23232360<a href="#abnf.dependencies" class="smpl">Accept-Charset</a> = &lt;Accept-Charset, defined in [Part3], Section 6.2&gt;
    23242361<a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> = &lt;Accept-Encoding, defined in [Part3], Section 6.3&gt;
    … …  
    24292466
    24302467<a href="#core.rules" class="smpl">token</a> = &lt;token, defined in [Part1], Section 1.2.2&gt;
    2431 </pre> <div id="rfc.figure.u.31"></div>
     2468</pre> <div id="rfc.figure.u.33"></div>
    24322469      <p>ABNF diagnostics:</p><pre class="inline">; Reason-Phrase defined but not used
    24332470; Status-Code defined but not used
    … …  
    26342671      <ul>
    26352672         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>&gt;: "205 Bodies"
     2673         </li>
     2674         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/239">http://tools.ietf.org/wg/httpbis/trac/ticket/239</a>&gt;: "Migrate CONNECT from RFC2817 to p2"
    26362675         </li>
    26372676      </ul>
    … …  
    28002839            </li>
    28012840            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    2802                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a>, <a class="iref" href="#rfc.xref.Part1.21">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6</a>, <a class="iref" href="#rfc.xref.Part1.23">6.1</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">8.1.2</a>, <a class="iref" href="#rfc.xref.Part1.28">8.2.6</a>, <a class="iref" href="#rfc.xref.Part1.29">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.30">9.2</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.9</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.36">A</a><ul class="ind">
     2841                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">2</a>, <a class="iref" href="#rfc.xref.Part1.19">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a>, <a class="iref" href="#rfc.xref.Part1.21">3</a>, <a class="iref" href="#rfc.xref.Part1.22">5</a>, <a class="iref" href="#rfc.xref.Part1.23">6</a>, <a class="iref" href="#rfc.xref.Part1.24">6.1</a>, <a class="iref" href="#rfc.xref.Part1.25">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.28">8.1.2</a>, <a class="iref" href="#rfc.xref.Part1.29">8.2.6</a>, <a class="iref" href="#rfc.xref.Part1.30">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.31">9.2</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.8</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a>, <a class="iref" href="#rfc.xref.Part1.36">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.37">A</a><ul class="ind">
    28032842                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2</a></li>
    28042843                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li>
    2805                         <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.29">8.5.6</a></li>
    2806                         <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li>
    2807                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a></li>
    2808                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.22">6</a>, <a class="iref" href="#rfc.xref.Part1.28">8.2.6</a></li>
    2809                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.21">5</a>, <a class="iref" href="#rfc.xref.Part1.23">6.1</a></li>
    2810                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li>
    2811                         <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.31">9.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.9</a></li>
    2812                         <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.30">9.2</a></li>
    2813                         <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">3</a></li>
    2814                         <li class="indline1"><em>Section 9.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a></li>
    2815                         <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">8.1.2</a></li>
    2816                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.36">A</a></li>
    2817                         <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">7.8</a></li>
     2844                        <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.30">8.5.6</a></li>
     2845                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">1.2.2</a></li>
     2846                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.33">9.8</a>, <a class="iref" href="#rfc.xref.Part1.36">9.9</a></li>
     2847                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">2.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">6</a>, <a class="iref" href="#rfc.xref.Part1.29">8.2.6</a></li>
     2848                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">2</a>, <a class="iref" href="#rfc.xref.Part1.22">5</a>, <a class="iref" href="#rfc.xref.Part1.24">6.1</a></li>
     2849                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">1.2.2</a></li>
     2850                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.32">9.8</a>, <a class="iref" href="#rfc.xref.Part1.35">9.9</a></li>
     2851                        <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.31">9.2</a></li>
     2852                        <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.20">3</a></li>
     2853                        <li class="indline1"><em>Section 9.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.21">3</a></li>
     2854                        <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.28">8.1.2</a></li>
     2855                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">7.8</a>, <a class="iref" href="#rfc.xref.Part1.34">9.8</a>, <a class="iref" href="#rfc.xref.Part1.37">A</a></li>
     2856                        <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">7.8</a></li>
    28182857                     </ul>
    28192858                  </li>
    … …  
    28862925                     </ul>
    28872926                  </li>
    2888                   <li class="indline1"><em>RFC2817</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2817.1">7.9</a>, <a class="iref" href="#rfc.xref.RFC2817.2">10.2</a>, <a class="iref" href="#RFC2817"><b>13.2</b></a>, <a class="iref" href="#rfc.xref.RFC2817.3">A</a><ul class="ind">
    2889                         <li class="indline1"><em>Section 7.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2817.2">10.2</a>, <a class="iref" href="#rfc.xref.RFC2817.3">A</a></li>
     2927                  <li class="indline1"><em>RFC2817</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2817.1">10.2</a>, <a class="iref" href="#RFC2817"><b>13.2</b></a>, <a class="iref" href="#rfc.xref.RFC2817.2">A</a><ul class="ind">
     2928                        <li class="indline1"><em>Section 7.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2817.1">10.2</a>, <a class="iref" href="#rfc.xref.RFC2817.2">A</a></li>
    28902929                     </ul>
    28912930                  </li>

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

    r1058 r1061  
    377377<figure><!--Part1--><artwork type="abnf2616">
    378378  <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in &uri;&gt;
     379  <x:ref>authority</x:ref>     = &lt;authority, defined in &uri;&gt;
    379380  <x:ref>comment</x:ref>       = &lt;comment, defined in &header-fields;&gt;
    380381  <x:ref>Host</x:ref>          = &lt;Host, defined in &uri;&gt;
    … …  
    11431144  <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
    11441145<t>
    1145    This specification reserves the method name CONNECT for use with a
    1146    proxy that can dynamically switch to being a tunnel (e.g., SSL
    1147    tunneling <xref target="RFC2817"/>).
    1148 </t>
     1146   The CONNECT method is used with a proxy to dynamically switch
     1147   the connection to a tunnel.
     1148</t>
     1149<t>
     1150   When using CONNECT, the request-target &MUST; be an authority; i.e.,
     1151   the host name and port number destination of the requested connection
     1152   separated by a colon:
     1153</t>
     1154
     1155<figure><artwork type="example">
     1156    CONNECT server.example.com:80 HTTP/1.1
     1157    Host: server.example.com:80
     1158</artwork></figure>
     1159
     1160<t>
     1161   Other HTTP mechanisms can be used normally with the CONNECT method --
     1162   except end-to-end protocol Upgrade requests, since the
     1163   tunnel must be established first.
     1164</t>
     1165<t>
     1166   For example, proxy authentication might be used to establish the
     1167   authority to create a tunnel:
     1168</t>
     1169
     1170<figure><artwork type="example">
     1171    CONNECT server.example.com:80 HTTP/1.1
     1172    Host: server.example.com:80
     1173    Proxy-Authorization: basic aGVsbG86d29ybGQ=
     1174</artwork></figure>
     1175
     1176<t>
     1177   Like any other pipelined HTTP/1.1 request, data to be tunnel may be
     1178   sent immediately after the blank line. The usual caveats also apply:
     1179   data may be discarded if the eventual response is negative, and the
     1180   connection may be reset with no response if more than one TCP segment
     1181   is outstanding.
     1182</t>
     1183
     1184<section title="Establishing a Tunnel with CONNECT">
     1185<t>
     1186   Any successful (2xx) response to a CONNECT request indicates that the
     1187   proxy has established a connection to the requested host and port,
     1188   and has switched to tunneling the current connection to that server
     1189   connection.
     1190</t>
     1191<t>
     1192   It may be the case that the proxy itself can only reach the requested
     1193   origin server through another proxy.  In this case, the first proxy
     1194   &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel
     1195   to the authority.  A proxy &MUST-NOT; respond with any 2xx status code
     1196   unless it has either a direct or tunnel connection established to the
     1197   authority.
     1198</t>
     1199<t>
     1200   An origin server which receives a CONNECT request for itself &MAY;
     1201   respond with a 2xx status code to indicate that a connection is
     1202   established.
     1203</t>
     1204<t>
     1205   If at any point either one of the peers gets disconnected, any
     1206   outstanding data that came from that peer will be passed to the other
     1207   one, and after that also the other connection will be terminated by
     1208   the proxy. If there is outstanding data to that peer undelivered,
     1209   that data will be discarded.
     1210</t>
     1211
     1212</section>
    11491213</section>
    11501214</section>
    … …  
    28442908   said organizations to make sure that they do not attempt to
    28452909   invalidate resources over which they have no authority.
     2910</t>
     2911</section>
     2912
     2913<section title="Security Considerations for CONNECT">
     2914<t>
     2915   Since tunneled data is opaque to the proxy, there are additional
     2916   risks to tunneling to other well-known or reserved ports.
     2917   A HTTP client CONNECTing to port 25 could relay spam
     2918   via SMTP, for example. As such, proxies &SHOULD; restrict CONNECT
     2919   access to a small number of known ports.
    28462920</t>
    28472921</section>
    … …  
    39153989      "205 Bodies"
    39163990    </t>
     3991    <t>
     3992      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/239"/>:
     3993      "Migrate CONNECT from RFC2817 to p2"
     3994    </t>
    39173995  </list>
    39183996</t>
Note: See TracChangeset for help on using the changeset viewer.