CODEWITHSUNDEEP
httpserveretag
michfuer
michfuer

Reputation: 119

How does a web server determine if an ETag value is current?

Example scenario

Say there's a resource at /some-view that displays a list based off a database query e.g.

Client X makes the first request to /some-view, the server processes the response, caches it, generates an etag, and sends that back with a 200.

Now some time has passed, and the list at /some-view includes another item

Assuming Client X sends the first request again, will the server respond with a 304 until another request, e.g. Client Y, forces the generation of a new etag value, or does the server actually process the response and compare that with the current etag to determine if it's still valid? Maybe different web servers handle it differently?

Upvotes: 2

Views: 646

Answers (2)

shaochuancs
shaochuancs

Reputation: 16226

There are 2 scenario of ETag: ETag for static resource (files), and ETag for dynamic query result (as described in question).

If "web server" means server software such as Apache or Nginx, it only provides ETag feature for static resource, and does not generate or update ETag automatically for dynamic result. For example, according to Nginx document:

Syntax: etag on | off;

Default: etag on;

Enables or disables automatic generation of the “ETag” response header field for static resources.

The reason is: web server software can listen to file change and update ETag, but it can never determine whether a bunch of data in Database is modified.

If "web server" means server side logic, you can generate and manage ETag yourself (e.g. a mapping of URL and its corresponding ETag). The only requirement due to RFC7232 is:

An origin server SHOULD send an ETag for any selected representation for which detection of changes can be reasonably and consistently determined

Thus, the key point here is "detection of changes" -- you can pickup the most appropriate solution:

  • Listen to write-resource operation, and update the ETag.
  • Query resource every 5 minutes in the background, and update ETag once something is changed.
  • "Client Y" solution described in question.
  • "process and compare" solution described in question.
  • more...

As long as the solution can detect the changes reasonably and consistently, it's a good solution.

Upvotes: 2

Willis Blackburn
Willis Blackburn

Reputation: 8204

If the response is generated dynamically, the server will actually have to generate it in order to produce the ETag and compare it with the request. If they match, then the server can avoid sending the response, but it can't avoid generating it in the first place, at least not in the general case (e.g., an ETag filter) where the ETag is just a hash of the response. Of course the ETag can be anything, so while for the general case the server has to generate the response, if you make your own ETag, you include some information in it that your server can use to figure out if it can just return 304 without having to generate the response.

Upvotes: 2

Related Questions