Changeset 609 for draft-ietf-httpbis
- Timestamp:
- 13/07/09 08:30:27 (13 years ago)
- Location:
- draft-ietf-httpbis
- Files:
-
- 25 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/07/draft-ietf-httpbis-p1-messaging-07.xml
r605 r609 151 151 <country>Germany</country> 152 152 </postal> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 157 157 </address> 158 158 </author> … … 2854 2854 See Authors Section. 2855 2855 </t> 2856 2857 2858 </t> 2859 2860 2856 <t hangText="Intended usage:"> 2857 COMMON 2858 </t> 2859 <t hangText="Restrictions on usage:"> 2860 none 2861 2861 </t> 2862 2862 <t hangText="Author/Change controller:"> … … 2926 2926 See Authors Section. 2927 2927 </t> 2928 2929 2930 </t> 2931 2932 2928 <t hangText="Intended usage:"> 2929 COMMON 2930 </t> 2931 <t hangText="Restrictions on usage:"> 2932 none 2933 2933 </t> 2934 2934 <t hangText="Author/Change controller:"> -
draft-ietf-httpbis/07/draft-ietf-httpbis-p2-semantics-07.xml
r605 r609 151 151 <country>Germany</country> 152 152 </postal> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 157 157 </address> 158 158 </author> … … 840 840 agent, the origin server can create the resource with that URI. If a 841 841 new resource is created at the request-target, the origin server MUST 842 842 inform the user agent 843 843 via the 201 (Created) response. If an existing resource is modified, 844 844 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent -
draft-ietf-httpbis/07/draft-ietf-httpbis-p3-payload-07.xml
r605 r609 151 151 <country>Germany</country> 152 152 </postal> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 157 157 </address> 158 158 </author> -
draft-ietf-httpbis/07/draft-ietf-httpbis-p4-conditional-07.xml
r605 r609 151 151 <country>Germany</country> 152 152 </postal> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 157 157 </address> 158 158 </author> -
draft-ietf-httpbis/07/draft-ietf-httpbis-p5-range-07.xml
r605 r609 151 151 <country>Germany</country> 152 152 </postal> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 157 157 </address> 158 158 </author> … … 1285 1285 See Authors Section. 1286 1286 </t> 1287 1288 1289 </t> 1290 1291 1287 <t hangText="Intended usage:"> 1288 COMMON 1289 </t> 1290 <t hangText="Restrictions on usage:"> 1291 none 1292 1292 </t> 1293 1293 <t hangText="Author/Change controller:"> -
draft-ietf-httpbis/07/draft-ietf-httpbis-p7-auth-07.xml
r605 r609 151 151 <country>Germany</country> 152 152 </postal> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 153 <phone>+49 251 2807760</phone> 154 <facsimile>+49 251 2807761</facsimile> 155 <email>julian.reschke@greenbytes.de</email> 156 <uri>http://greenbytes.de/tech/webdav/</uri> 157 157 </address> 158 158 </author> -
draft-ietf-httpbis/07/p1-messaging.xml
r604 r609 185 185 <country>Germany</country> 186 186 </postal> 187 <phone>+49 251 2807760</phone> 188 <facsimile>+49 251 2807761</facsimile> 189 <email>julian.reschke@greenbytes.de</email> 190 <uri>http://greenbytes.de/tech/webdav/</uri> 187 <phone>+49 251 2807760</phone> 188 <facsimile>+49 251 2807761</facsimile> 189 <email>julian.reschke@greenbytes.de</email> 190 <uri>http://greenbytes.de/tech/webdav/</uri> 191 191 </address> 192 192 </author> … … 2894 2894 See Authors Section. 2895 2895 </t> 2896 2897 2898 </t> 2899 2900 2896 <t hangText="Intended usage:"> 2897 COMMON 2898 </t> 2899 <t hangText="Restrictions on usage:"> 2900 none 2901 2901 </t> 2902 2902 <t hangText="Author/Change controller:"> … … 2966 2966 See Authors Section. 2967 2967 </t> 2968 2969 2970 </t> 2971 2972 2968 <t hangText="Intended usage:"> 2969 COMMON 2970 </t> 2971 <t hangText="Restrictions on usage:"> 2972 none 2973 2973 </t> 2974 2974 <t hangText="Author/Change controller:"> -
draft-ietf-httpbis/07/p2-semantics.xml
r604 r609 212 212 <country>Germany</country> 213 213 </postal> 214 <phone>+49 251 2807760</phone> 215 <facsimile>+49 251 2807761</facsimile> 216 <email>julian.reschke@greenbytes.de</email> 217 <uri>http://greenbytes.de/tech/webdav/</uri> 214 <phone>+49 251 2807760</phone> 215 <facsimile>+49 251 2807761</facsimile> 216 <email>julian.reschke@greenbytes.de</email> 217 <uri>http://greenbytes.de/tech/webdav/</uri> 218 218 </address> 219 219 </author> … … 907 907 agent, the origin server can create the resource with that URI. If a 908 908 new resource is created at the request-target, the origin server &MUST; 909 909 inform the user agent 910 910 via the 201 (Created) response. If an existing resource is modified, 911 911 either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent -
draft-ietf-httpbis/07/p3-payload.xml
r604 r609 182 182 <country>Germany</country> 183 183 </postal> 184 <phone>+49 251 2807760</phone> 185 <facsimile>+49 251 2807761</facsimile> 186 <email>julian.reschke@greenbytes.de</email> 187 <uri>http://greenbytes.de/tech/webdav/</uri> 184 <phone>+49 251 2807760</phone> 185 <facsimile>+49 251 2807761</facsimile> 186 <email>julian.reschke@greenbytes.de</email> 187 <uri>http://greenbytes.de/tech/webdav/</uri> 188 188 </address> 189 189 </author> -
draft-ietf-httpbis/07/p4-conditional.xml
r604 r609 175 175 <country>Germany</country> 176 176 </postal> 177 <phone>+49 251 2807760</phone> 178 <facsimile>+49 251 2807761</facsimile> 179 <email>julian.reschke@greenbytes.de</email> 180 <uri>http://greenbytes.de/tech/webdav/</uri> 177 <phone>+49 251 2807760</phone> 178 <facsimile>+49 251 2807761</facsimile> 179 <email>julian.reschke@greenbytes.de</email> 180 <uri>http://greenbytes.de/tech/webdav/</uri> 181 181 </address> 182 182 </author> -
draft-ietf-httpbis/07/p5-range.xml
r604 r609 170 170 <country>Germany</country> 171 171 </postal> 172 <phone>+49 251 2807760</phone> 173 <facsimile>+49 251 2807761</facsimile> 174 <email>julian.reschke@greenbytes.de</email> 175 <uri>http://greenbytes.de/tech/webdav/</uri> 172 <phone>+49 251 2807760</phone> 173 <facsimile>+49 251 2807761</facsimile> 174 <email>julian.reschke@greenbytes.de</email> 175 <uri>http://greenbytes.de/tech/webdav/</uri> 176 176 </address> 177 177 </author> … … 1304 1304 See Authors Section. 1305 1305 </t> 1306 1307 1308 </t> 1309 1310 1306 <t hangText="Intended usage:"> 1307 COMMON 1308 </t> 1309 <t hangText="Restrictions on usage:"> 1310 none 1311 1311 </t> 1312 1312 <t hangText="Author/Change controller:"> -
draft-ietf-httpbis/07/p7-auth.xml
r604 r609 168 168 <country>Germany</country> 169 169 </postal> 170 <phone>+49 251 2807760</phone> 171 <facsimile>+49 251 2807761</facsimile> 172 <email>julian.reschke@greenbytes.de</email> 173 <uri>http://greenbytes.de/tech/webdav/</uri> 170 <phone>+49 251 2807760</phone> 171 <facsimile>+49 251 2807761</facsimile> 172 <email>julian.reschke@greenbytes.de</email> 173 <uri>http://greenbytes.de/tech/webdav/</uri> 174 174 </address> 175 175 </author> -
draft-ietf-httpbis/latest/p1-messaging.html
r604 r609 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">July 1 0, 2009</td>473 <td class="header right">July 13, 2009</td> 474 474 </tr> 475 475 </table> -
draft-ietf-httpbis/latest/p1-messaging.xml
r604 r609 185 185 <country>Germany</country> 186 186 </postal> 187 <phone>+49 251 2807760</phone> 188 <facsimile>+49 251 2807761</facsimile> 189 <email>julian.reschke@greenbytes.de</email> 190 <uri>http://greenbytes.de/tech/webdav/</uri> 187 <phone>+49 251 2807760</phone> 188 <facsimile>+49 251 2807761</facsimile> 189 <email>julian.reschke@greenbytes.de</email> 190 <uri>http://greenbytes.de/tech/webdav/</uri> 191 191 </address> 192 192 </author> … … 2894 2894 See Authors Section. 2895 2895 </t> 2896 2897 2898 </t> 2899 2900 2896 <t hangText="Intended usage:"> 2897 COMMON 2898 </t> 2899 <t hangText="Restrictions on usage:"> 2900 none 2901 2901 </t> 2902 2902 <t hangText="Author/Change controller:"> … … 2966 2966 See Authors Section. 2967 2967 </t> 2968 2969 2970 </t> 2971 2972 2968 <t hangText="Intended usage:"> 2969 COMMON 2970 </t> 2971 <t hangText="Restrictions on usage:"> 2972 none 2973 2973 </t> 2974 2974 <t hangText="Author/Change controller:"> -
draft-ietf-httpbis/latest/p2-semantics.html
r604 r609 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">July 1 0, 2009</td>473 <td class="header right">July 13, 2009</td> 474 474 </tr> 475 475 </table> -
draft-ietf-httpbis/latest/p2-semantics.xml
r604 r609 212 212 <country>Germany</country> 213 213 </postal> 214 <phone>+49 251 2807760</phone> 215 <facsimile>+49 251 2807761</facsimile> 216 <email>julian.reschke@greenbytes.de</email> 217 <uri>http://greenbytes.de/tech/webdav/</uri> 214 <phone>+49 251 2807760</phone> 215 <facsimile>+49 251 2807761</facsimile> 216 <email>julian.reschke@greenbytes.de</email> 217 <uri>http://greenbytes.de/tech/webdav/</uri> 218 218 </address> 219 219 </author> … … 907 907 agent, the origin server can create the resource with that URI. If a 908 908 new resource is created at the request-target, the origin server &MUST; 909 909 inform the user agent 910 910 via the 201 (Created) response. If an existing resource is modified, 911 911 either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent -
draft-ietf-httpbis/latest/p3-payload.html
r604 r609 478 478 <tr> 479 479 <td class="header left"></td> 480 <td class="header right">July 1 0, 2009</td>480 <td class="header right">July 13, 2009</td> 481 481 </tr> 482 482 </table> -
draft-ietf-httpbis/latest/p3-payload.xml
r604 r609 182 182 <country>Germany</country> 183 183 </postal> 184 <phone>+49 251 2807760</phone> 185 <facsimile>+49 251 2807761</facsimile> 186 <email>julian.reschke@greenbytes.de</email> 187 <uri>http://greenbytes.de/tech/webdav/</uri> 184 <phone>+49 251 2807760</phone> 185 <facsimile>+49 251 2807761</facsimile> 186 <email>julian.reschke@greenbytes.de</email> 187 <uri>http://greenbytes.de/tech/webdav/</uri> 188 188 </address> 189 189 </author> -
draft-ietf-httpbis/latest/p4-conditional.html
r604 r609 467 467 <tr> 468 468 <td class="header left"></td> 469 <td class="header right">July 1 0, 2009</td>469 <td class="header right">July 13, 2009</td> 470 470 </tr> 471 471 </table> -
draft-ietf-httpbis/latest/p4-conditional.xml
r604 r609 175 175 <country>Germany</country> 176 176 </postal> 177 <phone>+49 251 2807760</phone> 178 <facsimile>+49 251 2807761</facsimile> 179 <email>julian.reschke@greenbytes.de</email> 180 <uri>http://greenbytes.de/tech/webdav/</uri> 177 <phone>+49 251 2807760</phone> 178 <facsimile>+49 251 2807761</facsimile> 179 <email>julian.reschke@greenbytes.de</email> 180 <uri>http://greenbytes.de/tech/webdav/</uri> 181 181 </address> 182 182 </author> -
draft-ietf-httpbis/latest/p5-range.html
r604 r609 467 467 <tr> 468 468 <td class="header left"></td> 469 <td class="header right">July 1 0, 2009</td>469 <td class="header right">July 13, 2009</td> 470 470 </tr> 471 471 </table> -
draft-ietf-httpbis/latest/p5-range.xml
r604 r609 170 170 <country>Germany</country> 171 171 </postal> 172 <phone>+49 251 2807760</phone> 173 <facsimile>+49 251 2807761</facsimile> 174 <email>julian.reschke@greenbytes.de</email> 175 <uri>http://greenbytes.de/tech/webdav/</uri> 172 <phone>+49 251 2807760</phone> 173 <facsimile>+49 251 2807761</facsimile> 174 <email>julian.reschke@greenbytes.de</email> 175 <uri>http://greenbytes.de/tech/webdav/</uri> 176 176 </address> 177 177 </author> … … 1304 1304 See Authors Section. 1305 1305 </t> 1306 1307 1308 </t> 1309 1310 1306 <t hangText="Intended usage:"> 1307 COMMON 1308 </t> 1309 <t hangText="Restrictions on usage:"> 1310 none 1311 1311 </t> 1312 1312 <t hangText="Author/Change controller:"> -
draft-ietf-httpbis/latest/p6-cache.html
r604 r609 473 473 <tr> 474 474 <td class="header left"></td> 475 <td class="header right">July 1 0, 2009</td>475 <td class="header right">July 13, 2009</td> 476 476 </tr> 477 477 </table> … … 871 871 </p> 872 872 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> 873 <p id="rfc.section.2.4.p.1">Checking with the origin server to see if a stale or otherwise unusable cached response can be reused is called "validating" 874 or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when the stored response is 875 valid. 876 </p> 877 <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> is used for this purpose. When a stored response includes one or more validators, such as the field values of an ETag or Last-Modified 878 header field, then a validating request <em class="bcp14">SHOULD</em> be made conditional to those field values. 879 </p> 880 <p id="rfc.section.2.4.p.3">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section 2.7</a>. 881 </p> 882 <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace 883 the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span> 884 </p> 885 <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (which <em class="bcp14">SHOULD</em> include the 111 warn-code; see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>) unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). 873 <p id="rfc.section.2.4.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not 874 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to 875 update it. This process is known as "validating" or "revalidating" the stored response. 876 </p> 877 <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header whose value is that of the Last-Modified header from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>) stored response, if available. 878 </p> 879 <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header whose value is that of the ETag header(s) from all responses stored for the requested URI, if 880 present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored 881 response. 882 </p> 883 <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section 2.7</a>. 884 </p> 885 <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional 886 request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span> 887 </p> 888 <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). 889 </p> 890 <p id="rfc.section.2.4.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the 891 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 892 of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache. <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: DISCUSS: Not sure if this is necessary.]</span> 886 893 </p> 887 894 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2> … … 898 905 attacks. 899 906 </p> 900 <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment. 6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TODO: "host part" needs to be specified better.]</span>907 <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: "host part" needs to be specified better.]</span> 901 908 </p> 902 909 <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI. … … 908 915 change at the origin server might not have gone through the cache where a response is stored. 909 916 </p> 910 <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment. 7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>917 <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 911 918 </p> 912 919 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2> 913 <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) alters the conditions under which a cache can use the response for subsequent requests. 914 </p> 915 <p id="rfc.section.2.6.p.2">When a cache receives a request that can be satisfied by a stored response that includes a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-headers in the presented request match the corresponding stored request-headers 916 from the original request. 917 </p> 918 <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 919 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 920 name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment" id="DISCUSS-header-specific-canonicalization">[<a href="#DISCUSS-header-specific-canonicalization" class="smpl">DISCUSS-header-specific-canonicalization</a>: Should the matching requirement be relaxed so that it would be ok to use a cached response if the selecting request headers 921 match after header-specific canonicalization? (see <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</a>)]</span> 922 </p> 920 <p id="rfc.section.2.6.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-headers nominated by the Vary header match in both the original request 921 (i.e., that associated with the stored response), and the presented request. 922 </p> 923 <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 924 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 925 name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 926 </p> 927 <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p> 923 928 <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted 924 929 by the origin server. 925 930 </p> 926 <p id="rfc.section.2.6.p.5">If no stored response matches, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request, and <em class="bcp14">SHOULD</em> include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with 927 304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used, that cached response <em class="bcp14">MUST</em> be used to satisfy the presented request, and <em class="bcp14">SHOULD</em> be used to update the corresponding stored response; see <a href="#combining.headers" title="Combining Responses">Section 2.7</a>. 928 </p> 929 <p id="rfc.section.2.6.p.6">If any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored 930 response. 931 </p> 932 <p id="rfc.section.2.6.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the 933 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 934 of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: DISCUSS: Not sure if this is necessary.]</span> 931 <p id="rfc.section.2.6.p.5">The stored response with matching selecting request-headers is known as the selected response.</p> 932 <p id="rfc.section.2.6.p.6">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section 2.4</a>. 935 933 </p> 936 934 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="combining.headers" href="#combining.headers">Combining Responses</a></h2> 937 <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response 938 with the new one, so that the updated response can be sent to the client. 939 </p> 940 <p id="rfc.section.2.7.p.2">If the status code is 304 (Not Modified), the cache <em class="bcp14">SHOULD</em> use the stored entity-body as the updated entity-body. If the status code is 206 (Partial Content) and the ETag or Last-Modified 941 headers match exactly, the cache <em class="bcp14">MAY</em> combine the stored entity-body in the stored response with the updated entity-body received in the response and use the result 942 as the updated entity-body (see <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). 943 </p> 944 <p id="rfc.section.2.7.p.3">The stored response headers are used for the updated response, except that </p> 935 <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"), 936 it needs to created an updated response by combining the stored response with the new one, so that the updated response can 937 be used to satisfy the request. 938 </p> 939 <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: cover case where INM with multiple etags was sent]</span> 940 </p> 941 <p id="rfc.section.2.7.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have ETags, and those ETags <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined. 942 </p> 943 <p id="rfc.section.2.7.p.4">The stored response headers are used as those of the updated response, except that </p> 945 944 <ul> 946 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning. 3" title="Warning">Section 3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response.947 </li> 948 <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the forwarded response.949 </li> 950 <li>any headers provided in the 304 or 206response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response.945 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the updated response. 946 </li> 947 <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the updated response. 948 </li> 949 <li>any headers provided in the new response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response. 951 950 </li> 952 951 </ul> 953 <p id="rfc.section.2.7.p. 4">A cache <em class="bcp14">MUST</em> also replace any stored headers with corresponding headers received in the incoming response, except for Warning headers as954 described immediately above. If a header field-name in the incoming response matches more than one header in the stored response,955 all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body.956 </p> 957 <p id="rfc.section.2.7.p. 5"> <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: ISSUE: discuss how to handle HEAD updates]</span>952 <p id="rfc.section.2.7.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced. 953 </p> 954 <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored. 955 </p> 956 <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span> 958 957 </p> 959 958 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1041 1040 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1042 1041 by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 1043 a stale response of any age. <span class="comment" id="rfc.comment.1 1">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: of any staleness? --mnot]</span></dd>1042 a stale response of any age. <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: of any staleness? --mnot]</span></dd> 1044 1043 </dl> 1045 1044 <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.m.3"></span> min-fresh … … 1429 1428 <td>http</td> 1430 1429 <td>standard</td> 1431 <td> <a href="#header.warning" id="rfc.xref.header.warning. 4" title="Warning">Section 3.6</a>1430 <td> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 3.6</a> 1432 1431 </td> 1433 1432 </tr> … … 1545 1544 <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 1546 1545 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1547 computed. (see also <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="#Part3" id="rfc.xref.Part3. 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>1548 </p> 1549 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.1 3">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>1546 computed. (see also <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="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1547 </p> 1548 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1550 1549 </p> 1551 1550 <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send … … 1554 1553 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) 1555 1554 </p> 1556 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning. 5" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.1555 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 1557 1556 </p> 1558 1557 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 1718 1717 <ul> 1719 1718 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/161">http://tools.ietf.org/wg/httpbis/trac/ticket/161</a>>: "base for numeric protocol elements" 1719 </li> 1720 </ul> 1721 <p id="rfc.section.C.8.p.2">Affected issues: </p> 1722 <ul> 1723 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>>: Vary and non-existant headers 1720 1724 </li> 1721 1725 </ul> … … 1803 1807 <li class="indline1">Pragma <a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.1</a></li> 1804 1808 <li class="indline1">Vary <a class="iref" href="#rfc.xref.header.vary.1">2.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>3.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">5.1</a></li> 1805 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2. 4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li>1809 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li> 1806 1810 </ul> 1807 1811 </li> … … 1877 1881 </ul> 1878 1882 </li> 1879 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">2.6</a>, <a class="iref" href="#Part3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part3.2">A.1</a><ul class="ind"> 1880 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.1">2.6</a></li> 1881 </ul> 1882 </li> 1883 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind"> 1883 <li class="indline1"><em>Part3</em> <a class="iref" href="#Part3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part3.1">A.1</a></li> 1884 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#rfc.xref.Part4.3">2.7</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind"> 1885 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.3">2.7</a></li> 1884 1886 <li class="indline1"><em>Section 6.6</em> <a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a></li> 1885 1887 </ul> 1886 1888 </li> 1887 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="# rfc.xref.Part5.3">2.7</a>, <a class="iref" href="#Part5"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part5.4">A.1</a><ul class="ind">1888 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a> , <a class="iref" href="#rfc.xref.Part5.3">2.7</a></li>1889 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#Part5"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind"> 1890 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a></li> 1889 1891 </ul> 1890 1892 </li> … … 1938 1940 </li> 1939 1941 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 1940 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2. 4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li>1942 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li> 1941 1943 </ul> 1942 1944 </li> -
draft-ietf-httpbis/latest/p7-auth.html
r604 r609 462 462 <tr> 463 463 <td class="header left"></td> 464 <td class="header right">July 1 0, 2009</td>464 <td class="header right">July 13, 2009</td> 465 465 </tr> 466 466 </table> -
draft-ietf-httpbis/latest/p7-auth.xml
r604 r609 168 168 <country>Germany</country> 169 169 </postal> 170 <phone>+49 251 2807760</phone> 171 <facsimile>+49 251 2807761</facsimile> 172 <email>julian.reschke@greenbytes.de</email> 173 <uri>http://greenbytes.de/tech/webdav/</uri> 170 <phone>+49 251 2807760</phone> 171 <facsimile>+49 251 2807761</facsimile> 172 <email>julian.reschke@greenbytes.de</email> 173 <uri>http://greenbytes.de/tech/webdav/</uri> 174 174 </address> 175 175 </author>
Note: See TracChangeset
for help on using the changeset viewer.