[TCGC] Fix File type contentType/accept header inconsistencies

[Copilot]

Three bugs in File type handling: (1) contentType param typed as string instead of constant for File uploads with specific content types, (2) response contentType header has serializedName: undefined, (3) accept param is string instead of enum for multi-content-type downloads.

Changes

• Separate File type branch in createContentTypeOrAcceptHeader: The original content type/accept logic is preserved unchanged (json/text/octet-stream → constant for contentType; any single value → constant for accept). A new else if branch is added specifically for File type bodies (bodyKind === "file"), which follows the File's content type constraints to create a constant (single content type) or anonymous enum (multiple content types) for both contentType and accept params. This cleanly separates File-specific handling from the general content type logic.
• Response header serializedName fallback: Added fallback in getSdkHttpResponseAndExceptions — when getHeaderFieldName returns undefined (File's contentTypeProperty lacks @header), maps to "Content-Type"
• Enum accept for multiple content types: When a File body has multiple content types, creates an anonymous SdkEnumType with values instead of defaulting to string

// Issue 1: contentType was string, now constant (File body branch)
op upload(@body file: File<"image/png">): void;

// Issue 2: response contentType header serializedName was undefined
op download(): File<"application/json", string>;

// Issue 3: accept was string, now enum with two values (File body branch)
op downloadMultiple(): File<"image/png" | "image/jpeg">;

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[TCGC] Inconsistency for File support</issue_title>
<issue_description>Building uploadFileSpecificContentType the sdkMethod.parameters includes param contentType as string when it should be a constant. note that it is constant kind in the TypeSpec.Http.File type.

Building downloadFileJsonContentType, in the sdkMethod.operation.responses array, the contentType response header has its serializedName set to undefined.

In downloadFileMultipleContentTypes, the accept header param has type string but I believe it should be the anonymous enum containing image/png and image/jpeg values</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [TCGC] Inconsistency for File support #3999

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[tadelesh]

@copilot Resolve comment and check if all tests pass.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@azure-tools/typespec-client-generator-core@4030

commit: 0028cda

[Copilot]

@copilot Resolve comment and check if all tests pass.

Resolved — added test in 83414bc confirming File responses with single content type produce constant accept headers. All 1211 tests pass.

[azure-sdk]

All changed packages have been documented.

• ✅ @azure-tools/typespec-client-generator-core

Show changes

@azure-tools/typespec-client-generator-core - fix ✏️

Fix File support inconsistencies: contentType is now constant for File uploads with specific content types, response contentType header serializedName is set correctly, and accept header uses enum for multiple content types

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website