vLLM does not explicitly set this strictness check to True, but in recent versions of vLLM 0.26.0+ -- It uses a newer FastAPI version and inherits FastAPI’s default which is newly strict by default :

• vLLM 0.26.0 constructs FastAPI() without strict_content_type.
• vLLM requires FastAPI 0.133–0.136.
• FastAPI defines strict_content_type=True by default.

@chanh just want to double check if we really want to allow empty content-type, rather than continue to reject it. It seems like latest vllm serve versions also reject it.

You're right, and the PR's premise is wrong. I checked the FastAPI source rather than argue from memory, and it does not say what my description claims.

strict_content_type landed in FastAPI 0.132.0 and defaults to Default(True):

0.131.0  fastapi/routing.py: 0 occurrences
0.132.0  fastapi/routing.py: 17 occurrences   <- introduced here
0.136.1  fastapi/routing.py: 17
0.141.1  fastapi/routing.py: 26

vLLM 0.26.0 builds FastAPI(lifespan=lifespan) with no override, so it inherits the strict default, exactly as you said. My PR description asserts "the strict variant is opt-in and defaults off" — that was true before 0.132.0 and is false for every FastAPI version vLLM 0.26.0 accepts. The production behaviour I measured was against an older vLLM, and I generalised from it without checking the current default. My mistake.

One correction to both of us, though: under strict, FastAPI does not return 415. The enforcement is a fallthrough, not a rejection (routing.py 0.136.1, L409-426):

body_bytes = await request.body()
if body_bytes:
    json_body: Any = Undefined
    content_type_value = request.headers.get("content-type")
    if not content_type_value:
        if not actual_strict_content_type:
            json_body = await request.json()
    else:
        ...  # application/json or */*+json -> parse
    if json_body != Undefined:
        body = json_body
    else:
        body = body_bytes          # <- raw bytes, not an error

With strict on and no Content-Type, json_body stays Undefined, the body is handed to the model as raw bytes, and Pydantic validation fails — so vllm serve answers 422, not 415. Two further details that matter here:

• if not content_type_value is falsy for the empty string as well, so FastAPI groups absent and empty identically. My PR added a separate "empty → accept" branch; the grouping is right, the outcome is not.
• The check only fires when the body is non-empty, so an empty body with no Content-Type never reaches it.

So the honest picture is that neither current Dynamo nor this PR matches vLLM: Dynamo returns 415, vLLM returns 422, and this PR returns 200.

Given that, plus the CSRF rationale FastAPI documents for the default — a browser can send a no-Content-Type cross-origin POST with no CORS preflight — I don't think "accept it" is defensible. I'd rather not ship it.

Two options, and I'll take your call:

1. Close this PR. Current behaviour is safe and stricter than vLLM's; the only divergence is 415 vs 422, which no client should be branching on.
2. Narrow it to the status code: keep rejecting, but group empty with absent the way FastAPI does, and return 422 instead of 415 so a client migrating off vllm serve sees the same status. No change in what is accepted, only in how the rejection is reported.

I lean toward (1) — the divergence is cosmetic, and 415 is arguably the more correct status for this condition regardless of what FastAPI happens to do. Say the word and I'll close it, or push (2).

Either way I'll drop the "FastAPI treats an absent Content-Type as JSON" claim from the description so it doesn't mislead anyone reading the history.