Update 413 status code error handling

[stgrace]

Summary

Fixes #2808

Error handling for 413 errors seems to not properly return an error (anymore). When trying to create an entry with too large of a body the following generic errors were returned:

Error: signing <image>: Post "https://rekor.sigstore.dev/api/v1/log/entries": POST https://rekor.sigstore.dev/api/v1/log/entries giving up after 4 attempt(s)
error during command execution: signing <image>: Post "https://rekor.sigstore.dev/api/v1/log/entries": POST https://rekor.sigstore.dev/api/v1/log/entries giving up after 4 attempt(s)

This PR solves it by returning the proper http error code and a useful message:

Error: signing <image>: [POST /api/v1/log/entries][413] createLogEntry default {"code":413,"message":"Request Entity Too Large. Limit set to 10597713"}
error during command execution: <image>: [POST /api/v1/log/entries][413] createLogEntry default {"code":413,"message":"Request Entity Too Large. Limit set to 10597713"}

This was tested by running in debug mode with all dependencies running in docker via the docker compose and using cosign v2.6.2:

cosign attest --rekor-url=http://localhost:3000 --replace --timeout 10m0s --yes --predicate scan2.json --type spdx <image>

Release Note

• Fixed error handling for 413 status codes.

Documentation

N/A

[stgrace]

Not sure if this if statement actually ever works anymore, or how to test it.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 26.33%. Comparing base (488eb97) to head (38fdad9).
⚠️ Report is 688 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/generated/restapi/configure_rekor_server.go	0.00%	4 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2813       +/-   ##
===========================================
- Coverage   66.46%   26.33%   -40.13%     
===========================================
  Files          92      191       +99     
  Lines        9258    20264    +11006     
===========================================
- Hits         6153     5336      -817     
- Misses       2359    14091    +11732     
- Partials      746      837       +91     

Flag	Coverage Δ
e2etests	49.46% <ø> (+1.90%)	⬆️
unittests	16.95% <0.00%> (-30.73%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[stgrace]

Found a test for this as well, but I'm unsure if these are still being run in the pipeline: https://github.com/sigstore/rekor/blob/main/cmd/rekor-server/e2e_test.go#L370

@bobcallaway @dlorenc @lukehinds let me know if you guys have any feedback.

Thanks in advance.

[bobcallaway]

#2640 seems like this would have helped to address this, i dont know that cosign has picked it up yet.

also that test case is still runs but only tests the status code, not the actual message printed

[stgrace]

Hi @bobcallaway,

Thanks for your response.

I feel like this is a rekor issue though. In the main branch the server currently returns a 500 error, instead of a 413 when the payload is too large, hence the PR and my question if the e2e test is being run, as I would assume this test would fail. It's not just about the message. See the following logging for reference:

2026-05-05T21:50:11.898+0200	INFO	restapi/configure_rekor_server.go:239	completed request	{"operation": {"id": "BEPC164/qPrXNOf2zY-000003"}, "httpRequest": {"requestMethod": "POST", "requestUrl": "http://localhost:3000/api/v1/log/entries", "requestSize": "20037261", "status": 500, "responseSize": "53", "userAgent": "cosign/v2.6.3 (linux; amd64)", "remoteIp": "127.0.0.1:51484", "latency": "0.286485051s", "protocol": "HTTP/1.1"}}

[stgrace]

And after running with the code changes in this PR:

2026-05-05T21:56:22.466+0200	INFO	restapi/configure_rekor_server.go:239	completed request	{"operation": {"id": "BEPC164/ai5g7IbjMl-000002"}, "httpRequest": {"requestMethod": "POST", "requestUrl": "http://localhost:3000/api/v1/log/entries", "requestSize": "20037261", "status": 413, "responseSize": "72", "userAgent": "cosign/v2.6.3 (linux; amd64)", "remoteIp": "127.0.0.1:38426", "latency": "0.048714979s", "protocol": "HTTP/1.1"}}

[bobcallaway]

Hi @bobcallaway,

Thanks for your response.

I feel like this is a rekor issue though. In the main branch the server currently returns a 500 error, instead of a 413 when the payload is too large, hence the PR and my question if the e2e test is being run, as I would assume this test would fail. It's not just about the message. See the following logging for reference:

2026-05-05T21:50:11.898+0200	INFO	restapi/configure_rekor_server.go:239	completed request	{"operation": {"id": "BEPC164/qPrXNOf2zY-000003"}, "httpRequest": {"requestMethod": "POST", "requestUrl": "http://localhost:3000/api/v1/log/entries", "requestSize": "20037261", "status": 500, "responseSize": "53", "userAgent": "cosign/v2.6.3 (linux; amd64)", "remoteIp": "127.0.0.1:51484", "latency": "0.286485051s", "protocol": "HTTP/1.1"}}

looks like that test case does run regularly and passes but it tests a different endpoint (SearchLogQuery) which means this is more of a missing coverage situation.

[stgrace]

Hi @bobcallaway

I added an e2e test case for this.