- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 29 Apr 2013 22:31:35 +1000
- To: Ken Murchison <murch@andrew.cmu.edu>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Ken, I re-opened this issue as a result: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/345 We didn't add Last-Modified (or rather, we added it and then took it out) because doing so would make some existant implementations non-conformant, and there isn't a clear win in interop or security by doing so. Also, ETag is used by caches to help differentiate the selected response, when multiple etags are sent in If-None-Match. That said, it's a good question as to why some things are required to be returned when they haven't changed, as this *does* represent a change from 2616; hence, the reopened issue. Cheers, On 29/04/2013, at 10:18 PM, Ken Murchison <murch@andrew.cmu.edu> wrote: > Any thoughts on this? > > > Ken Murchison wrote: >> Hi All, >> >> In re-reading the latest section 4.1, I'm wondering why ETag was singled out as being a MUST generate, while Last-Modified isn't. If the server is capable of generating both, shouldn't it return both, as it SHOULD for 200 responses (per section 2.4)? What if the client only supports Last-Modified and not ETag (e.g. used If-Modified-Since in its request)? >> >> That being said, if the representation hasn't been modified then presumably none of the validators changed. What's the point in returning any of them? Shouldn't it be all or nothing? Just trying to wrap my head around the logic behind singling out ETag over Last-Modified for 304. >> > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > -- Mark Nottingham http://www.mnot.net/
Received on Monday, 29 April 2013 12:32:02 UTC