Changeset 2122 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 14/01/13 02:39:35 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2121 r2122 2382 2382 <tr> 2383 2383 <td class="left">505</td> 2384 <td class="left">HTTP Version not supported</td>2384 <td class="left">HTTP Version Not Supported</td> 2385 2385 <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 6.6.6</a></td> 2386 2386 </tr> … … 2394 2394 <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing 2395 2395 the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields, 2396 and thus are terminated by the empty line at the end of the header block. There are no required header fields for this class 2397 of status code. Since HTTP/1.0 did not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. 2398 </p> 2399 <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect a <a href="#status.100" class="smpl">100 (Continue)</a> status message. A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses. 2396 and thus are terminated by the empty line at the end of the header block. Since HTTP/1.0 did not define any 1xx status codes, 2397 servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. 2398 </p> 2399 <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect one. 2400 A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses. 2400 2401 </p> 2401 2402 <p id="rfc.section.6.2.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself … … 2414 2415 <div id="rfc.iref.72"></div> 2415 2416 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 2416 <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch to the protocol(s) indicated2417 within the response's Upgrade header field immediately after theempty line that terminates the 101 response.2417 <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the 2418 empty line that terminates the 101 response. 2418 2419 </p> 2419 2420 <p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching … … 3137 3138 </pre><p id="rfc.section.7.4.1.p.3">Example of use:</p> 3138 3139 <div id="rfc.figure.u.60"></div><pre class="text"> Allow: GET, HEAD, PUT 3139 </pre><p id="rfc.section.7.4.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 3140 <p id="rfc.section.7.4.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according 3140 </pre><p id="rfc.section.7.4.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request. An origin server <em class="bcp14">MUST</em> generate an Allow field in a <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> response and <em class="bcp14">MAY</em> do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in 3141 a 405 response if the resource has been temporarily disabled by configuration. 3142 </p> 3143 <p id="rfc.section.7.4.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all of the indicated methods in order to handle them according 3141 3144 to the generic message handling rules. 3142 3145 </p>
Note: See TracChangeset
for help on using the changeset viewer.