Custom headers with X-Accel-Redirect

Server NGINX
1

This is my understanding according to this:

http://wiki.codemongers.com/NginxXSendfile

Nginx will ignore any additional headers you pass along, except for
the list below, with your response?

Content-Type
Content-Disposition
Accept-Ranges
Set-Cookie
Cache-Control
Expires

Alex E.

2

On Mon, Dec 03, 2007 at 02:02:13PM -0800, Alex E. wrote:

Set-Cookie
Cache-Control
Expires

Yes.

3

Igor S. <is@…> writes:

Content-Type
Content-Disposition
Accept-Ranges
Set-Cookie
Cache-Control
Expires

Yes.

Please Igor, expand this to regard at least the proxy_pass_header
directive.

I’ve got a major problem with that which makes nginx for my project
unusable:

Let me explain why: I’m delivering PDF files out of a rails
application, and I’m using X-Accel-Redirect. I have to send a special
header for Google with it (X-Robots-Tag: noarchive) in order to
disallow archiving for Google. Also I’m sometimes sending a
X-Robots-Tag: unavailable_after to automatically remove files from
Googles index after a certain date.

I don’t have any possibility to pass these headers when using
X-Accel-Redirect (which I HAVE to, because otherwise the downloads of
the files would block my app).

In my opinion this special handling of headers makes no sense - when
using a normal upstream you can pass any header you want to. Why don’t
to so when using X-Accel-Redirect.

I’d really appreciate a response - because otherwise I have to turn
back to Apache which would be a big mess.

There are quite a few threads from people who have the same problem:

http://thread.gmane.org/gmane.comp.web.nginx.english/2301/
http://thread.gmane.org/gmane.comp.web.nginx.english/4201/

etc.

Regards,

Thomas
4

On Thu, Sep 11, 2008 at 3:52 PM, Thomas W. [email protected]
wrote:

Please Igor, expand this to regard at least the proxy_pass_header
directive.

In my opinion this special handling of headers makes no sense - when
using a normal upstream you can pass any header you want to. Why don’t
to so when using X-Accel-Redirect.

I agree. I don’t see a need to have limitations on this, myself.

5

Brendan Schwartz <bschwartz@…> writes:

On Thu, Sep 11, 2008 at 7:58 PM, mike
[email protected] wrote:
On Thu, Sep 11, 2008 at 3:52 PM, Thomas W.
[email protected] wrote:

Please Igor, expand this to regard at least the proxy_pass_header
directive.

In my opinion this special handling of headers makes no sense - when
using a normal upstream you can pass any header you want to. Why don’t
to so when using X-Accel-Redirect.
I agree. I don’t see a need to have limitations on this, myself.

I also agree. I would love this feature.

Igor, is there any chance, that we’ll see this artificial restriction
gone in
nginx soon?

… thomas

6

On Thu, Sep 11, 2008 at 7:58 PM, mike [email protected] wrote:

I agree. I don’t see a need to have limitations on this, myself.

I also agree. I would love this feature.

7

The patch below seems to work in my trivial testing. For example:

location /test {
proxy_pass_header X-Robots-Tag;
proxy_pass http://backend;
}

X-Robots-Tag will be passed from the backend, everything else (except
for the headers in the original email) will not.

Use at your own risk:

— orig/nginx-0.6.32/src/http/ngx_http_upstream.c 2008-04-17
07:32:11.000000000 -0700
+++ nginx-0.6.32/src/http/ngx_http_upstream.c 2008-10-28
13:56:42.000000000 -0700
@@ -1035,8 +1035,8 @@
{
ssize_t n;
ngx_int_t rc;

  • ngx_str_t *uri, args;
  • ngx_uint_t i, flags;
  • ngx_str_t *uri, args, *hs;
  • ngx_uint_t i, j, flags;
    ngx_list_part_t *part;
    ngx_table_elt_t *h;
    ngx_connection_t *c;
    @@ -1279,6 +1279,18 @@
    return;
    }
    }
  •        else {

  •            hs = u->conf->pass_headers->elts;

  •            for (j = 0; j < u->conf->pass_headers->nelts; j++) {

  •                if (ngx_strncasecmp(hs[j].data, h[i].key.data,

hs[j].len) == 0) {

  •                    if (ngx_http_upstream_copy_header_line(r,

&h[i], 0) != NGX_OK) {

  •                        ngx_http_finalize_request(r,

NGX_HTTP_INTERNAL_SERVER_ERROR);

  •                        return;

  •                    }

  •                    break;

  •                }

  •            }

  •        }
   }

   uri = &u->headers_in.x_accel_redirect->value;
8

+1

9

Eden Li <eden@…> writes:

The patch below seems to work in my trivial testing. For example:

This seems actually to work, thanks a lot! But I’d rather love to see
this
implemented in nginx directly rather than having to patch every release.

Can we make any progress here? Igor, what’s your opinion about this
patch? Any
chance to make it in a offical release of nginx?

10

Does anyone have this patch working with 0.6.34?

I modified it a bit to get it to cleanly apply
(gist:45269 · GitHub), now nginx builds but all
X-Accel-Redirects cease to function. I thought it could be S3
rejecting my requests so I put my log into debug. But I never get a
response from nginx. I double checked by dumping my interface with
Wireshark, but the request is never sent to S3 and nginx never replies
to my client.

From my nginx.conf (unchanged):

location /AWSS3/ {
proxy_pass http://s3.amazonaws.com/;
internal;
}

My backend application responds with (this is an open test file you
can feel free to hit):

HTTP/1.1 200 OK
Connection: close
Date: Fri, 09 Jan 2009 20:39:31 GMT
Status: 200 OK
X-Runtime: 0.00758
Etag: “7215ee9c7d9dc229d2921a40e899ec5f”
X-Accel-Redirect:
/AWSS3/dev-Andrew.onehub.com/lightweight-web-services-large.mp4
Cache-Control: private, max-age=0, must-revalidate
Content-Disposition: attachment;
filename=lightweight-web-services-large.mp4
Server: Mongrel 1.1.5
Content-Type: video/mp4; charset=utf-8
Content-Length: 1

Ideas?