validate content-type set as constant/required while @body or @bodyRoot value is optional?

[l0lawrence]

if the spec contains the following for an operation:

model Bar {
  baz: string;
}

op foo(
  @doc("Type of content")
  @header("content-type")
  contentType: "application/json; odata=minimalmetadata";

  @doc("The body.")
  @body
  body?: Bar;
): void;

Do we allow content-type to be required if the body is not or should we validate this?

[github-actions]

🎯 Issue Triage

This issue asks whether TypeSpec/the HTTP library should emit a validation warning or error when a content-type header is declared as a required constant while the @body (or @bodyRoot) parameter is optional — a potentially inconsistent contract.

Category: Feature Request
Area: lib:http

🔍 Analysis

The code sample shows an operation where:

• contentType is a required header with a literal/constant value ("application/json; odata=minimalmetadata")
• body is marked optional (body?: Bar)

This creates a semantic inconsistency: if the body is absent, the content-type header has no meaning, yet it would still be required by the contract. The question is whether the @typespec/http library should detect and warn (or error) on this pattern.

This touches the HTTP library's semantic validation logic (packages/http), specifically around how request bodies and their associated headers are validated together.

📝 Suggested next steps

• Decide whether this should be a hard error, a warning, or a lint rule in @typespec/http
• Consider the inverse case: optional content-type with required body
• Extend HTTP library validation to cross-check body optionality against content-type header requirements

Generated by Agentic Triage

[markcowl]

Add a linting rule in the library to prevent this.