Trigger an image to be cached without returning the image data in the response

[infogulch]

Say I have a series of image urls that I would like to be pre-cached for some reason, say reducing first load time of a real client, or hiding the timing of the first load from the backend host. For such a use-case getting the image data itself back just to warm up the cache is not useful and wastes the client's and proxy's time and bandwidth.

Is there a request mode that triggers the caching logic like usual, but otherwise returns an empty response? Is this a reasonable thing to ask for?

[willnorris]

An HTTP HEAD request would do what you're asking. It will fetch the remote image and cache it if configured, but won't return the response. Would that work for your use case?

For example:

imageproxy -cache ./cache

curl -I http://localhost/x/https://willnorris.com/2013/12/small-things.jpg
HTTP/2 200 
server: nginx
date: Sun, 03 Oct 2021 15:07:18 GMT
content-type: image/jpeg
content-length: 182835
access-control-allow-origin: *
cache-control: max-age=31536000
content-security-policy: script-src 'none'
etag: "5eef9719-2ca33"
expires: Mon, 03 Oct 2022 15:07:18 GMT
last-modified: Sun, 21 Jun 2020 17:21:29 GMT
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-security-policy: default-src https: data: 'unsafe-inline' 'unsafe-eval'

tree ./cache
cache
├── 97
│   └── db
│       └── 97dbc19e788603129f686c59062593c7
└── 9e
    └── 52
        └── 9e52ef12a421cbe88a3ef2b024c1554e

[infogulch]

Oh good idea, I didn't even think of that. That covers my 99% of my use-case and as a bonus doesn't require any changes to the project at all!

The one thing that I might want to be different is for imageproxy to respond immediately, even before the downloading the image. A kind of fire-and-forget thing. But then again, getting the status, content-length, and content-type headers from the backend might be useful even when you're just warming up the cache. Anyways this detail is pretty deep in tradeoff space, and definitely premature in my case.

Thanks!