CORS headers not being set for a 401 response from upstream

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-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.

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

“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.
http://nginx.org/

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:

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:

http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute


Maxim D.
http://nginx.org/

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: