Changeset 1716 for draft-ietf-httpbis/latest
- Timestamp:
- 04/07/12 20:15:19 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1715 r1716 2166 2166 </p> 2167 2167 <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2168 <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue)status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2168 <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2169 2169 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2170 2170 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2173 2173 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2174 2174 <ul> 2175 <li>If a client will wait for a 100 (Continue)response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2175 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 2176 2176 </li> 2177 2177 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. … … 2179 2179 </ul> 2180 2180 <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: 2181 100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a 100 (Continue) status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy)2182 from which it has never seen a 100 (Continue)status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.2181 100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has 2182 never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. 2183 2183 </p> 2184 2184 <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p> 2185 2185 <ul> 2186 <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status 2187 code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. 2188 </li> 2189 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect header field with the "100-continue" expectation, 2190 and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this 2191 rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field 2192 with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated 2193 with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other 2194 HTTP-version value. 2195 </li> 2196 <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request. 2197 </li> 2198 <li>An origin server that sends a 100 (Continue) response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection 2186 <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. 2187 </li> 2188 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an Expect header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility 2189 with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue" 2190 expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared 2191 wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value. 2192 </li> 2193 <li>An origin server <em class="bcp14">MAY</em> omit a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request. 2194 </li> 2195 <li>An origin server that sends a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection 2199 2196 prematurely. 2200 2197 </li> … … 2216 2213 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. 2217 2214 </li> 2218 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2219 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2220 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2215 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect header field 2216 with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2221 2217 </li> 2222 2218 </ul> … … 2257 2253 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2258 2254 </p> 2259 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched2260 to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.2255 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching 2256 Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. 2261 2257 </p> 2262 2258 <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined -
draft-ietf-httpbis/latest/p1-messaging.xml
r1715 r1716 3091 3091 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status"> 3092 3092 <t> 3093 The purpose of the 100 (Continue) status code (see &status-100;) is to3094 allow a client that is sending a request message with a request body3093 The purpose of the <x:ref>100 (Continue)</x:ref> status code (see &status-100;) 3094 is to allow a client that is sending a request message with a request body 3095 3095 to determine if the origin server is willing to accept the request 3096 3096 (based on the request header fields) before the client sends the request … … 3103 3103 <list style="symbols"> 3104 3104 <t> 3105 If a client will wait for a 100 (Continue)response before3105 If a client will wait for a <x:ref>100 (Continue)</x:ref> response before 3106 3106 sending the request body, it &MUST; send an Expect header 3107 3107 field (&header-expect;) with the "100-continue" expectation. … … 3118 3118 ambiguous situations in which a client might send "Expect: 100-continue" 3119 3119 without receiving either a <x:ref>417 (Expectation Failed)</x:ref> 3120 or a 100 (Continue)status code. Therefore, when a client sends this3120 or a <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends this 3121 3121 header field to an origin server (possibly via a proxy) from which it 3122 has never seen a 100 (Continue)status code, the client &SHOULD-NOT;3122 has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 3123 3123 wait for an indefinite period before sending the request body. 3124 3124 </t> … … 3128 3128 <t> Upon receiving a request which includes an Expect header 3129 3129 field with the "100-continue" expectation, an origin server &MUST; 3130 either respond with 100 (Continue)status code and continue to read3130 either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read 3131 3131 from the input stream, or respond with a final status code. The 3132 3132 origin server &MUST-NOT; wait for the request body before sending 3133 the 100 (Continue)response. If it responds with a final status3133 the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status 3134 3134 code, it &MAY; close the transport connection or it &MAY; continue 3135 3135 to read and discard the rest of the request. It &MUST-NOT; 3136 3136 perform the request method if it returns a final status code. 3137 3137 </t> 3138 <t> An origin server &SHOULD-NOT; send a 100 (Continue)response if3138 <t> An origin server &SHOULD-NOT; send a <x:ref>100 (Continue)</x:ref> response if 3139 3139 the request message does not include an Expect header 3140 3140 field with the "100-continue" expectation, and &MUST-NOT; send a 3141 100 (Continue)response if such a request comes from an HTTP/1.03141 <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0 3142 3142 (or earlier) client. There is an exception to this rule: for 3143 compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue)3143 compatibility with <xref target="RFC2068"/>, a server &MAY; send a <x:ref>100 (Continue)</x:ref> 3144 3144 status code in response to an HTTP/1.1 PUT or POST request that does 3145 3145 not include an Expect header field with the "100-continue" 3146 3146 expectation. This exception, the purpose of which is 3147 3147 to minimize any client processing delays associated with an 3148 undeclared wait for 100 (Continue)status code, applies only to3148 undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to 3149 3149 HTTP/1.1 requests, and not to requests with any other HTTP-version 3150 3150 value. 3151 3151 </t> 3152 <t> An origin server &MAY; omit a 100 (Continue)response if it has3152 <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has 3153 3153 already received some or all of the request body for the 3154 3154 corresponding request. 3155 3155 </t> 3156 <t> An origin server that sends a 100 (Continue)response &MUST;3156 <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST; 3157 3157 ultimately send a final status code, once the request body is 3158 3158 received and processed, unless it terminates the transport … … 3190 3190 numbers received from recently-referenced next-hop servers. 3191 3191 </t> 3192 <t> A proxy &MUST-NOT; forward a 100 (Continue)response if the3192 <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the 3193 3193 request message was received from an HTTP/1.0 (or earlier) 3194 3194 client and did not include an Expect header field with … … 3275 3275 </t> 3276 3276 <t> 3277 Servers &MUST; include the "Upgrade" header field in 101 (Switching3278 Protocols) responses to indicate which protocol(s) are being switched to,3277 Servers &MUST; include the "Upgrade" header field in <x:ref>101 (Switching 3278 Protocols)</x:ref> responses to indicate which protocol(s) are being switched to, 3279 3279 and &MUST; include it in <x:ref>426 (Upgrade Required)</x:ref> responses to indicate 3280 3280 acceptable protocols to upgrade to. Servers &MAY; include it in any other … … 4109 4109 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/> 4110 4110 <x:source href="p2-semantics.xml" basename="p2-semantics"> 4111 <x:defines>100 (Continue)</x:defines> 4112 <x:defines>101 (Switching Protocols)</x:defines> 4111 4113 <x:defines>200 (OK)</x:defines> 4112 4114 <x:defines>204 (No Content)</x:defines> -
draft-ietf-httpbis/latest/p2-semantics.html
r1715 r1716 1651 1651 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. 1652 1652 </p> 1653 <p id="rfc.section.4.3.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 1001654 (Continue)status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent.1653 <p id="rfc.section.4.3.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a <a href="#status.100" class="smpl">100 1654 (Continue)</a> status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. 1655 1655 </p> 1656 1656 <p id="rfc.section.4.3.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 1657 1657 requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards 1658 a request, then it need not forward the corresponding 100 (Continue)response(s).)1658 a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).) 1659 1659 </p> 1660 1660 <div id="rfc.iref.21"></div> … … 2897 2897 </p> 2898 2898 <ol> 2899 <li>If the response status code is 100 (Continue) or 101 (Switching Protocols), the response <em class="bcp14">MAY</em> include a Date header field, at the server's option. 2900 </li> 2901 <li>If the response status code conveys a server error, e.g., 500 (Internal Server Error) or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date. 2899 <li>If the response status code is <a href="#status.100" class="smpl">100 (Continue)</a> or <a href="#status.101" class="smpl">101 (Switching Protocols)</a>, the response <em class="bcp14">MAY</em> include a Date header field, at the server's option. 2900 </li> 2901 <li>If the response status code conveys a server error, e.g., <a href="#status.500" class="smpl">500 2902 (Internal Server Error)</a> or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date. 2902 2903 </li> 2903 2904 <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. -
draft-ietf-httpbis/latest/p2-semantics.xml
r1715 r1716 1291 1291 <t> 1292 1292 A client &MUST; be prepared to accept one or more 1xx status responses 1293 prior to a regular response, even if the client does not expect a 1001294 (Continue) status message. Unexpected 1xx status responses &MAY; be1293 prior to a regular response, even if the client does not expect a <x:ref>100 1294 (Continue)</x:ref> status message. Unexpected 1xx status responses &MAY; be 1295 1295 ignored by a user agent. 1296 1296 </t> … … 1300 1300 requested the generation of the 1xx response. (For example, if a 1301 1301 proxy adds a "Expect: 100-continue" field when it forwards a request, 1302 then it need not forward the corresponding 100 (Continue)1302 then it need not forward the corresponding <x:ref>100 (Continue)</x:ref> 1303 1303 response(s).) 1304 1304 </t> … … 1307 1307 <iref primary="true" item="100 Continue (status code)" x:for-anchor=""/> 1308 1308 <iref primary="true" item="Status Codes" subitem="100 Continue" x:for-anchor=""/> 1309 <x:anchor-alias value="100 (Continue)"/> 1309 1310 <t> 1310 1311 The client &SHOULD; continue with its request. This interim response is … … 1322 1323 <iref primary="true" item="101 Switching Protocols (status code)" x:for-anchor=""/> 1323 1324 <iref primary="true" item="Status Codes" subitem="101 Switching Protocols" x:for-anchor=""/> 1325 <x:anchor-alias value="101 (Switching Protocols)"/> 1324 1326 <t> 1325 1327 The server understands and is willing to comply with the client's … … 2047 2049 <iref primary="true" item="500 Internal Server Error (status code)" x:for-anchor=""/> 2048 2050 <iref primary="true" item="Status Codes" subitem="500 Internal Server Error" x:for-anchor=""/> 2051 <x:anchor-alias value="500 (Internal Server Error)"/> 2049 2052 <t> 2050 2053 The server encountered an unexpected condition which prevented it … … 3542 3545 except in these cases: 3543 3546 <list style="numbers"> 3544 <t>If the response status code is 100 (Continue) or 101 (Switching3545 Protocols), the response &MAY; include a Date header field, at3546 the server's option.</t>3547 3548 <t>If the response status code conveys a server error, e.g., 5003549 (Internal Server Error) or <x:ref>503 (Service Unavailable)</x:ref>,3547 <t>If the response status code is <x:ref>100 (Continue)</x:ref> or 3548 <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a 3549 Date header field, at the server's option.</t> 3550 3551 <t>If the response status code conveys a server error, e.g., <x:ref>500 3552 (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>, 3550 3553 and it is inconvenient or impossible to generate a valid Date.</t> 3551 3554
Note: See TracChangeset
for help on using the changeset viewer.