Open lenzenmi opened 9 years ago
Is it possible to do this in a single code sample, rather than fragment into two different code samples? Thanks!
It is possible. The issue is as follows:
The add_header method is included with standard builds of nginx, but it will not add the CORS header to any failed http statuses, 4xx, 5xx. It still works fine for any successful statuses and is perfectly usable.
What I found developing with django, was that when there was an error, I wanted to see the debuging output which required that the CORS header was being set on those 4xx and 5xx responses also. The only way I found to do that was by installing the additional http headers more module. This sets the headers on all response codes, but requires extra work and is not included in the standard distribution of nginx.
If we were to combine them, I would choose the second one, as it's the most practical for development which is the primary use case of a wide open CORS setting. The down side is that to make it work user's are required to install an additional module, which is destribution specific, and may require compilation of nginx from source code - not something everyone wants to do.
Anyways, I'm using the second solution now and you know your target audience a lot better than I, so I'll let you pick. If you want it reduced to a single example, tell me which one and I'll resubmit the pull request.
Thanks for your feedback. My preference for the site is to recommend a single way to do things. What do you think of the approach here:
I'm not really an nginx expert, just an average user. I can say the approach seems a little less intuitive to understand when reading the code, but there's probably a reason for it that I don't quite grasp. My approach was to set the headers on every request and eliminate all the method checks but perhaps that's incorrect with some obscure client I don't use.
It looks like the allow-origin header is fixed, so it should solve the problem I was having, so it's an improvement to what's there now. I don't see any reason that the patch won't work for production.
The only downside is it won't quite work for development, as failing statuses won't get the CORS headers set, so you won't be able to get any debug output from the webserver. That's a limitation of the add_header command built into nginx and can only be fixed with the more headers plugin.
If you just want a single example that works with vanilla nginx, then this approach should work fine. If you want something that can be used for development purposes (which in my opinion is the only reason to have a wide open CORS) then the add more headers plugin should really be required and the example should force users to install it.
It's unfortunate that nginx doesn't have a one config fits all approach, but at least in ubuntu installing the extra plugin is as simple as apt-get install nginx-extras
, so for a lot of users it's not that hard.
Previously both firefox and chrome would give this error:
I also added an example configuration that works for all response status codes