Dynamic image endpoints – think about conditional GETs

I’ve been looking at an issue recently on a site where there is a dynamic endpoint that serves up an image that is stored in a SQL database. The endpoint added the Cache-control: public header, so on the face of it looked like it had added client-side caching support.

By default if you don’t send either Cache-Control: max-age, or Expires headers then the user agent has been told that the resource can be cached, but has no way to know whether it has changed on the server. Based on this the user agent will send a conditional GET request to the server to find out if the resource has changed, or if it can be served directly from the local cache (this would look like a 304 response).

A conditional GET will compare versions of a resource based on either the Last-Modified header, or the ETag header. Generally these would have been sent in the original response for a resource. The client will then send either the If-None-Match, or If-Modified-Since headers in the GET request to indicate the resource should ONLY be sent by the server if it has changed.

In this case the dynamic endpoint had not been coded to support conditional GETs, so the images were getting fully downloaded on each request as a 200 response.

The simplest solution is to send Cache-control: max-age in order to allow the user agent to serve the resource directly from the cache without bothering with a conditional GET. Alternatively the endpoint has to check for conditional GET requests and change it’s behaviour to support sending a 304 response if the image hasn’t changed.

The best diagnostic tool to see what is going on is the Net tab in Firebug. This will allow you to check the request and response headers, the response codes, and user agent caching behaviour.