Changeset 1859 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 03/09/12 22:12:40 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1845 r1859 34 34 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 35 <!ENTITY header-etag "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">37 36 <!ENTITY header-expires "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 37 <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 48 47 <!ENTITY qvalue "<xref target='Part2' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 49 48 <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 50 <!ENTITY status-100 "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">51 49 <!ENTITY status-1xx "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 52 50 <!ENTITY status-203 "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 55 53 <!ENTITY status-4xx "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 56 54 <!ENTITY status-414 "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 57 <!ENTITY cons-new-header-fields "<xref target='Part2' x:rel='#considerations.for. creating.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">55 <!ENTITY cons-new-header-fields "<xref target='Part2' x:rel='#considerations.for.new.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 58 56 ]> 59 57 <?rfc toc="yes" ?> … … 3010 3008 </t> 3011 3009 </section> 3012 </section>3013 3014 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">3015 <t>3016 The purpose of the <x:ref>100 (Continue)</x:ref> status code (see &status-100;)3017 is to allow a client that is sending a request message with a request body3018 to determine if the origin server is willing to accept the request3019 (based on the request header fields) before the client sends the request3020 body. In some cases, it might either be inappropriate or highly3021 inefficient for the client to send the body if the server will reject3022 the message without looking at the body.3023 </t>3024 <t>3025 Requirements for HTTP/1.1 clients:3026 <list style="symbols">3027 <t>3028 If a client will wait for a <x:ref>100 (Continue)</x:ref> response before3029 sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header3030 field (&header-expect;) with the "100-continue" expectation.3031 </t>3032 <t>3033 A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with3034 the "100-continue" expectation if it does not intend to send a request3035 body.3036 </t>3037 </list>3038 </t>3039 <t>3040 Because of the presence of older implementations, the protocol allows3041 ambiguous situations in which a client might send "Expect: 100-continue"3042 without receiving either a <x:ref>417 (Expectation Failed)</x:ref>3043 or a <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends this3044 header field to an origin server (possibly via a proxy) from which it3045 has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT;3046 wait for an indefinite period before sending the request body.3047 </t>3048 <t>3049 Requirements for HTTP/1.1 origin servers:3050 <list style="symbols">3051 <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header3052 field with the "100-continue" expectation, an origin server &MUST;3053 either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read3054 from the input stream, or respond with a final status code. The3055 origin server &MUST-NOT; wait for the request body before sending3056 the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status3057 code, it &MAY; close the transport connection or it &MAY; continue3058 to read and discard the rest of the request. It &MUST-NOT;3059 perform the request method if it returns a final status code.3060 </t>3061 <t> An origin server &SHOULD-NOT; send a <x:ref>100 (Continue)</x:ref> response if3062 the request message does not include an <x:ref>Expect</x:ref> header3063 field with the "100-continue" expectation, and &MUST-NOT; send a3064 <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.03065 (or earlier) client. There is an exception to this rule: for3066 compatibility with <xref target="RFC2068"/>, a server &MAY; send a <x:ref>100 (Continue)</x:ref>3067 status code in response to an HTTP/1.1 PUT or POST request that does3068 not include an Expect header field with the "100-continue"3069 expectation. This exception, the purpose of which is3070 to minimize any client processing delays associated with an3071 undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to3072 HTTP/1.1 requests, and not to requests with any other HTTP-version3073 value.3074 </t>3075 <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has3076 already received some or all of the request body for the3077 corresponding request.3078 </t>3079 <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;3080 ultimately send a final status code, once the request body is3081 received and processed, unless it terminates the transport3082 connection prematurely.3083 </t>3084 <t> If an origin server receives a request that does not include an3085 <x:ref>Expect</x:ref> header field with the "100-continue" expectation,3086 the request includes a request body, and the server responds3087 with a final status code before reading the entire request body3088 from the transport connection, then the server &SHOULD-NOT; close3089 the transport connection until it has read the entire request,3090 or until the client closes the connection. Otherwise, the client3091 might not reliably receive the response message. However, this3092 requirement ought not be construed as preventing a server from3093 defending itself against denial-of-service attacks, or from3094 badly broken client implementations.3095 </t>3096 </list>3097 </t>3098 <t>3099 Requirements for HTTP/1.1 proxies:3100 <list style="symbols">3101 <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>3102 header field with the "100-continue" expectation, and the proxy3103 either knows that the next-hop server complies with HTTP/1.1 or3104 higher, or does not know the HTTP version of the next-hop3105 server, it &MUST; forward the request, including the Expect header3106 field.3107 </t>3108 <t> If the proxy knows that the version of the next-hop server is3109 HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;3110 respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.3111 </t>3112 <t> Proxies &SHOULD; maintain a record of the HTTP version3113 numbers received from recently-referenced next-hop servers.3114 </t>3115 <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the3116 request message was received from an HTTP/1.0 (or earlier)3117 client and did not include an <x:ref>Expect</x:ref> header field with3118 the "100-continue" expectation. This requirement overrides the3119 general rule for forwarding of <x:ref>1xx</x:ref> responses (see &status-1xx;).3120 </t>3121 </list>3122 </t>3123 3010 </section> 3124 3011
Note: See TracChangeset
for help on using the changeset viewer.