# CORS headers not being set for a 401 response from upstream **URL:** \ **Category:** NGINX\ **Created:** [June 9, 2014, 1:06pm UTC](https://www.ruby-forum.com/t/cors-headers-not-being-set-for-a-401-response-from-upstream/230295 "2014-06-09T13:06:15Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\ **Post date:** [June 9, 2014, 1:06pm UTC](https://www.ruby-forum.com/t/cors-headers-not-being-set-for-a-401-response-from-upstream/230295/1 "2014-06-09T13:06:15Z")
Hi, I am trying to setup CORS headers in my nginx config. My config is here : [http://pastie.org/private/eevpeyy6uwu25rl5qsgzyq](http://pastie.org/private/eevpeyy6uwu25rl5qsgzyq) The upstream is defined separately. It responds fine to OPTIONS request. It also adds the “Access-Control-Allow-Origin \*” header to responses from the upstream (pm\_puma\_cluster) when the response status is 200. But if the response status from the upstream is 401 it is not adding the CORS header. Is it expected? Or am I missing something in the config? P.S : The upstream is a Rails app and I would prefer to deal with the CORS headers in the nginx and not mess with them in the Rails app. – Regards, Srirang G Doddihal Brahmana. The LIGHT shows the way. The WISE see it. The BRAVE walk it. The PERSISTENT endure and complete it. I want to do it all ALONE. ---
**Author:** ![Srirang\_Doddihal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f4b2a3/32.png) [@Srirang\_Doddihal](https://www.ruby-forum.com/u/Srirang_Doddihal)\ **Post date:** [June 10, 2014, 1:34pm UTC](https://www.ruby-forum.com/t/cors-headers-not-being-set-for-a-401-response-from-upstream/230295/2 "2014-06-10T13:34:25Z")
Hello! On Mon, Jun 09, 2014 at 04:35:31PM +0530, Srirang Doddihal wrote: > But if the response status from the upstream is 401 it is not adding the > CORS header. > > Is it expected? Or am I missing something in the config? Quote from [Alphabetical index of directives](http://nginx.org/r/add_header:) “Adds the specified field to a response header provided that the response code equals 200, 201, 204, 206, 301, 302, 303, 304, or 307.” – Maxim D. > **[nginx](http://nginx.org/)** ---
**Author:** ![Srirang\_Doddihal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f4b2a3/32.png) [@Srirang\_Doddihal](https://www.ruby-forum.com/u/Srirang_Doddihal)\ **Post date:** [July 15, 2014, 7:38pm UTC](https://www.ruby-forum.com/t/cors-headers-not-being-set-for-a-401-response-from-upstream/230295/3 "2014-07-15T19:38:28Z")
Thanks Maxim for the documentation link. I am running into a similar issue. But it is for a 504 server time out. I’m doing a long-poll, but it is a cross domain long poll GET request. The client implementation is trying to use CORS. It all works fine with when the GET requests returns something. But when the server times out (HTTP 504) there is no CORS header information on the reply and the client code treats it as: ‘No ‘Access-Control-Allow-Origin’ header is present on the requested resource’ Just extending the keepalive\_timeout indefinitely is also not a good idea. So what is the recommended way to handle a 504. It seems I don’t get this in the client side XmlHttpRequest. The exceptions occurs before. Posted at Nginx Forum: > **[Re: CORS headers not being set for a 401 response from upstream.](https://forum.nginx.org/read.php?2,250740,251830#msg-251830)** > > Hi, I am trying to setup CORS headers in my nginx config. My config is here : http://pastie.org/private/eevpeyy6uwu25rl5qsgzyq The upstream is defined separately. It responds fine to OPTIONS request. It also adds the "Access-Control-Allow-Origi ---
**Author:** ![Srirang\_Doddihal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f4b2a3/32.png) [@Srirang\_Doddihal](https://www.ruby-forum.com/u/Srirang_Doddihal)\ **Post date:** [July 16, 2014, 12:21am UTC](https://www.ruby-forum.com/t/cors-headers-not-being-set-for-a-401-response-from-upstream/230295/4 "2014-07-16T00:21:54Z")
Hello! On Tue, Jul 15, 2014 at 01:37:58PM -0400, ensing wrote: > resource’ > > Just extending the keepalive\_timeout indefinitely is also not a good idea. > > So what is the recommended way to handle a 504. It seems I don’t get this in > the client side XmlHttpRequest. The exceptions occurs before. The message in question isn’t an exception. Rather, it’s an error message in your javascript console. All other code works as intended - with the exception that it can’t access the response returned. From client code point of view, this is mostly identical to network connectivity problem. And you have to handle such problems anyway (and likely in the same way). In javascript, the code should test the “status” property of the XMLHttpRequest object to find out if the request was successful or not, see here: > **[XMLHttpRequest Level 1](https://www.w3.org/TR/XMLHttpRequest/)** – Maxim D. > **[nginx](http://nginx.org/)** ---
**Author:** ![Srirang\_Doddihal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f4b2a3/32.png) [@Srirang\_Doddihal](https://www.ruby-forum.com/u/Srirang_Doddihal)\ **Post date:** [August 21, 2015, 7:30pm UTC](https://www.ruby-forum.com/t/cors-headers-not-being-set-for-a-401-response-from-upstream/230295/5 "2015-08-21T19:30:48Z")
To quote previous email from Maxim: “In javascript, the code should test the “status” property of the XMLHttpRequest object to find out if the request was successful or not” The problem here is that xhr.status === 0 if you don’t have CORS headers present. If nginx doesn’t allow you to add\_headers for a 401, a 504, a 404 etc then a Javascript app can’t react to each response individually. Isn’t it a little rudimentary to expect a Javascript app to treat to all server errors in the same way? Simply because 401 !== 504. Posted at Nginx Forum: > **[Re: CORS headers not being set for a 401 response from upstream.](https://forum.nginx.org/read.php?2,250740,261171#msg-261171)** > > Hi, I am trying to setup CORS headers in my nginx config. My config is here : http://pastie.org/private/eevpeyy6uwu25rl5qsgzyq The upstream is defined separately. It responds fine to OPTIONS request. It also adds the "Access-Control-Allow-Origi