Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consumes with mime type parameters blocks all content types #136

Open
nlsun opened this issue Apr 19, 2019 · 0 comments
Open

consumes with mime type parameters blocks all content types #136

nlsun opened this issue Apr 19, 2019 · 0 comments
Labels

Comments

@nlsun
Copy link

nlsun commented Apr 19, 2019

What I See

Setting a parameter in the mime type (e.g. charset=utf-8 in text/plain;charset=utf-8) inside the consumes field in the swagger file ends up not matching any request.

You get the error

{"code":415,"message":"unsupported media type \"text/plain\", only [text/plain; charset=utf-8] are allowed"}

even if the client content type is set to text/plain; charset=utf-8

Sample swagger consumes line:

definitions:
  '/test/{id}':
    post:
      consumes:
        - text/plain; charset=utf-8

What I think is happening

It looks like the problem is that we're doing a string match of the parsed request mime type (text/plain), against the "allowed" mime types (text/plain; charset=utf-8)

if swag.ContainsStringsCI(allowed, mt) {

I talked briefly with @casualjim on slack and his opinion on this is:

I’m leaning towards saying it should only match the base + any parameters the client sends

So it seems like the behavior should be changed to

  1. Pass, client sends text/plain and server accepts text/plain;charset=utf-8
  2. Fail, client sends text/plain;blah=true and server accepts text/plain;charset=utf-8
  3. Pass, client sends text/plain;charset=utf-8 and server accepts text/plain
  4. Pass, client sends text/plain;charset=utf-8 and server accepts text/plain;charset=utf-8
  5. Fail, client sends text/plain;charset=utf-8 and server accepts text/plain;charset=ascii

I'll try and submit a patch for this when I get a chance.

@fredbi fredbi added the bug label Dec 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants