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

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

1 edited


  • draft-ietf-httpbis/latest/p4-conditional.xml

    r42 r45  
    1515  <!ENTITY ID-YEAR "2007">
    1616  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     17  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1718  <!ENTITY header-if-range            "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY header-vary                "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     21  <!ENTITY clockless                  "<xref target='Part1' x:rel='#clockless.origin.server.operation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2123<?rfc toc="yes" ?>
     228<section title="Status Code Definitions">
     229<section title="304 Not Modified" anchor="status.304">
     230  <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
     231  <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
     233   If the client has performed a conditional GET request and access is
     234   allowed, but the document has not been modified, the server &SHOULD;
     235   respond with this status code. The 304 response &MUST-NOT; contain a
     236   message-body, and thus is always terminated by the first empty line
     237   after the header fields.
     240   The response &MUST; include the following header fields:
     241  <list style="symbols">
     242    <t>Date, unless its omission is required by &clockless;</t>
     243  </list>
     246   If a clockless origin server obeys these rules, and proxies and
     247   clients add their own Date to any response received without one (as
     248   already specified by <xref target="RFC2068" />, section <xref target="RFC2068" x:sec="14.19" x:fmt="number"/>), caches will operate
     249   correctly.
     250  <list style="symbols">
     251    <t>ETag and/or Content-Location, if the header would have been sent
     252        in a 200 response to the same request</t>
     253    <t>Expires, Cache-Control, and/or Vary, if the field-value might
     254        differ from that sent in any previous response for the same
     255        variant</t>
     256  </list>
     259   If the conditional GET used a strong cache validator (see &caching;),
     260   the response &SHOULD-NOT;  include other entity-headers.
     261   Otherwise (i.e., the conditional GET used a weak validator), the
     262   response &MUST-NOT; include other entity-headers; this prevents
     263   inconsistencies between cached entity-bodies and updated headers.
     266   If a 304 response indicates an entity not currently cached, then the
     267   cache &MUST; disregard the response and repeat the request without the
     268   conditional.
     271   If a cache uses a received 304 response to update a cache entry, the
     272   cache &MUST; update the entry to reflect any new field values given in
     273   the response.
     277<section title="412 Precondition Failed" anchor="status.412">
     278  <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
     279  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
     281   The precondition given in one or more of the request-header fields
     282   evaluated to false when it was tested on the server. This response
     283   code allows the client to place preconditions on the current resource
     284   metainformation (header field data) and thus prevent the requested
     285   method from being applied to a resource other than the one intended.
    226290<section title="Weak and Strong Validators" anchor="weak.and.strong.validators">
     1041<reference anchor="RFC2068">
     1043<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
     1044<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
     1045<organization>University of California, Irvine, Department of Information and Computer Science</organization>
     1053<facsimile>+1 714 824 4056</facsimile>
     1055<author initials="J." surname="Gettys" fullname="Jim Gettys">
     1056<organization>MIT Laboratory for Computer Science</organization>
     1059<street>545 Technology Square</street>
     1064<facsimile>+1 617 258 8682</facsimile>
     1066<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
     1067<organization>Digital Equipment Corporation, Western Research Laboratory</organization>
     1070<street>250 University Avenue</street>
     1071<city>Palo Alto</city>
     1076<author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
     1077<organization>MIT Laboratory for Computer Science</organization>
     1080<street>545 Technology Square</street>
     1085<facsimile>+1 617 258 8682</facsimile>
     1087<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
     1088<organization>MIT Laboratory for Computer Science</organization>
     1091<street>545 Technology Square</street>
     1096<facsimile>+1 617 258 8682</facsimile>
     1098<date month="January" year="1997"/>
     1100<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t>
     1101<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front>
     1102<seriesInfo name="RFC" value="2068"/>
Note: See TracChangeset for help on using the changeset viewer.