Changeset 45
- Timestamp:
- 18/12/07 04:39:10 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r42 r45 57 57 <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 58 58 <!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'/>">60 59 ]> 61 60 <?rfc toc="yes" ?> … … 1184 1183 <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/> 1185 1184 <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;. 1227 1187 </t> 1228 1188 </section> … … 1483 1443 <t> 1484 1444 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;. 1489 1447 </t> 1490 1448 </section> -
draft-ietf-httpbis/latest/p4-conditional.xml
r42 r45 15 15 <!ENTITY ID-YEAR "2007"> 16 16 <!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'/>"> 17 18 <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!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'/>"> 20 22 ]> 21 23 <?rfc toc="yes" ?> … … 224 226 </section> 225 227 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 226 290 <section title="Weak and Strong Validators" anchor="weak.and.strong.validators"> 227 291 <t> … … 975 1039 </reference> 976 1040 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 977 1105 </references> 978 1106 </back>
Note: See TracChangeset
for help on using the changeset viewer.