Not getting Access-Control-Allow-Headers header in response to OPTIONS request

[anseljh]

Hello, I ran into a problem similar to #1 while sending a POST request to my Falcon API from an Angular web app.

After Googling around a bit and finding this StackOverflow question, I realized the browser was first sending an OPTIONS request, and complaining about not getting an Access-Control-Allow-Headers header back.

I had set allow_all_headers=True, but still the API was not returning the Access-Control-Allow-Headers header in response to the OPTIONS request. I eventually fixed this by defining a new on_options method on the resource, but this seems pretty clunky. Shouldn't that be the expected behavior when setting allow_all_headers=True? Perhaps falcon-cors is not even seeing that OPTIONS request that precedes the POST request?

Didn't work:

cors = CORS(allow_origins_list=['http://localhost:4200'], allow_all_headers=True)
app = falcon.API(middleware=[cors.middleware])

Did work:

    def on_options(self, req, resp):
        log.debug("OPTIONS /login")
        resp.set_header('Access-Control-Allow-Headers', 'Content-Type')

[muchas]

I ran into the same issue, would love to get author's feedback on that.

[robinsax]

I encountered this as well. The problem was I didn't specify which methods should pass their preflight (this is done with the allow_all_methods or allow_methods_list kwargs in the CORS constructor). When the request method isn't allowed, the middleware aborts processing OPTIONS before it even gets to inspecting the headers, as per the spec. Odd behavior though, as the response doesn't contain any telling signs of what went wrong.