Do not generate Content for request parameters in OpenAPI

[captainsafia]

Closes #45365.

OpenAPI parameters source from the route/query/header do not need to have the Content property defined as long as a Schema is generated. In this case, the schema is generated in Swashbuckle so we don't need to produce content attributes for them. This fix is a backport candidate.

cc: @marcominerva

[halter73]

Is the idea that endpoint IAcceptsMetadata should only influence the RequestBody and never any Parameters?

Adding the same Content to all parameters seems bad, but it seems odd that no OpenApiParameter ever has any Content. It kind of makes sense because there's no ParameterLocation for the body and OpenApiRequestBody exists, but then what's the purpose of OpenApiParameter.Content?

Edit. I found a sample. It seems like it's if you actually want to do something like accept json in a query string. Weird.

A complex parameter using content to define serialization:

{
  "in": "query",
  "name": "coordinates",
  "content": {
    "application/json": {
      "schema": {
        "type": "object",
        "required": [
          "lat",
          "long"
        ],
        "properties": {
          "lat": {
            "type": "number"
          },
          "long": {
            "type": "number"
          }
        }
      }
    }
  }
}

https://github.com/OAI/OpenAPI-Specification/blob/157a4c81ae537ef793b2bee368bc00d88b461de8/versions/3.1.0.md#parameter-object-examples

[captainsafia]

Edit. I found a sample. It seems like it's if you actually want to do something like accept json in a query string. Weird.

Chatted with @baywet about this. So for 99% of scenarios, the formats that are available for parameters sourced from routes/headers/etc. are going to be described by the style and explode property (see this).

Content is really meant to describe inputs/outputs that are more suited to serialization (request body and response) but is reused here for the 1% of scenarios where people are defining some custom serialization, like the example you shared with queries that look like ?coordiantes={lat:45,long:46}. For those scenarios, it probably makes sense to have users describe that specification themselves.

Most importantly, it looks like producing this content for the scenarios where it is not needed causes a buggy path in the Swagger UI that causes hangs if you send certain types of inputs through. :/

[captainsafia]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/aspnetcore/actions/runs/3609714209