Over-eager validation of wildcard content types (*/*)

[knellr]

We have an OpenAPI spec that contains wildcard content types, especially for non-200 responses:

          "404" : {
            "content" : {
              "*/*" : {
                "schema" : {
                  "type" : "object"
                }
              }
            },
            "description" : "Not Found"
          },

The client generated currently enforces these with the following generated code:

try converter.validateContentTypeIfPresent(
    in: response.headerFields,
    substring: "*/*"
)

As suggested, the code above is looking for a substring, causing the request to fail:

  underlyingError = unexpectedContentTypeHeader (unexpectedContentTypeHeader = "application/json")

My reading of the spec is that wildcards are supported (there are multiple examples including */*), and my expectation would be that either the validation should be done using a wildcard, or validation should be relaxed.

[czechboy0]

Thanks for reporting the issue - you're right, currently the generator doesn't handle content maps for bodies that contain wildcards in the content type names.

[czechboy0]

Hi @knellr – I've been thinking about this issue and I'm still not sure what kind of Swift code we should generate for it.

Can you talk more about what contexts you use wildcards in content types in the OpenAPI document for? Especially when paired with the schema field, it needs to be a JSON content type for Codable types to be generated for you, so why not explicitly specify it as such?

I do see */* as an example OpenAPI specification, they just don't clarify how it's meant to be handled by code generators.

Any info would be appreciated here, thanks! 🙏

[knellr]

I've just been able to dig into this, and in our specific case the issue is that we use springdoc-openapi-ui and it defauts its mime type to */* (https://springdoc.org/core-properties.html).

I'm not sure what a genuine use case would be here, but it seems we can work around this by annotating our backend fully or setting the springdoc.default-produces-media-type setting to application/json.

In practice, if I didn't have control of the backend, I think I'd expect the mime type to be validated correctly, and as a minimum to be given access to the actual mime-type and the underlying Data.

[czechboy0]

Glad to see you were able to get things working.

I'm not sure what a genuine use case would be here, but it seems we can work around this by annotating our backend fully or setting the springdoc.default-produces-media-type setting to application/json.

Yeah, that sounds like the right way to go. Even if you imagine a new client, it's a lot more useful to know the server is sending back application/json than */*. The former you can parse with some JSON parser, the latter you can't do much about without introspecting the bytes and guessing the format.

In practice, if I didn't have control of the backend, I think I'd expect the mime type to be validated correctly, and as a minimum to be given access to the actual mime-type and the underlying Data.

Understood. Today, the only place you could get the actual content type would be in a middleware (by inspecting the response's headers), but the raw data would be provided to you as part of the case any(Data) case in the operation's Output struct.

I'll keep this issue open in case other folks find a genuine use case for wildcard content types. Thanks @knellr for following up!

[czechboy0]

Closing - please reopen if you find a use case that can't be solved by using concrete content types in the OpenAPI document.