Ignore:
Timestamp:
Oct 26, 2010, 5:13:12 PM (9 years ago)
Author:
mnot@…
Message:

Move CONNECT text from RFC2817; fixes #239.

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.