Give /v1/e/ ETag, 304 and HEAD as /v1/image/ has (closes #84)
check / check (push) Failing after 2s

The ETag and If-None-Match code of the /v1/image/ handler becomes
notModified, which both image handlers call; /v1/e/ answers HEAD with
the headers only and is routed for HEAD. HandleImageEnc was at the
80-line function limit, so its token checks move unchanged into
parseImageEncRequest, as parseImageRequest does for /v1/image/. No Vary
is added: only the image routes' CORS headers depend on a request
header, and go-chi/cors already sends Vary: Origin with them.

Model: opus-5-5
This commit is contained in:
2026-10-04 08:40:15 +00:00
parent 20a46e96a2
commit f507b6076d
5 changed files with 101 additions and 51 deletions
+3 -2
View File
@@ -120,8 +120,9 @@ path under `/v1/` answers 200, in maintenance mode too.
`blocked_networks`); 502 when the upstream answered with an error status, and
for 5 minutes after that for the same source URL; 503 when pixa is busy or in
maintenance mode; 500 for any other failure.
- `GET /v1/e/<token>/<name>` — an image through an encrypted URL (see Encrypted
URLs). Needs: nothing but the URL. Answers: 200; 400 for a token that does not
- `GET` or `HEAD` `/v1/e/<token>/<name>` — an image through an encrypted URL
(see Encrypted URLs). Needs: nothing but the URL. Answers: 200; 304 when
`If-None-Match` matches the image's `ETag`; 400 for a token that does not
decrypt, or that asks for a size or fit that is not valid; 410 once it has
expired; 504 when the upstream has not sent its response headers within
`upstream_fetch_timeout`, but 500 when that time runs out while the image