14.27 If-Range
If a client has a partial copy of an entity in its cache, and wishes
to have an up-to-date copy of the entire entity in its cache, it
could use the Range request-header with a conditional GET (using
either or both of If-Unmodified-Since and If-Match.) However, if the
condition fails because the entity has been modified, the client
would then have to make a second request to obtain the entire current
entity-body.
The If-Range header allows a client to "short-circuit" the second
request. Informally, its meaning is `if the entity is unchanged, send
me the part(s) that I am missing; otherwise, send me the entire new
entity.'
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
If the client has no entity tag for an entity, but does have a Last-
Modified date, it may use that date in a If-Range header. (The server
can distinguish between a valid HTTP-date and any form of entity-tag
by examining no more than two characters.) The If-Range header should
only be used together with a Range header, and must be ignored if the
request does not include a Range header, or if the server does not
support the sub-range operation.
Fielding, et. al. Standards Track [Page 123]
RFC 2068 HTTP/1.1 January 1997
If the entity tag given in the If-Range header matches the current
entity tag for the entity, then the server should provide the
specified sub-range of the entity using a 206 (Partial content)
response. If the entity tag does not match, then the server should
return the entire entity using a 200 (OK) response.
14.28 If-Unmodified-Since
The If-Unmodified-Since request-header field is used with a method to
make it conditional. If the requested resource has not been modified
since the time specified in this field, the server should perform the
requested operation as if the If-Unmodified-Since header were not
present.
If the requested variant has been modified since the specified time,
the server MUST NOT perform the requested operation, and MUST return
a 412 (Precondition Failed).
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
An example of the field is:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If the request normally (i.e., without the If-Unmodified-Since
header) would result in anything other than a 2xx status, the If-
Unmodified-Since header should be ignored.
If the specified date is invalid, the header is ignored.
14.29 Last-Modified
The Last-Modified entity-header field indicates the date and time at
which the origin server believes the variant was last modified.
Last-Modified = "Last-Modified" ":" HTTP-date
An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
The exact meaning of this header field depends on the implementation
of the origin server and the nature of the original resource. For
files, it may be just the file system last-modified time. For
entities with dynamically included parts, it may be the most recent
of the set of last-modify times for its component parts. For database
gateways, it may be the last-update time stamp of the record. For
virtual objects, it may be the last time the internal state changed.
Fielding, et. al. Standards Track [Page 124]
RFC 2068 HTTP/1.1 January 1997
An origin server MUST NOT send a Last-Modified date which is later
than the server's time of message origination. In such cases, where
the resource's last modification would indicate some time in the
future, the server MUST replace that date with the message
origination date.
An origin server should obtain the Last-Modified value of the entity
as close as possible to the time that it generates the Date value of
its response. This allows a recipient to make an accurate assessment
of the entity's modification time, especially if the entity changes
near the time that the response is generated.
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.