Unusual content type in schema

[rafalkrupinski]

Hi

I have a schema to a 3rd party service that adds version to to the content-type header. While it should be easy to handle it in run-time, the generator has a problem parsing such a schema.

I've was able to fix it by adding a few lines to the schema parser.

My question is whether this niche problem should be solved in the mainline project, or should I rather keep it in a fork?

EDIT:

I just realised that it probably wouldn't work, as the version information wouldn't be handled by the generated code. I would also need to update the template.

Also, I think there are many servers with unusual behaviours, so I think there should be some means to hook some workarounds in various places.

EDIT 2:

Actually, RFC2616 allows parameters to content-types

Here's an example:

      responses:
        '200':
          content:
            application/json; version=2.3.5:
              schema:
                $ref: '#/components/schemas/AccountRole'
            application/xml; version=2.3.5:
              schema:
                $ref: '#/components/schemas/AccountRole'
          description: ''

This schema doesn't work because of this line in the schema parser (line 74):

if content_type in _SOURCE_BY_CONTENT_TYPE:

My solution is simply to remove the version part:

    for content_type, media_type in content.items():

        # new code
        comma = content_type.find(";")
        if comma >= 0:
            content_type = content_type[:comma]
        # end new code

        if content_type in _SOURCE_BY_CONTENT_TYPE:
            source = _SOURCE_BY_CONTENT_TYPE[content_type]
            schema_data = media_type.media_type_schema
            break
    else:
        return ParseError(data=data, detail=f"Unsupported content_type {content}"), schemas

[dbanty]

Thanks for bringing this up and for such a thorough investigation!

I think there should be two parts to solving this, and I'm creating issues for both:

Allow Content-Type Workarounds

Also, I think there are many servers with unusual behaviours, so I think there should be some means to hook some workarounds in various places.

Absolutely! There are open issues such as #592 that could benefit from this. Adding a content_type_overrides or similar to the formats accepted by --config is a great idea. Then someone can map any content type to one that this project recognizes.

Created #657 for tracking this.

Ignore Content-Type Parameters

Actually, RFC2616 allows parameters to content-types

Thanks for pointing out the actual standards here! For sure, we should implement the solution you pointed out where we ignore anything after (and including) a semi-colon.

Created #658 to track this.

[dbanty]

Content-Type parameters are now ignored in 0.15.2, so application/json; version=2.3.5 is treated identically to application/json.