Changeset 1061 for draft-ietf-httpbis/latest
- Timestamp:
- 27/10/10 00:13:12 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1058 r1061 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-10-2 6">405 <meta name="dct.issued" scheme="ISO8601" content="2010-10-27"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <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 "HTTP/1.1" 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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: April 29, 2011</td>436 <td class="left">Expires: April 30, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">October 2 6, 2010</td>489 <td class="right">October 27, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </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> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 574 574 <li class="tocline1">7.7 <a href="#DELETE">DELETE</a></li> 575 575 <li class="tocline1">7.8 <a href="#TRACE">TRACE</a></li> 576 <li class="tocline1">7.9 <a href="#CONNECT">CONNECT</a></li> 576 <li class="tocline1">7.9 <a href="#CONNECT">CONNECT</a><ul class="toc"> 577 <li class="tocline1">7.9.1 <a href="#rfc.section.7.9.1">Establishing a Tunnel with CONNECT</a></li> 578 </ul> 579 </li> 577 580 </ul> 578 581 </li> … … 658 661 <li class="tocline1">11.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 659 662 <li class="tocline1">11.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li> 663 <li class="tocline1">11.4 <a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li> 660 664 </ul> 661 665 </li> … … 727 731 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 728 732 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <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>> 729 <a href="#abnf.dependencies" class="smpl">comment</a> = <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>> 730 <a href="#abnf.dependencies" class="smpl">Host</a> = <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>> 731 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <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>> 732 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <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>> 733 <a href="#abnf.dependencies" class="smpl">product</a> = <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>> 734 <a href="#abnf.dependencies" class="smpl">TE</a> = <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>> 735 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <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>> 733 authority = <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>> 734 <a href="#abnf.dependencies" class="smpl">comment</a> = <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>> 735 <a href="#abnf.dependencies" class="smpl">Host</a> = <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>> 736 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <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>> 737 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <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>> 738 <a href="#abnf.dependencies" class="smpl">product</a> = <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>> 739 <a href="#abnf.dependencies" class="smpl">TE</a> = <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>> 740 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <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>> 736 741 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <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>> 737 742 <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> = … … 761 766 <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>> 762 767 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <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.1 7"><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. 764 769 </p> 765 770 <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 7.2</a> … … 801 806 to a single application, so that this is clear. 802 807 </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.1 8"><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 message808 <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 804 809 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 805 810 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 820 825 / <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> 821 826 / <a href="#header.from" class="smpl">From</a> ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 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> 823 828 / <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> 824 829 / <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> … … 830 835 / <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> 831 836 / <a href="#header.referer" class="smpl">Referer</a> ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.6</a> 832 / <a href="#abnf.dependencies" class="smpl">TE</a> ; <a href="#Part1" id="rfc.xref.Part1.2 0"><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> 833 838 / <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 9.9</a> 834 839 </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 … … 921 926 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 922 927 <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.2 1"><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>). 924 929 </p> 925 930 <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> … … 942 947 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>. 943 948 </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.2 2"><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 applied949 <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 945 950 to ensure safe and proper transfer of the message. 946 951 </p> … … 948 953 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 949 954 <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.2 3"><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 following955 <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 951 956 rules are used (with the first applicable one being selected): 952 957 </p> … … 1131 1136 </p> 1132 1137 <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.2 4"><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 the1138 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 1134 1139 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1135 1140 infinite loop. 1136 1141 </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.2 5"><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. 1138 1143 </p> 1139 1144 <div id="rfc.iref.c.1"></div> 1140 1145 <div id="rfc.iref.m.8"></div> 1141 1146 <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a> <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> 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. 1144 1176 </p> 1145 1177 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1> … … 1162 1194 <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 1163 1195 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.2 6"><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. 1165 1197 </p> 1166 1198 <div id="rfc.iref.26"></div> 1167 1199 <div id="rfc.iref.s.3"></div> 1168 1200 <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> <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.2 7"><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 defined1201 <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 1170 1202 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1171 1203 </p> … … 1247 1279 another input action. 1248 1280 </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.2 8"><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>. 1250 1282 </p> 1251 1283 <div id="rfc.iref.33"></div> … … 1554 1586 <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 1555 1587 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. 1557 1589 </p> 1558 1590 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1564 1596 this field is strictly to inform the recipient of valid methods associated with the resource. 1565 1597 </p> 1566 <div id="rfc.figure.u.1 2"></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> 1567 1599 <a href="#header.allow" class="smpl">Allow-v</a> = #<a href="#method" class="smpl">Method</a> 1568 1600 </pre><p id="rfc.section.9.1.p.3">Example of use:</p> 1569 <div id="rfc.figure.u.1 3"></div><pre class="text"> Allow: GET, HEAD, PUT1601 <div id="rfc.figure.u.15"></div><pre class="text"> Allow: GET, HEAD, PUT 1570 1602 </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> 1571 1603 <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 … … 1576 1608 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1577 1609 <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.1 4"></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> 1579 1611 <a href="#header.expect" class="smpl">Expect-v</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 1580 1612 … … 1596 1628 </p> 1597 1629 <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.3 0"><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. 1599 1631 </p> 1600 1632 <div id="rfc.iref.f.1"></div> … … 1603 1635 <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>: 1604 1636 </p> 1605 <div id="rfc.figure.u.1 5"></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> 1606 1638 <a href="#header.from" class="smpl">From-v</a> = <a href="#header.from" class="smpl">mailbox</a> 1607 1639 1608 1640 <a href="#header.from" class="smpl">mailbox</a> = <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>> 1609 1641 </pre><p id="rfc.section.9.3.p.3">An example is:</p> 1610 <div id="rfc.figure.u.1 6"></div><pre class="text"> From: webmaster@example.org1642 <div id="rfc.figure.u.18"></div><pre class="text"> From: webmaster@example.org 1611 1643 </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 1612 1644 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 … … 1631 1663 <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>). 1632 1664 </p> 1633 <div id="rfc.figure.u.1 7"></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> 1634 1666 <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> 1636 1668 <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.html1669 </pre><div id="rfc.figure.u.21"></div><pre class="text"> Location: /index.html 1638 1670 </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> 1639 1671 <ul> … … 1657 1689 is attempting to trace a request which appears to be failing or looping in mid-chain. 1658 1690 </p> 1659 <div id="rfc.figure.u.2 0"></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> 1660 1692 <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 1661 1693 </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> … … 1679 1711 non-HTTP URIs (e.g., FTP). 1680 1712 </p> 1681 <div id="rfc.figure.u.2 1"></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> 1682 1714 <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> 1683 1715 </pre><p id="rfc.section.9.6.p.5">Example:</p> 1684 <div id="rfc.figure.u.2 2"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html1716 <div id="rfc.figure.u.24"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1685 1717 </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 11.2</a> for security considerations. 1686 1718 </p> … … 1693 1725 </p> 1694 1726 <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.2 3"></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> 1696 1728 <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> 1697 1729 </pre><div id="rule.delta-seconds"> 1698 1730 <p id="rfc.section.9.7.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 1699 1731 </div> 1700 <div id="rfc.figure.u.2 4"></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> 1701 1733 </pre><p id="rfc.section.9.7.p.6">Two examples of its use are</p> 1702 <div id="rfc.figure.u.2 5"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT1734 <div id="rfc.figure.u.27"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1703 1735 Retry-After: 120 1704 1736 </pre><p id="rfc.section.9.7.p.8">In the latter example, the delay is 2 minutes.</p> … … 1707 1739 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1708 1740 <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.3 1"><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 for1741 <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 1710 1742 identifying the application. 1711 1743 </p> 1712 <div id="rfc.figure.u.2 6"></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> 1713 1745 <a href="#header.server" class="smpl">Server-v</a> = <a href="#abnf.dependencies" class="smpl">product</a> 1714 1746 *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 1715 1747 </pre><p id="rfc.section.9.8.p.4">Example:</p> 1716 <div id="rfc.figure.u.2 7"></div><pre class="text"> Server: CERN/3.0 libwww/2.171717 </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.3 3"><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>). 1718 1750 </p> 1719 1751 <div class="note" id="rfc.section.9.8.p.7"> … … 1731 1763 user agent limitations. 1732 1764 </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.3 4"><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 significance1765 <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 1734 1766 for identifying the application. 1735 1767 </p> … … 1742 1774 doing so makes the field value more difficult to parse. 1743 1775 </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> 1745 1777 <a href="#header.user-agent" class="smpl">User-Agent-v</a> = <a href="#abnf.dependencies" class="smpl">product</a> 1746 1778 *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 1747 1779 </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.17b31780 <div id="rfc.figure.u.31"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1749 1781 </pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1750 1782 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> … … 1816 1848 </div> 1817 1849 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <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 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 4.1</a> of this document. 1819 1851 </p> 1820 1852 <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: … … 2185 2217 <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 2186 2218 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> 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. 2187 2224 </p> 2188 2225 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> … … 2296 2333 </div> 2297 2334 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <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 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 4.1</a>) 2299 2336 </p> 2300 2337 <p id="rfc.section.A.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 7.5</a>) … … 2317 2354 </p> 2318 2355 <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.3 6"><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 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 9.8</a>) 2320 2357 </p> 2321 2358 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 2322 <div id="rfc.figure.u.3 0"></div> <pre class="inline"><a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in [Part3], Section 6.1>2359 <div id="rfc.figure.u.32"></div> <pre class="inline"><a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in [Part3], Section 6.1> 2323 2360 <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> = <Accept-Charset, defined in [Part3], Section 6.2> 2324 2361 <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> = <Accept-Encoding, defined in [Part3], Section 6.3> … … 2429 2466 2430 2467 <a href="#core.rules" class="smpl">token</a> = <token, defined in [Part1], Section 1.2.2> 2431 </pre> <div id="rfc.figure.u.3 1"></div>2468 </pre> <div id="rfc.figure.u.33"></div> 2432 2469 <p>ABNF diagnostics:</p><pre class="inline">; Reason-Phrase defined but not used 2433 2470 ; Status-Code defined but not used … … 2634 2671 <ul> 2635 2672 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>>: "205 Bodies" 2673 </li> 2674 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/239">http://tools.ietf.org/wg/httpbis/trac/ticket/239</a>>: "Migrate CONNECT from RFC2817 to p2" 2636 2675 </li> 2637 2676 </ul> … … 2800 2839 </li> 2801 2840 <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> <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> <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"> 2803 2842 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2</a></li> 2804 2843 <li class="indline1"><em>Section 1.2.2</em> <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> <a class="iref" href="#rfc.xref.Part1. 29">8.5.6</a></li>2806 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.1 1">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> <a class="iref" href="#rfc.xref.Part1.1 0">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> <a class="iref" href="#rfc.xref.Part1.1 8">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> <a class="iref" href="#rfc.xref.Part1.1 7">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> <a class="iref" href="#rfc.xref.Part1.1 2">1.2.2</a></li>2811 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.1 4">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> <a class="iref" href="#rfc.xref.Part1.2 6">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> <a class="iref" href="#rfc.xref.Part1. 19">3</a></li>2814 <li class="indline1"><em>Section 9.5</em> <a class="iref" href="#rfc.xref.Part1.1 5">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">3</a></li>2815 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.2 7">8.1.2</a></li>2816 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.2 4">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> <a class="iref" href="#rfc.xref.Part1.2 5">7.8</a></li>2844 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.30">8.5.6</a></li> 2845 <li class="indline1"><em>Section 2.6</em> <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> <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> <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> <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> <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a></li> 2850 <li class="indline1"><em>Section 6.3</em> <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> <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> <a class="iref" href="#rfc.xref.Part1.20">3</a></li> 2853 <li class="indline1"><em>Section 9.5</em> <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> <a class="iref" href="#rfc.xref.Part1.28">8.1.2</a></li> 2855 <li class="indline1"><em>Section 9.9</em> <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> <a class="iref" href="#rfc.xref.Part1.26">7.8</a></li> 2818 2857 </ul> 2819 2858 </li> … … 2886 2925 </ul> 2887 2926 </li> 2888 <li class="indline1"><em>RFC2817</em> <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> <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> <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> <a class="iref" href="#rfc.xref.RFC2817.1">10.2</a>, <a class="iref" href="#rfc.xref.RFC2817.2">A</a></li> 2890 2929 </ul> 2891 2930 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1058 r1061 377 377 <figure><!--Part1--><artwork type="abnf2616"> 378 378 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 379 <x:ref>authority</x:ref> = <authority, defined in &uri;> 379 380 <x:ref>comment</x:ref> = <comment, defined in &header-fields;> 380 381 <x:ref>Host</x:ref> = <Host, defined in &uri;> … … 1143 1144 <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> 1144 1145 <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> 1149 1213 </section> 1150 1214 </section> … … 2844 2908 said organizations to make sure that they do not attempt to 2845 2909 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. 2846 2920 </t> 2847 2921 </section> … … 3915 3989 "205 Bodies" 3916 3990 </t> 3991 <t> 3992 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/239"/>: 3993 "Migrate CONNECT from RFC2817 to p2" 3994 </t> 3917 3995 </list> 3918 3996 </t>
Note: See TracChangeset
for help on using the changeset viewer.