`@head` request with a body wrongly flags the content type

[timotheeguerin]

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'

[timotheeguerin]

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

[markcowl]

Timothee Guerin (@timotheeguerin) It looks like this is failing in samples on instances where a head operation can return an error response, like this

Strictly speaking, this is incorrect, but I don't think we want to correct it until next sprint (when we can either fix the underlying interfaces, or suppress the warning in the template, depending on what we find with existing specs)