Skip to content

fix(@typespec/http): @head response with body wrongly flags content type#9869

Draft
Copilot wants to merge 10 commits intomainfrom
copilot/fix-head-request-content-type
Draft

fix(@typespec/http): @head response with body wrongly flags content type#9869
Copilot wants to merge 10 commits intomainfrom
copilot/fix-head-request-content-type

Conversation

Copy link
Contributor

Copilot AI commented Mar 2, 2026

  • Add head-operation-no-body diagnostic to lib.ts
  • Revert payload.ts to use treatContentTypeAsHeader only
  • Update responses.ts to emit head-operation-no-body warning
  • Revert tsp-for-openapi3.ts and update openapi3 paths.test.ts
  • Update responses.test.ts and verbs.test.ts to use head-operation-no-body code
  • Fix formatting in verbs.test.ts
  • Use object (not array) in expectDiagnostics when expecting a single diagnostic
Original prompt

This section details on the original issue you should resolve

<issue_title>@head request with a body wrongly flags the content type</issue_title>
<issue_description>

Release 1.9.1 of @typespec/http updated so that the content-type header present in

Playground Link

I don't know if it is valid or not to do that with HEAD but the resulting openapi seems wrong as it now include the content type as header and the response has the wrong one

import "@typespec/http";

using Http;

@head
op listHead(): OkResponse | Error;

@error
model Error {
  @header
  contentType: "application/problem+json";

  type: string;
}
          headers:
            content-type:
              required: true
              schema:
                type: string
                enum:
                  - application/problem+json
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
```</issue_description>

<agent_instructions>We should emit a warning when this happen but also fix it so that we still respect the content type depsite it being against the HTTP spec. This means we probably need to move the logic where we decide if content-type should be a type: contentType or a header in the http property</agent_instructions>

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

<comments>
<comment_new><author>@timotheeguerin</author><body>
Http spec explicitly disallow this https://www.rfc-editor.org/rfc/rfc2616#page-54

So I believe we should add a diagnostic here. Now the question is do we want to police this or just it be a warning
1. Make it an error, doesn't matter what the regression was because it can't compile
2. Make it a warning, what do we do here:
  a. Drop the response body
  b. Act like any other verb and treat the content type as the one of the response</body></comment_new>
</comments>

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

…erb-body warning

Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com>
@microsoft-github-policy-service microsoft-github-policy-service bot added lib:http emitter:openapi3 Issues for @typespec/openapi3 emitter labels Mar 2, 2026
…est.ts, improve changeset

Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix content type flagging for HEAD requests fix(@typespec/http): @head response with body uses wrong content-type and missing warning Mar 2, 2026
…treatContentTypeAsHeader, revert tsp-for-openapi3.ts

Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com>
Copilot AI changed the title fix(@typespec/http): @head response with body uses wrong content-type and missing warning fix(@typespec/http): @head response with body wrongly flags content type Mar 3, 2026
@pkg-pr-new
Copy link

pkg-pr-new bot commented Mar 4, 2026

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http@9869
npm i https://pkg.pr.new/@typespec/openapi3@9869

commit: 0bf96a8

@timotheeguerin
Copy link
Member

@copilot rename the diagnostic to head-operation-no-body

Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com>
Copy link
Contributor Author

Copilot AI commented Mar 5, 2026

@copilot rename the diagnostic to head-operation-no-body

Done in c6c60f9.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • telemetry.astro.build
    • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/typespec/typespec/website/node_modules/.bin/../astro/astro.js build pnpm pec/�� ebsite/src/conte--llmstxt uname /.bin/node --no-emit ture st/node-gyp-bin/generate-scenarios-summary sh /nod�� es &amp;&amp; pnpm build:lib &amp;&amp; vite bui--typekits node pec/node_modules/.bin/node ose l/reference sh node (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

@timotheeguerin timotheeguerin added the int:azure-specs Run integration tests against azure-rest-api-specs label Mar 5, 2026
@timotheeguerin
Copy link
Member

@copilot fix formatting issue

Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com>
Copy link
Contributor Author

Copilot AI commented Mar 5, 2026

@copilot fix formatting issue

Fixed in 433f22a — prettier wrapped the long expectDiagnostics line in verbs.test.ts.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • telemetry.astro.build
    • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/typespec/typespec/website/node_modules/.bin/../astro/astro.js build node s/.b�� tput-dir ../../website/src/content/docs/docs/libraries/events/reference node .0_tmp_3968/node_modules/pnpm/dist/node-gyp-bin/node . sh p-client/node_mogenerate-scenarios-summary sh sion�� tspd --enable-experimental gen-extern-signature . node /.bin/sh --no-emit sh rsioning/referendoc sh (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

….test.ts

Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com>
Copy link
Contributor Author

Copilot AI commented Mar 5, 2026

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • telemetry.astro.build
    • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/typespec/typespec/website/node_modules/.bin/../astro/astro.js build node cal/�� ebsite/src/conte--llmstxt --local /.bin/node import @typespecnode git st/node-gyp-bin/generate-scenarios-summary node /nod�� build.json sh t/node_modules/.bin/tspd --no-emit l/reference st/node-gyp-bin/doc sh (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

@timotheeguerin
Copy link
Member

@copilot update the target for that new diagnostic to be the operation

Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com>
@github-actions
Copy link
Contributor

github-actions bot commented Mar 5, 2026

All changed packages have been documented.

  • @typespec/http
Show changes

@typespec/http - fix ✏️

  • Emit a head-no-body warning when a @head operation response contains a body (HTTP spec: "head request must not return a message-body in the response").,> - Fix the content-type-ignored warning incorrectly firing for @head responses that have a content-type header but no body.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

emitter:openapi3 Issues for @typespec/openapi3 emitter int:azure-specs Run integration tests against azure-rest-api-specs lib:http

Projects

None yet

Development

Successfully merging this pull request may close these issues.

@head request with a body wrongly flags the content type

3 participants