Changeset 45 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

Dec 17, 2007, 8:39:10 PM (12 years ago)

Author:

fielding@…

Message:

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

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (3 diffs)

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

@@ -57 +57 @@
   <!ENTITY message-body               "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY message-transmission-req   "<xref target='Part1' x:rel='#message.transmission.requirements' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY clockless                  "<xref target='Part1' x:rel='#clockless.origin.server.operation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
 ]>
 <?rfc toc="yes" ?>
@@ -1184 +1183 @@
   <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
 <t>
-   If the client has performed a conditional GET request and access is
-   allowed, but the document has not been modified, the server &SHOULD;
-   respond with this status code. The 304 response &MUST-NOT; contain a
-   message-body, and thus is always terminated by the first empty line
-   after the header fields.
-</t>
-<t>
-   The response &MUST; include the following header fields:
-  <list style="symbols">
-    <t>Date, unless its omission is required by &clockless;</t>
-  </list>
-</t>
-<t>
-   If a clockless origin server obeys these rules, and proxies and
-   clients add their own Date to any response received without one (as
-   already specified by [RFC 2068], section <xref target="RFC2068" x:sec="14.19" x:fmt="number"/>), caches will operate
-   correctly.
-  <list style="symbols">
-    <t>ETag and/or Content-Location, if the header would have been sent
-        in a 200 response to the same request</t>
-    <t>Expires, Cache-Control, and/or Vary, if the field-value might
-        differ from that sent in any previous response for the same
-        variant</t>
-  </list>
-</t>
-<t>
-   If the conditional GET used a strong cache validator (see &caching;),
-   the response &SHOULD-NOT;  include other entity-headers.
-   Otherwise (i.e., the conditional GET used a weak validator), the
-   response &MUST-NOT; include other entity-headers; this prevents
-   inconsistencies between cached entity-bodies and updated headers.
-</t>
-<t>
-   If a 304 response indicates an entity not currently cached, then the
-   cache &MUST; disregard the response and repeat the request without the
-   conditional.
-</t>
-<t>
-   If a cache uses a received 304 response to update a cache entry, the
-   cache &MUST; update the entry to reflect any new field values given in
-   the response.
+   The response to the request has not been modified since the conditions
+   indicated by the client's conditional GET request, as defined in &conditional;.
 </t>
 </section>
@@ -1483 +1443 @@
 <t>
    The precondition given in one or more of the request-header fields
-   evaluated to false when it was tested on the server. This response
-   code allows the client to place preconditions on the current resource
-   metainformation (header field data) and thus prevent the requested
-   method from being applied to a resource other than the one intended.
+   evaluated to false when it was tested on the server, as defined in
+   &conditional;.
 </t>
 </section>