Ignore:
Timestamp:
Jun 23, 2012, 4:27:41 AM (7 years ago)
Author:
julian.reschke@…
Message:

tune conformance requirements (see #271)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1689 r1691  
    301301   received.  However, if a resource has distinct representations that differ
    302302   only in their metadata, such as might occur with content negotiation over
    303    media types that happen to share the same data format, then a server
    304    &SHOULD; incorporate additional information in the validator to
     303   media types that happen to share the same data format, then the origin
     304   server &SHOULD; incorporate additional information in the validator to
    305305   distinguish those representations and avoid confusing cache behavior.
    306306</t>
     
    312312   representations of the resource, or due to a desire by the resource owner
    313313   to group representations by some self-determined set of equivalency
    314    rather than unique sequences of data.  A weak entity-tag &SHOULD; change
    315    whenever the origin server considers prior representations to be
    316    unacceptable as a substitute for the current representation. In other
    317    words, a weak entity-tag &SHOULD; change whenever the origin server wants
    318    caches to invalidate old responses.
     314   rather than unique sequences of data.  An origin server &SHOULD; change a
     315   weak entity-tag whenever it considers prior representations to be
     316   unacceptable as a substitute for the current representation. In other words,
     317   a weak entity-tag ought to change whenever the origin server wants caches to
     318   invalidate old responses.
    319319</t>
    320320<t>
     
    715715      last-modified values received or used by these systems will
    716716      support transparent and efficient caching, and so HTTP/1.1 origin
    717       servers should provide Last-Modified values. In those rare cases
     717      servers still ought to provide Last-Modified values. In those rare cases
    718718      where the use of a Last-Modified value as a validator by an
    719719      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
     
    735735  <x:anchor-alias value="If-Match"/>
    736736<t>
    737    The "If-Match" header field &MAY; be used to make a request method
     737   The "If-Match" header field can be used to make a request method
    738738   conditional on the current existence or value of an entity-tag for
    739739   one or more representations of the target resource.  If-Match is
     
    787787  <x:anchor-alias value="If-None-Match"/>
    788788<t>
    789    The "If-None-Match" header field &MAY; be used to make a request method
     789   The "If-None-Match" header field can be used to make a request method
    790790   conditional on not matching any of the current entity-tag values for
    791791   representations of the target resource.  If-None-Match is primarily
     
    798798</t>
    799799<t>
    800    If-None-Match &MAY; also be used with a value of "*" to prevent an unsafe
     800   If-None-Match can also be used with a value of "*" to prevent an unsafe
    801801   request method (e.g., PUT) from inadvertently modifying an existing
    802802   representation of the target resource when the client believes that
     
    857857  <x:anchor-alias value="If-Modified-Since"/>
    858858<t>
    859    The "If-Modified-Since" header field &MAY; be used to make a request
     859   The "If-Modified-Since" header field can be used to make a request
    860860   method conditional by modification date: if the selected representation
    861861   has not been modified since the time specified in this field, then
     
    940940  <x:anchor-alias value="If-Unmodified-Since"/>
    941941<t>
    942    The "If-Unmodified-Since" header field &MAY; be used to make a request
     942   The "If-Unmodified-Since" header field can be used to make a request
    943943   method conditional by modification date: if the selected representation
    944944   has been modified since the time specified in this field, then the
     
    959959</artwork></figure>
    960960<t>
    961    If the request normally (i.e., without the If-Unmodified-Since
     961   If a request normally (i.e., in absence of the If-Unmodified-Since
    962962   header field) would result in anything other than a 2xx or 412 status code,
    963963   the If-Unmodified-Since header field &SHOULD; be ignored.
Note: See TracChangeset for help on using the changeset viewer.