Open API Spec File fails parsing

[prestonhashworth]

trafficstars

The spec file at /openapi.json appears to have some problems when loaded from the latest image at docker.io/dmuth1/fastapi-httpbin:latest. It fails to validate in an enforcement tool and editor.swagger.io reports the following:

Errors:

Semantic error at paths./cookies.delete.requestBody DELETE operations cannot have a requestBody. Jump to line 1265 Structural error at components.schemas.QRCode.properties.box_size.exclusiveMinimum should be boolean Jump to line 1849 Structural error at components.schemas.QRCode.properties.border.exclusiveMinimum should be boolean Jump to line 1856

[prestonhashworth]

Some additional information that may be relevant:

In section 4.3.5 DELETE from RFC 7231 (https://www.rfc-editor.org/rfc/rfc7231#page-29)

   A payload within a DELETE request message has no defined semantics;
   sending a payload body on a DELETE request might cause some existing
   implementations to reject the request.

[dmuth]

Good catch, I wasn't aware validators for OpenAPI existed!

I did know that having a payload for DELETE isn't supported--I opted to add it in specifically so that people using the Swagger interface at https://httpbin.dmuth.org/ could set and delete cookies while playing around in their web browser. In fact, I'll go a little further and say that I think the functionality is helpful for people who are trying to understand how cookies work, and want to explore the behavior in their web browser.

That said, I'm not sure what the "best" way to approach this is. I can think of a few ideas off the top of my head:

• Remove the payload for DELETE /cookies. I'd prefer not to do this for the reasons above.
• Tweak the code that writes to /openapi.json to not list that. That would require me to hack on/fork FastAPI (not a great idea), and I would now have something that isn't documented. (also not a great idea)
• Come up with another way to delete cookies. (Maybe path data on the URL? Would prefer that I can also make this work in the Swagger page)

I'm open to any suggestions, maybe there's a better idea that I haven't considered yet?

Best,

-- Doug

[prestonhashworth]

I honestly wasn't aware of the differences in validator versions either (and as of today how many different modules/packages/libraries that validate) until I really dug into trying to put this behind an API security gateway that can validate based on the swagger file's contents.

In my case, I fixed it by removing the response body stanza from the delete section (suboptimal but I'll roll with it until I can't), and switching minimumExclusive to booleans while specifying a 'minimum: 0.0' key:value (with no idea what each value does) and it passes version 0 validation.

I am unsure of the scope of this issue for how it will affect the intended users of this application. My case is to use it in a very selective security use case rather than for pure development work, although I will be interacting with it in the course of my testing. Perhaps the best path is to note that this validation disparity can arise if the OAS file doesn't conform to https://json-schema.org/specification but rather draft versions with extended functionality. If no one else is having this issue I can accept a PEBCAK and we'll chock this up to a curiosity?

[prestonhashworth]

I have found that I can parse your spec file with editor.swagger.io and if I remove the request body and adjust the QR code sizing parameters to booleans everything validates perfectly. I'm going to mark this closed and if the issue comes up with anyone else this can be a reference issue.