Hello,
I set up a project with CrowCpp using the CORs middleware, and found an issue with the OPTIONS reply. When using CORs in some modern browsers, the browser sends a preflight OPTIONS message before sending the actual request (it doesn't do this with "simple" requests, such as GET, but does with some other request types). It expects the response to contain a CORs header, but with CrowCpp, the response does not have CORs header even when using the CORs middleware. I took a look at the code in routing.h, and saw that the OPTIONS and HEAD responses go through their own special pathways, and seemingly do not get affected by the middleware, so they don't get the CORs header added on to the response.
As a test, I added the CORs headers manually underneath else if (req.method == HTTPMethod::Options), and after that my browser allowed the frontend to communicate with the CrowCpp backend. Though the actual solution would probably be more complicated (and involve running the OPTIONS replies through the middleware).
I believe this was brought up previously in issue #417. Though it's marked as resolved, it does seem a code change is still needed to fix this.
Mozilla info about preflight requests, and how they should be responded to
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
Hello,
I set up a project with CrowCpp using the CORs middleware, and found an issue with the OPTIONS reply. When using CORs in some modern browsers, the browser sends a preflight OPTIONS message before sending the actual request (it doesn't do this with "simple" requests, such as GET, but does with some other request types). It expects the response to contain a CORs header, but with CrowCpp, the response does not have CORs header even when using the CORs middleware. I took a look at the code in
routing.h, and saw that the OPTIONS and HEAD responses go through their own special pathways, and seemingly do not get affected by the middleware, so they don't get the CORs header added on to the response.As a test, I added the CORs headers manually underneath
else if (req.method == HTTPMethod::Options), and after that my browser allowed the frontend to communicate with the CrowCpp backend. Though the actual solution would probably be more complicated (and involve running the OPTIONS replies through the middleware).I believe this was brought up previously in issue #417. Though it's marked as resolved, it does seem a code change is still needed to fix this.
Mozilla info about preflight requests, and how they should be responded to
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request