Ignore:
Timestamp:
16/07/12 06:22:34 (8 years ago)
Author:
fielding@…
Message:

p4: Add a section for precedence of conditional request fields and remove

paragraphs that say it isn't defined. Addresses #241
Clarify that If-Modified-Since only applies to GET and HEAD. Addresses #371

also generated HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1796 r1799  
    751751   This section defines the syntax and semantics of HTTP/1.1 header fields
    752752   for applying preconditions on requests.
     753   <xref target="precedence"/> defines the order of evaluation when
     754   more than one precondition is present in a request.
    753755</t>
    754756
     
    807809  If-Match: *
    808810</artwork></figure>
    809 <t>
    810    The result of a request having both an If-Match header field and
    811    either an <x:ref>If-None-Match</x:ref> or an <x:ref>If-Modified-Since</x:ref>
    812    header field is undefined by this specification.
    813 </t>
    814811</section>
    815812
     
    885882  If-None-Match: *
    886883</artwork></figure>
    887 <t>
    888    The result of a request having both an If-None-Match header field and
    889    either an <x:ref>If-Match</x:ref> or an <x:ref>If-Unmodified-Since</x:ref>
    890    header field is undefined by this specification.
    891 </t>
    892884</section>
    893885
     
    897889  <x:anchor-alias value="If-Modified-Since"/>
    898890<t>
    899    The "If-Modified-Since" header field can be used to make a request
    900    method conditional by modification date: if the selected representation
     891   The "If-Modified-Since" header field can be used with GET or HEAD to make
     892   the method conditional by modification date: if the selected representation
    901893   has not been modified since the time specified in this field, then
    902894   do not perform the request method; instead, respond as detailed below.
     
    968960  </list>
    969961</t>
    970 <t>
    971    The result of a request having both an If-Modified-Since header field
    972    and either an <x:ref>If-Match</x:ref> or an <x:ref>If-Unmodified-Since</x:ref>
    973    header field is undefined by this specification.
    974 </t>
    975962</section>
    976963
     
    1006993<t>
    1007994   If the specified date is invalid, the header field &MUST; be ignored.
    1008 </t>
    1009 <t>
    1010    The result of a request having both an If-Unmodified-Since header
    1011    field and either an <x:ref>If-None-Match</x:ref> or an <x:ref>If-Modified-Since</x:ref>
    1012    header field is undefined by this specification.
    1013995</t>
    1014996</section>
     
    10881070</t>
    10891071</section>
     1072</section>
     1073
     1074<section title="Precedence" anchor="precedence">
     1075<t>
     1076   When more than one conditional request header field is present in a request,
     1077   the order in which the fields are evaluated becomes important. In practice,
     1078   the fields defined in this document are consistently implemented in a
     1079   single, logical order, due to the fact that entity tags are presumed to be
     1080   more accurate than date validators. For example, the only reason to send
     1081   both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in the same GET request is to
     1082   support intermediary caches that might not have implemented <x:ref>If-None-Match</x:ref>,
     1083   so it makes sense to ignore the <x:ref>If-Modified-Since</x:ref> when entity tags are
     1084   understood and available for the selected representation.
     1085</t>
     1086<t>
     1087   The general rule of conditional precedence is that exact match conditions
     1088   are evaluated before cache-validating conditions and, within that order,
     1089   last-modified conditions are only evaluated if the corresponding
     1090   entity tag condition is not present (or not applicable because the
     1091   selected representation does not have an entity tag).
     1092</t>
     1093<t>
     1094   Specifically, the fields defined by this specification are evaluated
     1095   as follows:
     1096   <list style="numbers">
     1097     <t>When <x:ref>If-Match</x:ref> is present, evaluate it:
     1098       <list style="symbols">
     1099         <t>if true, continue to step 3</t>
     1100         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref></t>
     1101       </list>
     1102     </t>
     1103     <t>When <x:ref>If-Match</x:ref> is not present and
     1104        <x:ref>If-Unmodified-Since</x:ref> is present, evaluate it:
     1105       <list style="symbols">
     1106         <t>if true, continue to step 3</t>
     1107         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref></t>
     1108       </list>
     1109     </t>
     1110     <t>When the method is GET and both <x:ref>Range</x:ref> and
     1111        <x:ref>If-Range</x:ref> are present, evaluate it:
     1112       <list style="symbols">
     1113         <t>if the validator matches, respond <x:ref>206 (Partial Content)</x:ref></t>
     1114         <t>if the validator does not match, respond <x:ref>200 (OK)</x:ref></t>
     1115       </list>
     1116     </t>
     1117     <t>When <x:ref>If-None-Match</x:ref> is present, evaluate it:
     1118       <list style="symbols">
     1119         <t>if true, all conditions are met</t>
     1120         <t>if false for GET/HEAD, respond <x:ref>304 (Not Modified)</x:ref></t>
     1121         <t>if false for other methods, respond <x:ref>412 (Precondition Failed)</x:ref></t>
     1122       </list>
     1123     </t>
     1124     <t>When the method is GET or HEAD,
     1125        <x:ref>If-None-Match</x:ref> is not present, and
     1126        <x:ref>If-Modified-Since</x:ref> is present, evaluate it:
     1127       <list style="symbols">
     1128         <t>if true, all conditions are met</t>
     1129         <t>if false, respond <x:ref>304 (Not Modified)</x:ref></t>
     1130       </list>
     1131     </t>
     1132   </list>
     1133</t>
     1134<t>
     1135   Any extension to HTTP/1.1 that defines additional conditional request
     1136   header fields ought to define its own expectations regarding the order
     1137   for evaluating such fields in relation to those defined in this document
     1138   and other conditionals that might be found in practice.
     1139</t>
    10901140</section>
    10911141
Note: See TracChangeset for help on using the changeset viewer.