ETag implementation in ASP.Net Core

Friday, 20 August 2021
ASP.NET ETag REST API

As we all know, HTTP protocol mostly works based on the request and response mechanism. The client - the user's Web browser - initiates a request and the request is sent to the server. The server processes the incoming request and sends back a proper response to the client and these steps repeat.

Each request and response force data to be transferred over network. The more data, the more response time and also the more the user is charged. So it is wise to cut down the amount of data that transfers between the server and its clients.

Entity tag - or ETag for short - is a versioning mechanism inside HTTP. When using ETag, the client is able tell the server which version of the requested resource has already been asked and cached by it and the server is able to permit the client to used its cached version of the resource instead of sending same unchanged data over and over again.

Another use of ETag is avoiding mid-air collisions. When the client sends an edit request, it sends the version of the resource it is requesting to be edited along with the request allowing the server to check whether the client data is editing the latest version of not. This can control some optimistic concurrency problems.

Technical talks

Now that you know what ETag is all about, let's see how it actually works. There are three HTTP header involved: - ETag - If-None-Match - If-Match

Caching

The following steps take place when ETag is used: 1. Client asks for a resource 2. Server sends the resource back to the client. The response has an ETag header

ETag: "<version1>"
  1. Client caches the received resource along with its ETag (version).
  2. Client asks for the same resource again. This time it informs server that it has already have version1 using the following header
If-None-Match: "<version1>"
  1. Server either sends version2 of the resource with its new ETag and the process goes to step 3
ETag: "<version2>"
  1. Or if the resource has not changed, 304 Not Modified is send back to the client meaning the cached version is still valid and the process goes to step 3

Handling concurrency issues

The following steps take place here: 1. Client asks for a resource 2. Server sends the resource back to the client. The response has an ETag header

ETag: "<version1>"
  1. clients sends an edit request (using HTTP PUT). It also informs the server which version of the resource its is trying to edit by sending the following header
If-Match: "<version1>"
  1. server either edits the resource,
  2. or sends 412 Precondition Failed back to the client meaning cache version is not the latest version anymore and it is not safe to apply any modification to the resource based on this outdated version.

ETag values can be any ASCII string. Normally they are generated using hash functions so in real life you would see something like this

ETag: "68588518948ca8e0e2a9e479fcb19e9e"

and keep in mind that ETag values has no special meaning for the client. It is completely opaque there. All processes that need to be done (generating, comparing, ...) are taken place solely by the server and inside the server.

In part two we will create a very simple yet working ASP.Net core application that uses ETag.

Top