18/12/07 04:39:10 (14 years ago)

Move definitions of 304 and 412 to p4 (conditional requests).

1 edited


  • draft-ietf-httpbis/latest/p2-semantics.xml

    r42 r45  
    5757  <!ENTITY message-body               "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5858  <!ENTITY message-transmission-req   "<xref target='Part1' x:rel='#message.transmission.requirements' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    59   <!ENTITY clockless                  "<xref target='Part1' x:rel='#clockless.origin.server.operation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    6160<?rfc toc="yes" ?>
    11841183  <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
    1186    If the client has performed a conditional GET request and access is
    1187    allowed, but the document has not been modified, the server &SHOULD;
    1188    respond with this status code. The 304 response &MUST-NOT; contain a
    1189    message-body, and thus is always terminated by the first empty line
    1190    after the header fields.
    1191 </t>
    1192 <t>
    1193    The response &MUST; include the following header fields:
    1194   <list style="symbols">
    1195     <t>Date, unless its omission is required by &clockless;</t>
    1196   </list>
    1197 </t>
    1198 <t>
    1199    If a clockless origin server obeys these rules, and proxies and
    1200    clients add their own Date to any response received without one (as
    1201    already specified by [RFC 2068], section <xref target="RFC2068" x:sec="14.19" x:fmt="number"/>), caches will operate
    1202    correctly.
    1203   <list style="symbols">
    1204     <t>ETag and/or Content-Location, if the header would have been sent
    1205         in a 200 response to the same request</t>
    1206     <t>Expires, Cache-Control, and/or Vary, if the field-value might
    1207         differ from that sent in any previous response for the same
    1208         variant</t>
    1209   </list>
    1210 </t>
    1211 <t>
    1212    If the conditional GET used a strong cache validator (see &caching;),
    1213    the response &SHOULD-NOT;  include other entity-headers.
    1214    Otherwise (i.e., the conditional GET used a weak validator), the
    1215    response &MUST-NOT; include other entity-headers; this prevents
    1216    inconsistencies between cached entity-bodies and updated headers.
    1217 </t>
    1218 <t>
    1219    If a 304 response indicates an entity not currently cached, then the
    1220    cache &MUST; disregard the response and repeat the request without the
    1221    conditional.
    1222 </t>
    1223 <t>
    1224    If a cache uses a received 304 response to update a cache entry, the
    1225    cache &MUST; update the entry to reflect any new field values given in
    1226    the response.
     1185   The response to the request has not been modified since the conditions
     1186   indicated by the client's conditional GET request, as defined in &conditional;.
    14841444   The precondition given in one or more of the request-header fields
    1485    evaluated to false when it was tested on the server. This response
    1486    code allows the client to place preconditions on the current resource
    1487    metainformation (header field data) and thus prevent the requested
    1488    method from being applied to a resource other than the one intended.
     1445   evaluated to false when it was tested on the server, as defined in
     1446   &conditional;.
Note: See TracChangeset for help on using the changeset viewer.