A side given as 0 is computed from the source's proportions, and nothing held it to the 8192 a requested side is held to, so 0x8192 of a 3000x600 source was resized to 40960x8192 and encoded. As decided on the issue, such a size is refused, not clamped.
targetDimensions now returns ErrOutputTooLarge for a side above MaxOutputDimension. Process calls it right after the existing check of the source's dimensions and returns before the resize and the encode; the existing defer gives the processing slot back.
Both image routes answer it 400 with the JSON error body: size too large for the source: the side computed from its proportions is above 8192.
The refusal is a processing error, and only a failed upstream fetch reaches the negative cache. The new route test requests the same sources at smaller sizes after the refusals.
imgcache.MaxDimension is now defined as imageprocessor.MaxOutputDimension (imgcache already imports imageprocessor; the reverse would be a cycle), so the request limit and the output limit are one value.
Judgement call: the route test is in internal/server, which already builds both routes against a test upstream, rather than a second handler setup in internal/handlers.
Not covered: fit=outside with both sides given can still make a side above 8192, filed as #257.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/pixa/issues/241.
A side given as `0` is computed from the source's proportions, and nothing held it to the 8192 a requested side is held to, so `0x8192` of a 3000x600 source was resized to 40960x8192 and encoded. As decided on the issue, such a size is refused, not clamped.
- `targetDimensions` now returns `ErrOutputTooLarge` for a side above `MaxOutputDimension`. `Process` calls it right after the existing check of the source's dimensions and returns before the resize and the encode; the existing `defer` gives the processing slot back.
- Both image routes answer it 400 with the JSON error body: `size too large for the source: the side computed from its proportions is above 8192`.
- The refusal is a processing error, and only a failed upstream fetch reaches the negative cache. The new route test requests the same sources at smaller sizes after the refusals.
- `imgcache.MaxDimension` is now defined as `imageprocessor.MaxOutputDimension` (imgcache already imports imageprocessor; the reverse would be a cycle), so the request limit and the output limit are one value.
Judgement call: the route test is in `internal/server`, which already builds both routes against a test upstream, rather than a second handler setup in `internal/handlers`.
Not covered: `fit=outside` with both sides given can still make a side above 8192, filed as https://git.eeqj.de/sneak/pixa/issues/257.
Model: opus-5-5
Failing tests first. Through both image routes, 0x8192 of a 3000x600
source and 8192x0 of a 600x3000 source must answer 400 with the JSON
error body; orig, a size with both sides given and a 0 side whose
computed side stays within 8192 must be served as before, after the
refusals. In the image processor, a 0 side computed to exactly 8192 is
kept and one above is refused with ErrOutputTooLarge, which does not
exist yet.
Model: opus-5-5
A side given as 0 is computed from the source's proportions, and
nothing held it to 8192: 0x8192 of a 3000x600 source was resized to
40960x8192 and encoded. Process now refuses such a size with
ErrOutputTooLarge once it knows the source's dimensions, before the
resize and the encode, and both image routes answer it 400 with the
JSON error body. It is a processing error, not a failed fetch, so it
is never negative-cached. imgcache.MaxDimension is now
imageprocessor.MaxOutputDimension, so the request limit and the output
limit are one value. README.md says it under Routes and Encrypted URLs.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #241.
A side given as
0is computed from the source's proportions, and nothing held it to the 8192 a requested side is held to, so0x8192of a 3000x600 source was resized to 40960x8192 and encoded. As decided on the issue, such a size is refused, not clamped.targetDimensionsnow returnsErrOutputTooLargefor a side aboveMaxOutputDimension.Processcalls it right after the existing check of the source's dimensions and returns before the resize and the encode; the existingdefergives the processing slot back.size too large for the source: the side computed from its proportions is above 8192.imgcache.MaxDimensionis now defined asimageprocessor.MaxOutputDimension(imgcache already imports imageprocessor; the reverse would be a cycle), so the request limit and the output limit are one value.Judgement call: the route test is in
internal/server, which already builds both routes against a test upstream, rather than a second handler setup ininternal/handlers.Not covered:
fit=outsidewith both sides given can still make a side above 8192, filed as #257.Model: opus-5-5
PASS
Model: opus-5-5