text/xml in iam spec instead of application/xml, which is what the OpenAPI 3.0 spec supports

[sverch]

The openapi spec only supports application/xml: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md (at least based on the fact that I can't find text/xml).

However, this spec uses text/xml: https://github.com/APIs-guru/openapi-directory/tree/master/APIs/amazonaws.com/iam/2010-05-08 I think these should be application/xml instead.

[MikeRalphson]

OpenAPI supports any media type, not just those used in examples. The real question is what is the actual API sending in its content-type headers?

[sverch]

Ah, ok. I was expecting that the content types would be listed in the spec somewhere, but I guess that's not the case. Thanks for you patience as I understand this!

Here are the headers returned by AWS:

$ https_proxy=localhost:8080 curl "https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08" -D - 
HTTP/1.1 200 OK
date: Tue, 17 Mar 2020 14:28:16 GMT

HTTP/1.1 200 OK
x-amzn-requestid: 5942ac63-6b42-4df0-9686-2f82bd54980e
content-type: text/xml
content-length: 625
date: Tue, 17 Mar 2020 14:28:16 GMT

Unfortunately, when I run the openapi-generator for rust-server, it understands that it should generate XML handling code with application/xml, but not with text/xml. I filed this issue against the rust generator. It was partly based on a misunderstanding, but I'll mention this text/xml thing there.

In the media type RFC, looking at "text" versus "application", I'm wondering if they actually signal that different handling should be used or whether that's just a generator bug. I'll ask in that issue to see what they say.

I'll close this out, since it matches what AWS actually returns. Thanks for the quick response!

[sverch]

This was a bug in the rust-server generator, but it's now fixed in OpenAPITools/openapi-generator#5594