Changeset 1920 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 01/10/12 01:14:48 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r1918 r1920 529 529 </section> 530 530 531 <section title="Selected Representation Header Fields" anchor="selected.representation">532 <t><iref primary="true" item="selected representation"/>533 We use the term "<x:dfn>selected representation</x:dfn>" to refer to the534 the current representation of a target resource that would have been535 selected in a successful response if the same request had used the536 method GET and excluded any conditional request header fields.537 </t>538 <t>539 Additional header fields define metadata about the selected540 representation, which might differ from the representation included541 in the message for responses to some state-changing methods.542 The following header fields are defined as selected representation543 metadata:544 </t>545 <texttable align="left">546 <ttcol>Header Field Name</ttcol>547 <ttcol>Defined in...</ttcol>548 549 <c>ETag</c> <c>&header-etag;</c>550 <c>Last-Modified</c> <c>&header-last-modified;</c>551 </texttable>552 </section>553 554 531 <section title="Representation Data" anchor="representation.data"> 555 532 <x:anchor-alias value="representation-data"/> … … 3261 3238 <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol> 3262 3239 3240 <c>Age</c> <c>&header-age;</c> 3241 <c>Date</c> <c><xref target="header.date"/></c> 3263 3242 <c>Location</c> <c><xref target="header.location"/></c> 3264 3243 <c>Retry-After</c> <c><xref target="header.retry-after"/></c> 3265 3244 </texttable> 3245 3246 <section title="Date" anchor="header.date"> 3247 <iref primary="true" item="Date header field" x:for-anchor=""/> 3248 <x:anchor-alias value="Date"/> 3249 <t> 3250 The "Date" header field represents the date and time at which 3251 the message was originated, having the same semantics as the Origination 3252 Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. 3253 The field value is an HTTP-date, as defined in <xref target="http.date"/>; 3254 it &MUST; be sent in rfc1123-date format. 3255 </t> 3256 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/> 3257 <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref> 3258 </artwork></figure> 3259 <t> 3260 An example is 3261 </t> 3262 <figure><artwork type="example"> 3263 Date: Tue, 15 Nov 1994 08:12:31 GMT 3264 </artwork></figure> 3265 <t> 3266 Origin servers &MUST; include a Date header field in all responses, 3267 except in these cases: 3268 <list style="numbers"> 3269 <t>If the response status code is <x:ref>100 (Continue)</x:ref> or 3270 <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a 3271 Date header field, at the server's option.</t> 3272 3273 <t>If the response status code conveys a server error, e.g., <x:ref>500 3274 (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>, 3275 and it is inconvenient or impossible to generate a valid Date.</t> 3276 3277 <t>If the server does not have a clock that can provide a 3278 reasonable approximation of the current time, its responses 3279 &MUST-NOT; include a Date header field.</t> 3280 </list> 3281 </t> 3282 <t> 3283 A received message that does not have a Date header field &MUST; be 3284 assigned one by the recipient if the message will be cached by that 3285 recipient. 3286 </t> 3287 <t> 3288 Clients can use the Date header field as well; in order to keep request 3289 messages small, they are advised not to include it when it doesn't convey 3290 any useful information (as is usually the case for requests that do not 3291 contain a payload). 3292 </t> 3293 <t> 3294 The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and 3295 time subsequent to the generation of the message. It &SHOULD; represent 3296 the best available approximation of the date and time of message 3297 generation, unless the implementation has no means of generating a 3298 reasonably accurate date and time. In theory, the date ought to 3299 represent the moment just before the payload is generated. In 3300 practice, the date can be generated at any time during the message 3301 origination without affecting its semantic value. 3302 </t> 3303 </section> 3266 3304 3267 3305 <section title="Location" anchor="header.location"> … … 3367 3405 </section> 3368 3406 3369 <section title="Cache-related" anchor="response.cache.related"> 3370 <t> 3371 Cache-related response header fields provide metadata about the message 3372 in order to assist downstream caches. 3407 <section title="Selected Representation Header Fields" anchor="selected.representation"> 3408 <t><iref primary="true" item="selected representation"/> 3409 We use the term "<x:dfn>selected representation</x:dfn>" to refer to the 3410 the current representation of a target resource that would have been 3411 selected in a successful response if the same request had used the 3412 method GET and excluded any conditional request header fields. 3413 </t> 3414 <t> 3415 Additional header fields define metadata about the selected 3416 representation, which might differ from the representation included 3417 in the message for responses to some state-changing methods. 3418 The following header fields are defined as selected representation 3419 metadata: 3373 3420 </t> 3374 3421 <texttable align="left"> 3375 <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol> 3376 3377 <c>Age</c> <c>&header-age;</c> 3378 <c>Date</c> <c><xref target="header.date"/></c> 3422 <ttcol>Header Field Name</ttcol> 3423 <ttcol>Defined in...</ttcol> 3424 3425 <c>ETag</c> <c>&header-etag;</c> 3426 <c>Last-Modified</c> <c>&header-last-modified;</c> 3379 3427 <c>Vary</c> <c><xref target="header.vary"/></c> 3380 3428 </texttable> 3381 3382 <section title="Date" anchor="header.date">3383 <iref primary="true" item="Date header field" x:for-anchor=""/>3384 <x:anchor-alias value="Date"/>3385 <t>3386 The "Date" header field represents the date and time at which3387 the message was originated, having the same semantics as the Origination3388 Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.3389 The field value is an HTTP-date, as defined in <xref target="http.date"/>;3390 it &MUST; be sent in rfc1123-date format.3391 </t>3392 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>3393 <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>3394 </artwork></figure>3395 <t>3396 An example is3397 </t>3398 <figure><artwork type="example">3399 Date: Tue, 15 Nov 1994 08:12:31 GMT3400 </artwork></figure>3401 <t>3402 Origin servers &MUST; include a Date header field in all responses,3403 except in these cases:3404 <list style="numbers">3405 <t>If the response status code is <x:ref>100 (Continue)</x:ref> or3406 <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a3407 Date header field, at the server's option.</t>3408 3409 <t>If the response status code conveys a server error, e.g., <x:ref>5003410 (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,3411 and it is inconvenient or impossible to generate a valid Date.</t>3412 3413 <t>If the server does not have a clock that can provide a3414 reasonable approximation of the current time, its responses3415 &MUST-NOT; include a Date header field.</t>3416 </list>3417 </t>3418 <t>3419 A received message that does not have a Date header field &MUST; be3420 assigned one by the recipient if the message will be cached by that3421 recipient.3422 </t>3423 <t>3424 Clients can use the Date header field as well; in order to keep request3425 messages small, they are advised not to include it when it doesn't convey3426 any useful information (as is usually the case for requests that do not3427 contain a payload).3428 </t>3429 <t>3430 The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and3431 time subsequent to the generation of the message. It &SHOULD; represent3432 the best available approximation of the date and time of message3433 generation, unless the implementation has no means of generating a3434 reasonably accurate date and time. In theory, the date ought to3435 represent the moment just before the payload is generated. In3436 practice, the date can be generated at any time during the message3437 origination without affecting its semantic value.3438 </t>3439 </section>3440 3429 3441 3430 <section anchor="header.vary" title="Vary">
Note: See TracChangeset
for help on using the changeset viewer.