fit=outside scales the source to cover the requested size, so one side comes out past it, and that side had no maximum: 1x8192?fit=outside of a 3000x600 source was resized to 40960x8192 and encoded. resize now returns ErrOutputTooLarge before resizing when that side would be above 8192. Both image routes already answer that error 400 with the JSON error body (since #258), so no handler changed, and like that refusal it is not cached as a failed fetch.
The other fit modes cannot go above 8192: cover and fill make exactly the requested size, contain and inside one within it.
Tests, committed before the fix: the image processor refuses the wide and the tall case and still makes a fit=outside output with a side of exactly 8192, and one within it. Both routes answer 400 for 1x8192 of a 3000x600 source and of an 8192x1 source, and 8192x1 of a 1x8192 source (the height), and serve 1x1200 of the 3000x600 source at 6000x1200.
README.md extends the sentence on sizes with one side 0 to fit=outside; TODO.md has the entry.
Judgement call: the check sits in resize, where the fit=outside size is worked out, not in Process beside targetDimensions; it still runs before any resize or encode.
Judgement call: the 400 message is the existing one ("the side computed from its proportions is above 8192"), which also describes the side fit=outside scales.
Left as is: the Encrypted URLs sentence "A URL whose scaled side would come out above 8192 answers 400" already holds for fit=outside.
Model: opus-5-5
`fit=outside` scales the source to cover the requested size, so one side comes out past it, and that side had no maximum: `1x8192?fit=outside` of a 3000x600 source was resized to 40960x8192 and encoded. `resize` now returns `ErrOutputTooLarge` before resizing when that side would be above 8192. Both image routes already answer that error 400 with the JSON error body (since https://git.eeqj.de/sneak/pixa/pulls/258), so no handler changed, and like that refusal it is not cached as a failed fetch.
The other fit modes cannot go above 8192: `cover` and `fill` make exactly the requested size, `contain` and `inside` one within it.
Tests, committed before the fix: the image processor refuses the wide and the tall case and still makes a `fit=outside` output with a side of exactly 8192, and one within it. Both routes answer 400 for `1x8192` of a 3000x600 source and of an 8192x1 source, and `8192x1` of a 1x8192 source (the height), and serve `1x1200` of the 3000x600 source at 6000x1200.
`README.md` extends the sentence on sizes with one side `0` to `fit=outside`; `TODO.md` has the entry.
Judgement call: the check sits in `resize`, where the `fit=outside` size is worked out, not in `Process` beside `targetDimensions`; it still runs before any resize or encode.
Judgement call: the 400 message is the existing one ("the side computed from its proportions is above 8192"), which also describes the side `fit=outside` scales.
Left as is: the Encrypted URLs sentence "A URL whose scaled side would come out above 8192 answers 400" already holds for `fit=outside`.
Model: opus-5-5
fit=outside scales the source to cover the requested size, and the side
that comes out past it is held to no maximum: 1x8192?fit=outside of a
3000x600 source makes a 40960x8192 output. The new tests expect such a
size to be refused with ErrOutputTooLarge, answered 400 on both image
routes, for the width and for the height, and a fit=outside output of at
most 8192 on each side to be made as before.
Model: opus-5-5
fit=outside scales the source to cover the requested size, and the side
scaled past it was held to no maximum: 1x8192?fit=outside of a 3000x600
source was resized to 40960x8192 and encoded. resize now refuses such an
output with ErrOutputTooLarge before resizing, so both image routes answer
it 400 with the error a size with one side 0 already gets. The other fit
modes make the requested size or one within it. README.md and TODO.md
say so.
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.
fit=outsidescales the source to cover the requested size, so one side comes out past it, and that side had no maximum:1x8192?fit=outsideof a 3000x600 source was resized to 40960x8192 and encoded.resizenow returnsErrOutputTooLargebefore resizing when that side would be above 8192. Both image routes already answer that error 400 with the JSON error body (since #258), so no handler changed, and like that refusal it is not cached as a failed fetch.The other fit modes cannot go above 8192:
coverandfillmake exactly the requested size,containandinsideone within it.Tests, committed before the fix: the image processor refuses the wide and the tall case and still makes a
fit=outsideoutput with a side of exactly 8192, and one within it. Both routes answer 400 for1x8192of a 3000x600 source and of an 8192x1 source, and8192x1of a 1x8192 source (the height), and serve1x1200of the 3000x600 source at 6000x1200.README.mdextends the sentence on sizes with one side0tofit=outside;TODO.mdhas the entry.Judgement call: the check sits in
resize, where thefit=outsidesize is worked out, not inProcessbesidetargetDimensions; it still runs before any resize or encode.Judgement call: the 400 message is the existing one ("the side computed from its proportions is above 8192"), which also describes the side
fit=outsidescales.Left as is: the Encrypted URLs sentence "A URL whose scaled side would come out above 8192 answers 400" already holds for
fit=outside.Model: opus-5-5
PASS
Model: opus-5-5