pixa no longer accepts SVG sources, and orig no longer turns a source it cannot name into a JPEG.
The upstream fetch no longer accepts image/svg+xml. libvips renders SVG, so an SVG source was rasterized, and orig of one came back as image/jpeg.
Before decoding, the image processor names the input's format from its first bytes with govips' DetermineImageType, which is how govips picks the libvips loader, and refuses with ErrUnsupportedInputFormat any input whose first bytes it does not name as one of the six source formats. An SVG whose first bytes pass the first-bytes check for AVIF (an XML comment holding ftypavis) is refused there, before librsvg reads it. A damaged image in a source format is not: it is decoded and answers 500.
Both image routes answer 415 unsupported source format for that, and when the upstream's Content-Type is not one of the source formats.
formatFromString refuses a format it cannot name, where it returned JPEG; it makes the refusal above, and orig is the format it named.
README.md drops SVG from the source formats and lists the 415.
Each fix follows its failing tests in commit order. No existing test is changed.
Disclosures:
SVG detection stays in internal/magic, unused on the request path, for #168.
Judgement call: every upstream Content-Type outside the accepted list now answers 415 where it answered 500.
An SVG failing the first-bytes check for the type it is sent under still answers 500.
An AVIF image sequence (brand avis), whose first bytes govips names as no format, now answers 415 where it answered 500; README.md does not name that case.
pixa no longer accepts SVG sources, and `orig` no longer turns a source it cannot name into a JPEG.
- The upstream fetch no longer accepts `image/svg+xml`. libvips renders SVG, so an SVG source was rasterized, and `orig` of one came back as `image/jpeg`.
- Before decoding, the image processor names the input's format from its first bytes with govips' `DetermineImageType`, which is how govips picks the libvips loader, and refuses with `ErrUnsupportedInputFormat` any input whose first bytes it does not name as one of the six source formats. An SVG whose first bytes pass the first-bytes check for AVIF (an XML comment holding `ftypavis`) is refused there, before librsvg reads it. A damaged image in a source format is not: it is decoded and answers 500.
- Both image routes answer 415 `unsupported source format` for that, and when the upstream's `Content-Type` is not one of the source formats.
- `formatFromString` refuses a format it cannot name, where it returned JPEG; it makes the refusal above, and `orig` is the format it named.
- `README.md` drops SVG from the source formats and lists the 415.
Each fix follows its failing tests in commit order. No existing test is changed.
Disclosures:
- SVG detection stays in `internal/magic`, unused on the request path, for https://git.eeqj.de/sneak/pixa/issues/168.
- Judgement call: every upstream `Content-Type` outside the accepted list now answers 415 where it answered 500.
- An SVG failing the first-bytes check for the type it is sent under still answers 500.
- An AVIF image sequence (brand `avis`), whose first bytes govips names as no format, now answers 415 where it answered 500; `README.md` does not name that case.
Closes https://git.eeqj.de/sneak/pixa/issues/68
Model: opus-5-5
Failing tests, ahead of the fix: an upstream answering image/svg+xml is
answered 415 on the image route, also for orig; both image routes answer
415 for an unaccepted upstream content type and for orig of an input the
processor cannot name; and the processor refuses orig of a TIFF instead
of saving it as JPEG.
Model: opus-5-5
The fetcher no longer accepts image/svg+xml, so an SVG source gets the
refusal every unaccepted upstream type gets, which both image routes now
answer with 415 where they answered 500. orig of an input the processor
cannot name is ErrUnsupportedInputFormat, also answered 415, where it
was saved as JPEG. README.md drops SVG from the source formats and lists
the 415.
Model: opus-5-5
internal/imageprocessor/imageprocessor.go, Process: an SVG still gets rasterized. An upstream can answer Content-Type: image/avif with an SVG document that starts with an XML comment holding ftypavis, so that bytes 4 to 11 read ftypavis. It passes the fetcher, and it passes the first-bytes check, because internal/magic accepts the AVIF brand avis. govips does not read avis as AVIF, so it loads the bytes as SVG and librsvg renders them. A png or jpeg request then gets 200 with the rendered image, and orig gets 415 only after rendering. So untrusted XML still reaches librsvg, which is what #68 removes. Acceptable: before decoding, the processor refuses any input that libvips would not load as one of the six source formats, SVG included, and both routes answer that with the same 415. A new test sends this input and gets 415, for a resized format and for orig.
PR body and the new TODO.md entry: "An SVG sent under another image type still fails the first-bytes check and answers 500" is wrong for the input in 1. So is the PR body's claim that no accepted source reaches formatFromString without a name. Acceptable: after the fix in 1, both texts say what the tree does.
Judgement call: the test commit does not compile on its own, because it names ErrUnsupportedInputFormat before the fix adds it. I counted it as failing first, since each new test fails on its own assertion once that error exists.
Judgement call: I took 415 for every upstream Content-Type outside the accepted list as right, in line with the 415 the issue asks for SVG.
Model: opus-5-5
FAIL: needs-rework
1. `internal/imageprocessor/imageprocessor.go`, `Process`: an SVG still gets rasterized. An upstream can answer `Content-Type: image/avif` with an SVG document that starts with an XML comment holding `ftypavis`, so that bytes 4 to 11 read `ftypavis`. It passes the fetcher, and it passes the first-bytes check, because `internal/magic` accepts the AVIF brand `avis`. govips does not read `avis` as AVIF, so it loads the bytes as SVG and librsvg renders them. A `png` or `jpeg` request then gets 200 with the rendered image, and `orig` gets 415 only after rendering. So untrusted XML still reaches librsvg, which is what https://git.eeqj.de/sneak/pixa/issues/68 removes. Acceptable: before decoding, the processor refuses any input that libvips would not load as one of the six source formats, SVG included, and both routes answer that with the same 415. A new test sends this input and gets 415, for a resized format and for `orig`.
2. PR body and the new `TODO.md` entry: "An SVG sent under another image type still fails the first-bytes check and answers 500" is wrong for the input in 1. So is the PR body's claim that no accepted source reaches `formatFromString` without a name. Acceptable: after the fix in 1, both texts say what the tree does.
Judgement call: the test commit does not compile on its own, because it names `ErrUnsupportedInputFormat` before the fix adds it. I counted it as failing first, since each new test fails on its own assertion once that error exists.
Judgement call: I took 415 for every upstream `Content-Type` outside the accepted list as right, in line with the 415 the issue asks for SVG.
Model: opus-5-5
An SVG starting with an XML comment holding "ftypavis" passes the
first-bytes check for AVIF; resized as PNG, it is answered 200 with the
SVG rendered. The new server test asks for it through both image routes,
resized and as orig, and wants 415 for each. The new processor test
checks that an image in each of the six source formats loads and is saved
again in its own format.
Model: opus-5-5
govips picks the libvips loader for the input with DetermineImageType.
The image processor now names the format from that type before decoding,
and refuses with ErrUnsupportedInputFormat, answered 415, any input it
cannot name as one of the six source formats. An SVG whose first bytes
pass the first-bytes check for AVIF therefore never reaches librsvg.
orig is the format named there. README.md and TODO.md say so.
Model: opus-5-5
Fixed: before decoding, the image processor names the input's format from govips' DetermineImageType, by which govips picks the libvips loader, and refuses with ErrUnsupportedInputFormat, answered 415 by both routes, any input that is not one of the six source formats. New tests send the SVG with ftypavis as image/avif through both routes, resized as PNG and as orig, and load each of the six formats.
Fixed: the PR body and the TODO.md entry now say that such an SVG gets 415 from the image processor, that an SVG failing the first-bytes check answers 500, and that formatFromString makes the refusal before decoding.
Model: opus-5-5
Fixed: before decoding, the image processor names the input's format from govips' `DetermineImageType`, by which govips picks the libvips loader, and refuses with `ErrUnsupportedInputFormat`, answered 415 by both routes, any input that is not one of the six source formats. New tests send the SVG with `ftypavis` as `image/avif` through both routes, resized as PNG and as `orig`, and load each of the six formats.
Fixed: the PR body and the `TODO.md` entry now say that such an SVG gets 415 from the image processor, that an SVG failing the first-bytes check answers 500, and that `formatFromString` makes the refusal before decoding.
Model: opus-5-5
README.md (the 415 in the /v1/image/ route entry, and the paragraph on source images) and the doc comment of ErrUnsupportedInputFormat in internal/imageprocessor/imageprocessor.go: they promise the refusal and 415 for "an image libvips would not load as one of" the source formats. That also reads as a damaged image in an accepted format, such as a truncated JPEG served as image/jpeg, which libvips does not load and which answers 500. The refusal covers only input whose first bytes libvips reads as some other format. Acceptable: these three texts say that, for example "an image whose first bytes libvips reads as another format, such as an SVG whose first bytes pass the check for AVIF", and none of them promises 415 for a damaged image.
internal/imageprocessor/orig_format_internal_test.go, doc comment of TestImageProcessor_OrigOfUnnamedFormatRefused: it says the processor decodes TIFF but cannot name it. Since the rework, TIFF is refused before it is decoded, whatever format is asked for. Acceptable: the comment says TIFF is refused before decoding.
Judgement call: TestImageProcessor_LoadsEachSourceFormat passes without the fix; I took it as a check that the refusal leaves the six formats loading, not as a test that must fail first.
Judgement call: the first test commit still does not compile on its own; as in the earlier review, I counted its tests as failing first, since each fails on its own assertion once ErrUnsupportedInputFormat exists.
Model: opus-5-5
FAIL: needs-rework
1. `README.md` (the 415 in the `/v1/image/` route entry, and the paragraph on source images) and the doc comment of `ErrUnsupportedInputFormat` in `internal/imageprocessor/imageprocessor.go`: they promise the refusal and 415 for "an image libvips would not load as one of" the source formats. That also reads as a damaged image in an accepted format, such as a truncated JPEG served as `image/jpeg`, which libvips does not load and which answers 500. The refusal covers only input whose first bytes libvips reads as some other format. Acceptable: these three texts say that, for example "an image whose first bytes libvips reads as another format, such as an SVG whose first bytes pass the check for AVIF", and none of them promises 415 for a damaged image.
2. `internal/imageprocessor/orig_format_internal_test.go`, doc comment of `TestImageProcessor_OrigOfUnnamedFormatRefused`: it says the processor decodes TIFF but cannot name it. Since the rework, TIFF is refused before it is decoded, whatever format is asked for. Acceptable: the comment says TIFF is refused before decoding.
Judgement call: `TestImageProcessor_LoadsEachSourceFormat` passes without the fix; I took it as a check that the refusal leaves the six formats loading, not as a test that must fail first.
Judgement call: the first test commit still does not compile on its own; as in the earlier review, I counted its tests as failing first, since each fails on its own assertion once `ErrUnsupportedInputFormat` exists.
Model: opus-5-5
README.md, the doc comment of ErrUnsupportedInputFormat and the TODO.md
entry say the 415 is for input whose first bytes libvips reads as
another format, and no longer read as refusing a damaged image in a
source format, which is decoded and answers 500. The doc comment of
TestImageProcessor_OrigOfUnnamedFormatRefused says TIFF is refused
before it is decoded.
Model: opus-5-5
Fixed: README.md (the 415 in the /v1/image/ route entry and the paragraph on source images) and the doc comment of ErrUnsupportedInputFormat say the refusal is for an image whose first bytes libvips reads as another format, such as an SVG whose first bytes pass the check for AVIF; the PR body and the TODO.md entry say the refusal goes by the first bytes and that a damaged image in a source format answers 500.
Fixed: the doc comment of TestImageProcessor_OrigOfUnnamedFormatRefused says TIFF is refused before it is decoded.
Judgement call: the doc comment of ErrUnsupportedInputFormat also names input whose first bytes libvips reads as no format, since the image processor refuses that the same way; the comment above the check in Process now says the same.
Disclosure: an AVIF image sequence (brand avis) answers 415 though govips reads its first bytes as no format, so the README.md wording does not cover it; the PR body says so.
Model: opus-5-5
Fixed: `README.md` (the 415 in the `/v1/image/` route entry and the paragraph on source images) and the doc comment of `ErrUnsupportedInputFormat` say the refusal is for an image whose first bytes libvips reads as another format, such as an SVG whose first bytes pass the check for AVIF; the PR body and the `TODO.md` entry say the refusal goes by the first bytes and that a damaged image in a source format answers 500.
Fixed: the doc comment of `TestImageProcessor_OrigOfUnnamedFormatRefused` says TIFF is refused before it is decoded.
Judgement call: the doc comment of `ErrUnsupportedInputFormat` also names input whose first bytes libvips reads as no format, since the image processor refuses that the same way; the comment above the check in `Process` now says the same.
Disclosure: an AVIF image sequence (brand `avis`) answers 415 though govips reads its first bytes as no format, so the `README.md` wording does not cover it; the PR body says 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.
pixa no longer accepts SVG sources, and
origno longer turns a source it cannot name into a JPEG.image/svg+xml. libvips renders SVG, so an SVG source was rasterized, andorigof one came back asimage/jpeg.DetermineImageType, which is how govips picks the libvips loader, and refuses withErrUnsupportedInputFormatany input whose first bytes it does not name as one of the six source formats. An SVG whose first bytes pass the first-bytes check for AVIF (an XML comment holdingftypavis) is refused there, before librsvg reads it. A damaged image in a source format is not: it is decoded and answers 500.unsupported source formatfor that, and when the upstream'sContent-Typeis not one of the source formats.formatFromStringrefuses a format it cannot name, where it returned JPEG; it makes the refusal above, andorigis the format it named.README.mddrops SVG from the source formats and lists the 415.Each fix follows its failing tests in commit order. No existing test is changed.
Disclosures:
internal/magic, unused on the request path, for #168.Content-Typeoutside the accepted list now answers 415 where it answered 500.avis), whose first bytes govips names as no format, now answers 415 where it answered 500;README.mddoes not name that case.Closes #68
Model: opus-5-5
FAIL: needs-rework
internal/imageprocessor/imageprocessor.go,Process: an SVG still gets rasterized. An upstream can answerContent-Type: image/avifwith an SVG document that starts with an XML comment holdingftypavis, so that bytes 4 to 11 readftypavis. It passes the fetcher, and it passes the first-bytes check, becauseinternal/magicaccepts the AVIF brandavis. govips does not readavisas AVIF, so it loads the bytes as SVG and librsvg renders them. Apngorjpegrequest then gets 200 with the rendered image, andoriggets 415 only after rendering. So untrusted XML still reaches librsvg, which is what #68 removes. Acceptable: before decoding, the processor refuses any input that libvips would not load as one of the six source formats, SVG included, and both routes answer that with the same 415. A new test sends this input and gets 415, for a resized format and fororig.PR body and the new
TODO.mdentry: "An SVG sent under another image type still fails the first-bytes check and answers 500" is wrong for the input in 1. So is the PR body's claim that no accepted source reachesformatFromStringwithout a name. Acceptable: after the fix in 1, both texts say what the tree does.Judgement call: the test commit does not compile on its own, because it names
ErrUnsupportedInputFormatbefore the fix adds it. I counted it as failing first, since each new test fails on its own assertion once that error exists.Judgement call: I took 415 for every upstream
Content-Typeoutside the accepted list as right, in line with the 415 the issue asks for SVG.Model: opus-5-5
69dd0143e8to6241c6a425Fixed: before decoding, the image processor names the input's format from govips'
DetermineImageType, by which govips picks the libvips loader, and refuses withErrUnsupportedInputFormat, answered 415 by both routes, any input that is not one of the six source formats. New tests send the SVG withftypavisasimage/avifthrough both routes, resized as PNG and asorig, and load each of the six formats.Fixed: the PR body and the
TODO.mdentry now say that such an SVG gets 415 from the image processor, that an SVG failing the first-bytes check answers 500, and thatformatFromStringmakes the refusal before decoding.Model: opus-5-5
FAIL: needs-rework
README.md(the 415 in the/v1/image/route entry, and the paragraph on source images) and the doc comment ofErrUnsupportedInputFormatininternal/imageprocessor/imageprocessor.go: they promise the refusal and 415 for "an image libvips would not load as one of" the source formats. That also reads as a damaged image in an accepted format, such as a truncated JPEG served asimage/jpeg, which libvips does not load and which answers 500. The refusal covers only input whose first bytes libvips reads as some other format. Acceptable: these three texts say that, for example "an image whose first bytes libvips reads as another format, such as an SVG whose first bytes pass the check for AVIF", and none of them promises 415 for a damaged image.internal/imageprocessor/orig_format_internal_test.go, doc comment ofTestImageProcessor_OrigOfUnnamedFormatRefused: it says the processor decodes TIFF but cannot name it. Since the rework, TIFF is refused before it is decoded, whatever format is asked for. Acceptable: the comment says TIFF is refused before decoding.Judgement call:
TestImageProcessor_LoadsEachSourceFormatpasses without the fix; I took it as a check that the refusal leaves the six formats loading, not as a test that must fail first.Judgement call: the first test commit still does not compile on its own; as in the earlier review, I counted its tests as failing first, since each fails on its own assertion once
ErrUnsupportedInputFormatexists.Model: opus-5-5
Fixed:
README.md(the 415 in the/v1/image/route entry and the paragraph on source images) and the doc comment ofErrUnsupportedInputFormatsay the refusal is for an image whose first bytes libvips reads as another format, such as an SVG whose first bytes pass the check for AVIF; the PR body and theTODO.mdentry say the refusal goes by the first bytes and that a damaged image in a source format answers 500.Fixed: the doc comment of
TestImageProcessor_OrigOfUnnamedFormatRefusedsays TIFF is refused before it is decoded.Judgement call: the doc comment of
ErrUnsupportedInputFormatalso names input whose first bytes libvips reads as no format, since the image processor refuses that the same way; the comment above the check inProcessnow says the same.Disclosure: an AVIF image sequence (brand
avis) answers 415 though govips reads its first bytes as no format, so theREADME.mdwording does not cover it; the PR body says so.Model: opus-5-5
PASS
Model: opus-5-5