An upstream body whose first bytes are not those of the format its Content-Type names (a JPEG sent as image/png, text, an empty body) answered 500 on both image routes, was logged at error level, and was fetched again on every request.
Both routes now answer 415 unsupported source format, as for a Content-Type that is not a source format.
The image service logs it at warning level as source refused, with the Content-Type. The plain route no longer logs it at error level.
It gets a negative cache entry, as an upstream error status does. For 5 minutes every request for that source URL, at any size or format, answers 502 without a fetch. README.md says so under Routes and where it lists the source formats.
Not shown by the diff:
The entry records 415, but a negative cache hit answers 502 whatever the entry records, as before.
Storing the entry, with its warning on failure, moved into storeNegative, which both failure points call, so fetchAndProcess stays under the function length limit.
Red: TestService_Get_ConcurrentMissesShareAFailure (internal/imgcache/concurrent_misses_internal_test.go) expects the request after a failed first-bytes check to fetch again; as an existing test it is left unchanged. The smallest change that fits the fix is its second case: {"source fails the magic byte check, kept in the negative cache", "/images/text.png", magic.ErrUnknownFormat, ErrNegativeCached, 1}.
Judgement call: a body under 12 bytes (magic.ErrNotEnoughData, the third error the same check returns) is handled the same way. The plan named only the other two.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/pixa/issues/253.
An upstream body whose first bytes are not those of the format its `Content-Type` names (a JPEG sent as `image/png`, text, an empty body) answered 500 on both image routes, was logged at error level, and was fetched again on every request.
- Both routes now answer 415 `unsupported source format`, as for a `Content-Type` that is not a source format.
- The image service logs it at warning level as `source refused`, with the `Content-Type`. The plain route no longer logs it at error level.
- It gets a negative cache entry, as an upstream error status does. For 5 minutes every request for that source URL, at any size or format, answers 502 without a fetch. `README.md` says so under Routes and where it lists the source formats.
Not shown by the diff:
- The entry records 415, but a negative cache hit answers 502 whatever the entry records, as before.
- Storing the entry, with its warning on failure, moved into `storeNegative`, which both failure points call, so `fetchAndProcess` stays under the function length limit.
Red: `TestService_Get_ConcurrentMissesShareAFailure` (`internal/imgcache/concurrent_misses_internal_test.go`) expects the request after a failed first-bytes check to fetch again; as an existing test it is left unchanged. The smallest change that fits the fix is its second case: `{"source fails the magic byte check, kept in the negative cache", "/images/text.png", magic.ErrUnknownFormat, ErrNegativeCached, 1}`.
Judgement call: a body under 12 bytes (`magic.ErrNotEnoughData`, the third error the same check returns) is handled the same way. The plan named only the other two.
Model: opus-5-5
Both image routes must answer 415 for an upstream body whose first
bytes are not those of the format its Content-Type names, log it as a
refused source and not at error level, and answer the next request for
that source 502 without fetching it again. The test fails until the
fix for #253.
Model: opus-5-5
A body whose first bytes are not those of the format its Content-Type
names answered 500 on both image routes, was logged as pixa's own
error, and was fetched again on every request. Both routes now answer
415 for each error the first-bytes check returns, and the image service
logs the refused source at warning level. The failure also gets a
negative cache entry, as an upstream error status does, so the source
URL is not fetched for 5 minutes and answers 502 meanwhile. README.md
says so.
TestService_Get_ConcurrentMissesShareAFailure still expects such a
source to be fetched again and fails until its case is changed.
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.
Fixes #253.
An upstream body whose first bytes are not those of the format its
Content-Typenames (a JPEG sent asimage/png, text, an empty body) answered 500 on both image routes, was logged at error level, and was fetched again on every request.unsupported source format, as for aContent-Typethat is not a source format.source refused, with theContent-Type. The plain route no longer logs it at error level.README.mdsays so under Routes and where it lists the source formats.Not shown by the diff:
storeNegative, which both failure points call, sofetchAndProcessstays under the function length limit.Red:
TestService_Get_ConcurrentMissesShareAFailure(internal/imgcache/concurrent_misses_internal_test.go) expects the request after a failed first-bytes check to fetch again; as an existing test it is left unchanged. The smallest change that fits the fix is its second case:{"source fails the magic byte check, kept in the negative cache", "/images/text.png", magic.ErrUnknownFormat, ErrNegativeCached, 1}.Judgement call: a body under 12 bytes (
magic.ErrNotEnoughData, the third error the same check returns) is handled the same way. The plan named only the other two.Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.