swagger-api
Preflight OPTIONS is rejected by Swagger for unknown reason in POST requests
Q&A
- Browser: Chrome
- Version: https://editor-next.swagger.io/
- Method of installation: https://editor-next.swagger.io/
- Swagger-UI version: https://editor-next.swagger.io/
- Swagger/OpenAPI version: 3.0.0
Content & configuration
We are currently migrating from a Delphi Proxy to a Java Spring Webflux proxy. Our requests against the migrated proxy work fine when done via Postman, but in Swagger, the POST requests fail. With the following error:
Failed to fetch.
Possible Reasons:
CORS
Network Failure
URL scheme must be "http" or "https" for CORS request.
We have debugged this and confirmed that the last request that reaches the server is an OPTIONS request made against the endpoint, and that this request delivers a 200 status code along with a bunch of headers.
Using Postman, we compared what this OPTIONS request returns when made against our old Delphi Server (where the Swagger POST requests work), and the new Java Spring Webflux Server (where they fail). The result was that the new server returns all of the headers that the old server returns (including those that according to other posts are essential for Swagger to accept the preflight), plus some additional ones. Here's the comparison:
| Key | Old Proxy (working) | New Proxy (not working) |
|---|---|---|
| Access-Control-Allow-Headers | Content-Type, Authorization, token_auth | Content-Type, Authorization, token_auth |
| Access-Control-Allow-Methods | GET, POST, DELETE, PUT, PATCH, OPTIONS | GET, POST, DELETE, PUT, PATCH, OPTIONS |
| Access-Control-Allow-Origin | * | * |
| Cache-Control | no-cache, no-store, max-age=0, must-revalidate | |
| Content-Length | 39 | 39 |
| Content-Type | text/html; charset=utf-8 | text/html; charset=utf-8 |
| Date | Fri, 12 Jul 2024 10:59:43 GMT | Fri, 12 Jul 2024 11:04:15 GMT |
| Expires | 0 | |
| Pragma | no-cache | |
| Referrer-Policy | no-referrer | |
| Strict-Transport-Security | max-age=16070400; includeSubDomains | max-age=16070400; includeSubDomains |
| X-Content-Type-Options | nosniff | |
| X-Frame-Options | DENY | |
| X-XSS-Protection | 0 |
Thus, our current assumption is that some of those extra headers are causing the problem on the Swagger side, which seems like a bug because the Access-Control headers that Swagger requires are there and filled correctly. At the very least, Swagger should offer a more helpful error message stating why it refuses to continue at this point.
UPDATE:
Strangely enough, the Swagger POST works fine when I let both the Proxy and respective backend that it connects to run on my local PC. The preflight only fails when I try to access the Proxy on a server, where it is installed behind an IIS. However, accessing the old proxy on that same server through the same IIS with the same configuration (apart from the port number) works just fine.
