![]() ![]() ![]() However this comes at the expense of actually executing the request on the server-side, even though the browser will block the response from the user. ![]() It is also easier to implement, since the server is returning the same response headers regardless of the request headers. Method #2 provides more insight into what the supported methods and headers are. Method #1 is more closely aligned to the CORS spec, but provides no useful debugging information to the user. The browser still makes the request, but if the CORS response headers don't match the user's request, the browser withholds the response from the user.Įach of these methods has their pros and cons. In this case, the server doesn't do any error checking, and just returns the CORS headers for the supported origin, method and headers. This seems to be the far more common approach, and is used by the APIs for Amazon S3, SoundCloud, FourSquare and Spotify (the latter two APIs benefit from only supporting simple CORS requests). This library returnsĤ00 Bad Request for requests that don't conform to the specĤ03 Forbidden for invalid origins or headers.Ģ) Return CORS headers in the response and let the browser sort out the access details. This is the route taken by the Java CORS filter project. I did some research into this and it seems like behavior falls into two camps:ġ) Return an error if the CORS request is invalid. Yes, I realize I'm answering my own question, but here it goes anyway.
0 Comments
Leave a Reply. |