W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Until HTTP header when the representation will disappear in the future

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 12 Jun 2013 22:22:05 +1200
Message-ID: <51B84BCD.7030003@treenet.co.nz>
To: Karl Dubost <karl@la-grange.net>
CC: ietf-http-wg@w3.org
On 12/06/2013 8:02 p.m., Karl Dubost wrote:
> Amos Jeffries [2013-06-12T16:12]:
>> A combination of Expires (and/or max-age=N) and Cache-Control:must-revalidate serve this purpose.
> Example:
> HTTP BIS semantics spec, in the content has a "Expires: August 27, 2013"
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22
> But if I do:
> → http HEAD http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22
> HTTP/1.1 200 OK
> Accept-Ranges: bytes
> Content-Encoding: gzip
> Content-Location: draft-ietf-httpbis-p2-semantics-22.html
> Content-Type: text/html; charset=UTF-8
> Date: Wed, 12 Jun 2013 07:55:45 GMT
> ETag: "186e6bd-4b989-4dbc6c4497a80;4def056fb837d"
> Last-Modified: Fri, 03 May 2013 02:04:10 GMT
> Server: Apache/2.2.22 (Debian)
> TCN: choice
> Vary: negotiate,Accept-Encoding
> And the spec
> Hypertext Transfer Protocol (HTTP/1.1): Caching
> http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22#section-7.3
> says about Expires.
>     The "Expires" header field gives the date/time after which the
>     response is considered stale.  See Section 4.1 for further discussion
>     of the freshness model.
>     The presence of an Expires field does not imply that the original
>     resource will change or cease to exist at, before, or after that
>     time.
> It doesn't have the same semantics. Caching vs Information on the representation.

The use-cases you presented for the new header from DRM to legality to 
maintenance downtime were all about what gets delivered (representation 
/ cached copy). Not meta data describing the contents. And images do 
have embeded meta data.

Notice that what I posted was not *only* Expires. It was a combination 
of Expires plus must-revalidate. Expires which flags a timestamp where 
*something* is supposed to have happened to the resource (without saying 
what). The addition of must-revalidate forces a check with the origin 
after that timestamp, which causes all the agents to fetch whatever you 
turn the resource into in that new time bracket (that 410 gone or whatever).

What use is a new header if it is going to take time to roll out, 
duplicates existing capabilities, and will probably act as a source for 
contradictory input to HTTP implementations? (ie invalid at timestamp V, 
Expires at timestamp V+M, may be served stale until V+M+N with arbitrary 
values for V, M, and N being added and removed at it transits the network)

>    Just asking maybe HTTP is not the right place to express it, though in case of an image it is difficult to do without HTTP.

Received on Wednesday, 12 June 2013 10:22:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC