Changeset 45


Ignore:
Timestamp:
Dec 17, 2007, 8:39:10 PM (12 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • 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'/>">
    6059]>
    6160<?rfc toc="yes" ?>
    … …  
    11841183  <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
    11851184<t>
    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;.
    12271187</t>
    12281188</section>
    … …  
    14831443<t>
    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;.
    14891447</t>
    14901448</section>

  • 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'/>">
    2022]>
    2123<?rfc toc="yes" ?>
    … …  
    224226</section>
    225227
     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=""/>
     232<t>
     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.
     238</t>
     239<t>
     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>
     244</t>
     245<t>
     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>
     257</t>
     258<t>
     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.
     264</t>
     265<t>
     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.
     269</t>
     270<t>
     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.
     274</t>
     275</section>
     276
     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=""/>
     280<t>
     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.
     286</t>
     287</section>
     288</section>
     289
    226290<section title="Weak and Strong Validators" anchor="weak.and.strong.validators">
    227291<t>
    … …  
    9751039</reference>
    9761040
     1041<reference anchor="RFC2068">
     1042<front>
     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>
     1046<address>
     1047<postal>
     1048<street/>
     1049<city>Irvine</city>
     1050<region>CA</region>
     1051<code>92717-3425</code>
     1052<country>US</country></postal>
     1053<facsimile>+1 714 824 4056</facsimile>
     1054<email>fielding@ics.uci.edu</email></address></author>
     1055<author initials="J." surname="Gettys" fullname="Jim Gettys">
     1056<organization>MIT Laboratory for Computer Science</organization>
     1057<address>
     1058<postal>
     1059<street>545 Technology Square</street>
     1060<city>Cambridge</city>
     1061<region>MA</region>
     1062<code>02139</code>
     1063<country>US</country></postal>
     1064<facsimile>+1 617 258 8682</facsimile>
     1065<email>jg@w3.org</email></address></author>
     1066<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
     1067<organization>Digital Equipment Corporation, Western Research Laboratory</organization>
     1068<address>
     1069<postal>
     1070<street>250 University Avenue</street>
     1071<city>Palo Alto</city>
     1072<region>CA</region>
     1073<code>94301</code>
     1074<country>US</country></postal>
     1075<email>mogul@wrl.dec.com</email></address></author>
     1076<author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
     1077<organization>MIT Laboratory for Computer Science</organization>
     1078<address>
     1079<postal>
     1080<street>545 Technology Square</street>
     1081<city>Cambridge</city>
     1082<region>MA</region>
     1083<code>02139</code>
     1084<country>US</country></postal>
     1085<facsimile>+1 617 258 8682</facsimile>
     1086<email>frystyk@w3.org</email></address></author>
     1087<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
     1088<organization>MIT Laboratory for Computer Science</organization>
     1089<address>
     1090<postal>
     1091<street>545 Technology Square</street>
     1092<city>Cambridge</city>
     1093<region>MA</region>
     1094<code>02139</code>
     1095<country>US</country></postal>
     1096<facsimile>+1 617 258 8682</facsimile>
     1097<email>timbl@w3.org</email></address></author>
     1098<date month="January" year="1997"/>
     1099<abstract>
     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"/>
     1103</reference>
     1104
    9771105</references>
    9781106</back>
Note: See TracChangeset for help on using the changeset viewer.