1

I am working on a new API. With ETags enabled, Chrome always conditionally GETs a resource with a long cache lifetime, that is, Chrome no longer uses the cached version without first confirming the ETag.

Is this how ETags are supposed to work with GET?

If so, and considering that I don't need them for update race-checking, I will remove the ETags and alleviate the extra work my server is doing.

Edit

I would have expected Chrome to use the cached item according to the max-age until it expires and then use the conditional GET to update its cached-item.

As I write this, it has now occurred to me that it would not be able to 'update its cached-item' since the 304 contains no max-age to use to extend the expiry time.

So I guess with ETags enabled, a client will always conditionally GET unless there's a good reason to use the cached version, such as no network.

Thus, it appears that ETags harm server performance when no concurrency control is needed.

Edit

I think I've already guessed the answer (above) but here's the question in a nutshell:

When ETags are enabled and the Max-Age is far in the future, should User Agents always use conditional GET instead of using the previously cached, fresh response?

Luke Puplett
  • 42,091
  • 47
  • 181
  • 266

2 Answers2

1

How you load your page in the browser might be relevant here:

  • If you press Ctrl and reload the page using the refresh button, that will cause an unconditional reload of your resources with 200s returned.
  • If you just reload using the refresh button (or equivalent key like F5), conditional requests will be sent and 304s will be returned for static resources.
  • If you press enter in the address box, add the page to your bookmarks and load from there, or visit the page from a hyperlink, the cache max-age should work as expected.
deepkimo
  • 3,187
  • 3
  • 23
  • 21
0

With ETags enabled, Chrome always conditionally GETs a resource with a long cache lifetime, [...] Is this how ETags are supposed to work with GET?

The answer is in the RFC:

10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code.

So, yes.

If this is not the answer you expect, you might want to include some actual traffic in your question that shows the order of request-response pairs that you expect and that you actually get.

considering that I don't need them for update race-checking

If you're not going to use conditional requests (If-Match and the likes), you may indeed omit the ETag calculation and processing.

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • "If the client has performed a conditional GET" - what I'm surprised about is that the client (Chrome) always conditionally GETs rather than just when it needs to update a stale cached rep. – Luke Puplett Jul 08 '13 at 11:27
  • See for example [this](http://stackoverflow.com/questions/824152/what-takes-precedence-the-etag-or-last-modified-http-header) question, though it's still not clear to me what you mean to ask. Is it along the lines of _"Should an HTTP client send a GET request for a cached entitiy with a future Expires header, if an ETag was also returned for the entity"_? – CodeCaster Jul 08 '13 at 11:33
  • That's not the same, that's about ETag vs. Last-Modified not Expires. – Luke Puplett Jul 09 '13 at 11:01
  • @LukePuplett then what **is** your question? – CodeCaster Jul 09 '13 at 11:46