Response headers incomplete when making CORS requests

• OS: macos
• Browser: chrome
• Version: 66
• Method of installation: npm
• Swagger-UI version: 3.15.0
• Swagger/OpenAPI version: 2.0

Describe the bug you’re encounering

I’ve noticed that when you host swagger-ui on a particular domain and you make calls to a CORS enabled api, not all response headers are shown. I think this may be a bug related to the preflight OPTIONS call, but I may just be misunderstanding something.

To reproduce…

1. Run this endpoint with the provided sample data: http://petstore.swagger.io/#/pet/addPet and notice your response will include headers. Likely something like this -
2. Download and setup swagger-ui locally following readme instructions for development. Run the same endpoint. This should be hosted at http://0.0.0.0:3200/#/pet/addPet Making the same call I see something like this -

Expected behavior

The response headers should be very similar since the call is made to the same endpoint

Additional context or thoughts

I believe that something is going awry when CORS is required. I tested this assumption by hosting the same petstore swagger document locally at http://0.0.0.0:3200/test.json , removing the host property making CORS unnecessary. I received this in response - Of course the actual call failed (404) since i’m not hosting the api, but I do in fact receive the expected response headers from the dev server.

[shockey]

@blortfish, while you’re right in that there’s not really a way to throw out CORS… you do have a couple of options while you wait to hear back:

• Run your browser without CORS enabled. With Chrome, the --disable-web-security command line flag will get you there. Also consider browser extensions, looks like there’s a few out there that claim to be able to toggle CORS enforcement on and off.
• Use a CORS proxy to talk to the API. Some public ones exist, like Crossorigin.me1 and CORS Anywhere2. If privacy or ownership of your infrastructure is a concern, CORS Anywhere is also available as a library3, and CORS-Proxy4 publishes a Docker image that you can spin up wherever you’d like to.

[blortfish]

@shockey thank you for all of the suggestions and information. These are all great options to consider. In the end we will be recommending that our users either whitelist headers in Access-Control-Expose-Headers or allow *.