Changeset 860


Ignore:
Timestamp:
22/07/10 03:03:27 (13 years ago)
Author:
fielding@…
Message:

Addresses #69: Clarify "Requested Variant"

Eliminated that phrase.

Addresses #109: Clarify entity / representation / variant terminology

Replaced variant with representation.
Cleaned up p4 description of 304 and 206 status code

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

Legend:

Unmodified
Added
Removed

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

    r848 r860  
    357357</artwork></figure>
    358358<t>
    359    In this case, the response may use the gzip Content Coding or not.
    360    If it does, it might look like that:
     359   In this case, the response may or may not use the gzip content coding.
     360   If it does not, the response might look like:
    361361</t>
    362362<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
    … …  
    375375</x:span></artwork></figure>
    376376<t>
    377    A variant that does use gzip Content Coding would be:
     377   An alternative representation that does use gzip content coding would be:
    378378</t>
    379379<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
    … …  
    389389<x:note>
    390390  <t>
    391     <x:h>Note:</x:h> Content Codings are a property of the response
    392     entity, thus affect the Entity Tag. An alternative are Transfer
    393     Codings (&transfer-codings;) which apply only to the transfer of
    394     the message, and thus do not require assigning distinct entity tags.
     391    <x:h>Note:</x:h> Content codings are a property of the representation,
     392    so therefore an entity tag of an encoded representation must be distinct
     393    from an unencoded representation to prevent conflicts during cache updates
     394    and range requests.  In contrast, transfer codings (&transfer-codings;)
     395    apply only during message transfer and do not require distinct entity tags.
    395396  </t>
    396397</x:note>
    … …  
    410411</t>
    411412<t>
    412    The response &MUST; include the following header fields:
    413   <list style="symbols">
    414     <x:lt>
    415       <t>Date, unless its omission is required by &clockless;.</t>
    416       <t>
    417          If a clockless origin server obeys these rules, and proxies and
    418          clients add their own Date to any response received without one (as
    419          already specified by &header-date;, caches will operate
    420          correctly.</t>
    421     </x:lt>
    422     <x:lt>
    423       <t>ETag and/or Content-Location, if the header would have been sent
    424          in a 200 response to the same request.</t>
    425     </x:lt>
    426     <x:lt>
    427       <t>Expires, Cache-Control, and/or Vary, if the field-value might
    428          differ from that sent in any previous response for the same
    429          variant.</t>
    430     </x:lt>
    431   </list>
    432 </t>
    433 <t>
    434    If the conditional GET used a strong cache validator (see <xref target="weak.and.strong.validators"/>),
    435    the response &SHOULD-NOT;  include other entity-headers.
    436    Otherwise (i.e., the conditional GET used a weak validator), the
    437    response &MUST-NOT; include other entity-headers; this prevents
    438    inconsistencies between cached entity-bodies and updated headers.
    439 </t>
    440 <t>
    441    If a 304 response indicates an entity not currently cached, then the
    442    cache &MUST; disregard the response and repeat the request without the
    443    conditional.
     413   A 304 response &MUST; include a Date header field (&header-date;)
     414   unless its omission is required by &clockless;.  If a 200 response
     415   to the same request would have included any of the header fields
     416   Cache-Control, Content-Location, ETag, Expires, Last-Modified, or
     417   Vary, then those same header fields &MUST; be sent in a 304 response.
     418</t>
     419<t>
     420   Since the goal of a 304 response is to minimize information transfer
     421   when the recipient already has one or more cached representations,
     422   the response &SHOULD-NOT; include representation metadata other
     423   than the above listed fields unless said metadata exists for the
     424   purpose of guiding cache updates (e.g., future HTTP extensions).
     425</t>
     426<t>
     427   If a 304 response includes an entity-tag that indicates a
     428   representation not currently cached, then the recipient &MUST-NOT;
     429   use the 304 to update its own cache.  If that conditional request originated
     430   with an outbound client, such as a user agent with its own cache sending a
     431   conditional GET to a shared proxy, then the 304 response &MUST; be
     432   forwarded to the outbound client.  Otherwise, disregard the response
     433   and repeat the request without the conditional.
    444434</t>
    445435<t>
    … …  
    746736<t>
    747737   The "ETag" response-header field provides the current value of the
    748    entity tag (see <xref target="entity.tags"/>) for the requested variant,
    749    which may be used for comparison with other entities from the same resource
    750    (see <xref target="weak.and.strong.validators"/>).
     738   entity tag (see <xref target="entity.tags"/>) for one representation of
     739   the resource identified by the Effective Request URI.  An entity tag
     740   is intended for use as a resource-local identifier for differentiating
     741   between representations of the same resource that vary over time or via
     742   content negotiation (see <xref target="weak.and.strong.validators"/>).
    751743</t>
    752744<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/><iref primary="true" item="Grammar" subitem="ETag-v"/>
    … …  
    763755</artwork></figure>
    764756<t>
    765    The ETag response-header field value, an entity tag, provides for an
    766    "opaque" cache validator. This might allow more reliable validation
    767    in situations where it is inconvenient to store modification dates,
     757   An entity tag provides an "opaque" cache validator that allows for
     758   more reliable validation than modification dates in situations where
     759   it is inconvenient to store modification dates,
    768760   where the one-second resolution of HTTP date values is not
    769761   sufficient, or where the origin server wishes to avoid certain
    … …  
    858850<t>
    859851   The "If-Modified-Since" request-header field is used to make a request
    860    method conditional: if the requested variant has not been modified since the
    861    time specified in this field, the server will not return an entity; instead,
    862    a 304 (Not Modified) response will be returned.
     852   method conditional by date: if the representation that would have been
     853   transferred in a 200 response to a GET request has not been modified since
     854   the time specified in this field, then do not perform the method;
     855   instead, respond as detailed below.
    863856</t>
    864857<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><iref primary="true" item="Grammar" subitem="If-Modified-Since-v"/>
    … …  
    875868<t>
    876869   A GET method with an If-Modified-Since header and no Range header
    877    requests that the identified entity be transferred only if it has
     870   requests that the representation be transferred only if it has
    878871   been modified since the date given by the If-Modified-Since header.
    879872   The algorithm for determining this includes the following cases:
    … …  
    885878         invalid.</t>
    886879
    887       <t>If the variant has been modified since the If-Modified-Since
     880      <t>If the representation has been modified since the If-Modified-Since
    888881         date, the response is exactly the same as for a normal GET.</t>
    889882
    890       <t>If the variant has not been modified since a valid If-Modified-Since
    891          date, the server &SHOULD; return a 304 (Not
    892          Modified) response.</t>
     883      <t>If the representation has not been modified since a valid
     884         If-Modified-Since date, the server &SHOULD; return a
     885         304 (Not Modified) response.</t>
    893886  </list>
    894887</t>
    … …  
    10211014<t>
    10221015   The "If-Unmodified-Since" request-header field is used to make a request
    1023    method conditional. If the requested resource has not been modified
     1016   method conditional.  If the representation that would have been transferred
     1017   in a 200 response to a GET request on the same resource has not been modified
    10241018   since the time specified in this field, the server &SHOULD; perform the
    10251019   requested operation as if the If-Unmodified-Since header were not
    … …  
    10271021</t>
    10281022<t>
    1029    If the requested variant has been modified since the specified time,
     1023   If the representation has been modified since the specified time,
    10301024   the server &MUST-NOT; perform the requested operation, and &MUST; return
    10311025   a 412 (Precondition Failed).
    … …  
    10641058<t>
    10651059   The "Last-Modified" entity-header field indicates the date and time at
    1066    which the origin server believes the variant was last modified.
     1060   which the origin server believes the representation was last modified.
    10671061</t>
    10681062<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/><iref primary="true" item="Grammar" subitem="Last-Modified-v"/>
    … …  
    11051099   The Last-Modified entity-header field value is often used as a cache
    11061100   validator. In simple terms, a cache entry is considered to be valid
    1107    if the entity has not been modified since the Last-Modified value.
     1101   if the representation has not been modified since the Last-Modified value.
    11081102</t>
    11091103</section>

  • draft-ietf-httpbis/latest/p5-range.xml

    r859 r860  
    364364    </t>
    365365    <t>
    366         ETag and/or Content-Location, if the header would have been sent
    367         in a 200 response to the same request
    368     </t>
    369     <t>
    370         Expires, Cache-Control, and/or Vary, if the field-value might
    371         differ from that sent in any previous response for the same
    372         variant
     366        Cache-Control, ETag, Expires, Content-Location, Last-Modified,
     367        and/or Vary, if the header field would have been sent in a 200
     368        response to the same request
    373369    </t>
    374370  </list>
Note: See TracChangeset for help on using the changeset viewer.