Repository navigation
fix: answer unreadable request formats with 415, and count content types (DW-985) - #2083
Merged
Merged
Conversation
Deploying control-layer with
|
| Latest commit: |
91e6ff2
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://9894111e.control-layer.pages.dev |
| Branch Preview URL: | https://steffen-dw-985-return-415-fo.control-layer.pages.dev |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 5 files
Reply with feedback, questions, or to request a fix.
View guided diff | Turn on auto-fix | Re-trigger cubic
Crown421
force-pushed
the
steffen/dw-985-return-415-for-unreadable-content
branch
2 times, most recently
from
October 21, 2026 21:34
33b547c to
f43ad20
Compare
pjb157
added this pull request to stack #2088
October 22, 2026 11:05
Crown421
force-pushed
the
steffen/dw-985-return-415-for-unreadable-content
branch
from
October 22, 2026 11:06
f43ad20 to
457e752
Compare
Contributor
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
pjb157
approved these changes
Oct 22, 2026
Base automatically changed from
steffen/dw-985-accept-compressed-request-bodies-and-return-415-for-content
to
main
October 22, 2026 11:14
…pes (DW-985) RFC 9110 reserves 415 for a body in a format or coding the server doesn't support. Non-multipart file uploads, batch files compressed with xz, zip, bzip2 or lz4, and strict /responses bodies not declared as JSON were 400s, telling clients their request was malformed rather than sent in the wrong format. All three already failed, so no working client changes behaviour. The lenient JSON endpoints parse whatever content type a client declares, and curl -d declares a form body. Count the declared content types before deciding whether rejecting any of them is safe.
Crown421
force-pushed
the
steffen/dw-985-return-415-for-unreadable-content
branch
from
October 22, 2026 11:15
457e752 to
91e6ff2
Compare
This was referenced Oct 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #2082. Completes DW-985.
Why
RFC 9110 §15.5.16 reserves 415 for a request whose content format or coding the server doesn't support. #2082 returns it for unsupported content codings. Three other refusals in the same class still came back as a 400, which tells the client its request was malformed rather than sent in the wrong format:
POST /ai/v1/fileswithoutmultipart/form-data, e.g. a raw JSONL body. This was a 400 "Invalid multipart request: invalid boundary", and it took an upload slot before being refused./responseswith a body not declared as JSON. This was a 400invalid_content_type.All three already fail today, so changing the status breaks no working client.
What changes
Error::UnsupportedMediaTypevariant, returned as a 415.multipart/form-datacontent type gets a 415 before it takes an upload slot. A multipart request with a broken form, such as a bad boundary, is still a 400. Files compressed in a format we don't decode also get a 415./responses: a missing JSON content type returns 415. The code staysinvalid_content_type, soonwards_rejections_totalseries keep their label.dwctl_inference_request_content_types_total{content_type}counts the content type declared on each POST to the inference endpoints, i.e. everything under/ai/v1/*except the file and batch routes, which already check theirs. Values are grouped into json, form, multipart, text, other and none./chat/completions,/completionsand/embeddingsparse the body whatever it declares, andcurl -dwithout-Hdeclares a form body. Rejecting on content type there could break working clients, so this measures how many such requests there are before anyone decides.Not in this PR
charsetparameters: deliberately left alone for the same reason.Testing
test_upload_that_is_not_a_multipart_form_returns_415: a JSONL body, a form body and a missing content type each get a 415. A multipart body with a broken form still gets a 400.test_upload_broken_or_unsupported_compression_names_the_problem: xz gets a 415, and truncated gzip still gets a 400.responses_bodies_not_sent_as_json_are_counted_as_suchin onwards: now asserts a 415 and the unchanged rejection code.classifies_declared_content_types: covers the metric's labels.