Keep max-age within an expiring image URL's lifetime (closes #63)
check / check (push) Successful in 12s
check / check (push) Successful in 12s
Both image routes sent Cache-Control: public, max-age=31536000, immutable unconditionally, so a browser or proxy could keep serving an image for a year after its signed or encrypted URL had expired. max-age is now the whole seconds left until the URL expires, never negative and at most one year; a URL with no expiry keeps one year. The 304 answer uses the same value. An encrypted URL's expiry now reaches ImageRequest.Expires through ToImageRequest. immutable stays: freshness now ends no later than the URL's expiry. README.md documents the header. Model: opus-5-5
This commit was merged in pull request #146.
This commit is contained in:
@@ -100,6 +100,13 @@ than once, is refused with 400.
|
||||
- `<format>`: one of `orig`, `png`, `jpeg`, `webp`
|
||||
- `<size>`: `orig` or `<width>x<height>` (e.g. `800x600`)
|
||||
|
||||
An image is served with `Cache-Control: public, max-age=<seconds>, immutable`.
|
||||
When the URL has an expiry (an `exp`, or the TTL of an encrypted URL),
|
||||
`max-age` is the whole seconds left until then, at most one year, so no browser
|
||||
or proxy cache keeps the image after pixa would refuse the URL. A URL with no
|
||||
expiry gets one year. `immutable` only stops a client revalidating while its
|
||||
copy is fresh.
|
||||
|
||||
The login form (`POST /`) is limited to 5 attempts per minute per client
|
||||
address, counting an IPv6 client by its /64; an attempt over the limit is
|
||||
refused with 429 and a `Retry-After` header. Behind a reverse proxy the client
|
||||
|
||||
Reference in New Issue
Block a user