Proxy_pass_header not working in 1.6.0

Hi guys,

I’m currently running nginx version 1.6.0 (after upgrading from 1.4.4).

Sadly I’ve found out, after upgrading proxy_pass_header seems to stop
working, meaning no headers is passed from the upstream at all, I’ve
tried setting caching headers, expires headers, removing ETag etc but
nothing seems to go through.

I then wanted to test it, on other machines, because it could be a
faulty installation, but I can replicate it on 3 different machines, I’m
always getting my releases from https://github.com/nginx/nginx/releases.

My config looks as following:

https://gist.github.com/lucasRolff/c4a359d93b5906678a23

Do you guys know what can be wrong, and if there is a fix for it in any
newer version of nginx, or if I should downgrade to 1.4.4 again (Where I
know it’s working at least).

Thanks in advance!

Best regards,
Lucas Rolff

On 1 Jul 2014 07:58, “Lucas Rolff” [email protected] wrote:

Hi guys,

I’m currently running nginx version 1.6.0 (after upgrading from 1.4.4).

Sadly I’ve found out, after upgrading proxy_pass_header seems to stop
working, meaning no headers is passed from the upstream at all

You need to read the proxy_pass_header and proxy_hide_header reference
documentation. You’re using it wrongly, possibly because you’ve assumed
it
takes generic parameters instead of very specific ones.

Well, it used to work before 1.6.0…

For me
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header
shows that I should do:

proxy_pass_header Cache-Control;

So that should be correct

Best regards,
Lucas Rolff

On 1 Jul 2014 10:20, “Lucas Rolff” [email protected] wrote:

Well, it used to work before 1.6.0…

For me
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header
shows that I should do:

proxy_pass_header Cache-Control;

So that should be correct

No. You have misread the documentation.

proxy_pass_header accepts a very limited set of headers whereas your use
of
it assumes it is generic.

Please carefully reread the pass AND hide documentation as I
suggested.

Do you have a link to a documentation that has info about this then?
Because in the below link, and in
http://wiki.nginx.org/HttpProxyModule#proxy_pass_header theres nothing
about what it accepts.

Best regards,
Lucas Rolff

On 1 Jul 2014 10:34, “Lucas Rolff” [email protected] wrote:

Do you have a link to a documentation that has info about this then?
Because in the below link, and in
http://wiki.nginx.org/HttpProxyModule#proxy_pass_header theres nothing
about what it accepts.

How about the doc you already found, and then the link that it contains:

On 1 Jul 2014 10:20, “Lucas Rolff” [email protected] wrote:

For me
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header

So… Where is the thing that states I can’t use proxy_pass_header
cache-control, or expires? :)))

Maybe I’m just stupid

Best regards,
Lucas Rolff

Can we move past passive aggressive posting to a public mailing list and
actually try to accomplish something?

The nginx docs indicate the following about proxy_pass_header

“Permits passing otherwise disabled header fields from a proxied server
to a client.”

‘otherwise disabled header fields’ are documented as the following (from
proxy_hide_header docs):

By default, nginx does not pass the header fields Date, Server,
X-Pad, and X-Accel-… from the response of a proxied server to a
client.

So I don’t know why you would need to have proxy_pass_header
Cache-Control in the first place, since this wouldn’t seem to be dropped
by default from the response of a proxied server to a client.

Have you tried downgrading back to 1.4.4 to confirm whatever problem
you’re having doesn’t exist within some other part of your
infrastructure that was potentially changed as part of your upgrade?

I’ve verified that 1.4.4 works as it should, I receive the cache-control
and expires headers sent from upstream (Apache 2.4 in this case),
upgrading to nginx 1.6.0 breaks this, no config changes, nothing.

But thanks for the explanation Robert!
I’ll try investigate it further to see if I can find the root cause,
since for me this is very odd that it’s suddenly not sent to the client
anymore.

Best regards,
Lucas Rolff

On 1 Jul 2014 11:01, “Lucas Rolff” [email protected] wrote:

So… Where is the thing that states I can’t use proxy_pass_header
cache-control, or expires? :)))

The proxy_hide_header and proxy_pass_header reference docs.

On Tuesday 01 July 2014 10:30:47 Lucas Rolff wrote:

I’ve verified that 1.4.4 works as it should, I receive the cache-control
and expires headers sent from upstream (Apache 2.4 in this case),
upgrading to nginx 1.6.0 breaks this, no config changes, nothing.

But thanks for the explanation Robert!
I’ll try investigate it further to see if I can find the root cause,
since for me this is very odd that it’s suddenly not sent to the client
anymore.

[…]

They can be not sent because your backend stopped returning them for
some
reason. Try to investigate what happens on the wire between your
backend
and nginx.

wbr, Valentin V. Bartenev

nginx:

curl -I http://domain.com/wp-content/uploads/2012/05/forside.png
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 01 Jul 2014 10:42:06 GMT
Content-Type: image/png
Content-Length: 87032
Last-Modified: Fri, 08 Mar 2013 08:02:48 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: “51399b28-153f8”
Accept-Ranges: bytes

Backend:

curl -I http://domain.com:8081/wp-content/uploads/2012/05/forside.png
HTTP/1.1 200 OK
Date: Tue, 01 Jul 2014 10:42:30 GMT
Server: Apache
Last-Modified: Fri, 08 Mar 2013 08:02:48 GMT
Accept-Ranges: bytes
Content-Length: 87032
Cache-Control: max-age=2592000
Expires: Thu, 31 Jul 2014 10:42:30 GMT
Content-Type: image/png

So backend returns the headers just fine.

Best regards,
Lucas Rolff

You need to examine traffic over the wire between the proxy and the
origin as you send a request from an outside client to the proxy. This
will allow you to see if the origin is even returning the expected
headers to the proxy, or if the proxy is seeing a different response
than a direct client is.

I’ve been investigating, and seems like it’s related to 1.6 or so -
because 1.4.2 and 1.4.4 works perfectly with the config in the first
email.

Any that can possibly reproduce this as well?

Best regards,
Lucas R

Seems like its not possible to ude try_files together with
proxy_pass_header

So if that was a bug before that you could get the headers from Backend
but
still serve the file using nginx I don’t know.

All dynamic files which I send to Backend is having cache-control
headers
set. All static files (which I want to serve using nginx, but inherit
the
cache-control header from
Backend) doesn’t work, which it used to do.

  • lucas R

Robert P. wrote:

You need to examine traffic over the wire between the proxy and the
origin as you send a request from an outside client to the proxy. This
will allow you to see if the origin is even returning the expected
headers to the proxy, or if the proxy is seeing a different response
than a direct client is.

On 07/01/2014 04:00 AM, Lucas Rolff wrote:

So backend returns the headers just fine.

Hello!

On Tue, Jul 01, 2014 at 01:00:05PM +0200, Lucas Rolff wrote:

Vary: Accept-Encoding
Accept-Ranges: bytes
Content-Length: 87032
Cache-Control: max-age=2592000
Expires: Thu, 31 Jul 2014 10:42:30 GMT
Content-Type: image/png

So backend returns the headers just fine.

The response returned by nginx is a static file served by nginx
itself. Note the ETag header returned, and the “location
~..(3gp|gif|jpg|jpeg|png|…” in your config - it looks like
the file exists on the filesystem, and returned directly as per
configuration. There is no surprise the response doesn’t have any
headers which are normally returned by your backend.

(And yes, all proxy_pass_header directives in your config are
meaningless and should be removed.)


Maxim D.
http://nginx.org/

Hmm, okay…

Then I’ll go back to an old buggy version of nginx which gives me the
possibility to use the headers from Backend!

Best regards,
Lucas Rolff

On Tuesday 01 July 2014 14:33:54 Lucas Rolff wrote:

Hmm, okay…

Then I’ll go back to an old buggy version of nginx which gives me the
possibility to use the headers from Backend!

[…]

It doesn’t do this either. Probably, it just has different
configuration or
permissions which results to that try_files always fails, and all
requests are
served from your backend.

wbr, Valentin V. Bartenev

But if files was served from backend I would assume to see the
$upstream_response_time variable in nginx would return other stuff than
a dash in 1.4.4
Like this, using logformat:
“$request”$status$body_bytes_sent"$http_referer""$http_user_agent"$request_time$upstream_response_time’;

“GET /css/colors.css HTTP/1.1” 304 0 “http://viewabove.dk/?page_id=2
“Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36” 0.000 -

Again, configs is exactly the same, same operating system, same
permissions, same site, so it seems odd to me, specially because nothing
has been listed in the change logs about this ‘fix’ - it was in earlier
versions, and was actually served by nginx, even when it did fetch
headers from the backend.

Best regards,
Lucas Rolff

Hello!

On Tue, Jul 01, 2014 at 02:33:54PM +0200, Lucas Rolff wrote:

Hmm, okay…

Then I’ll go back to an old buggy version of nginx which gives me the
possibility to use the headers from Backend!

You don’t need to go back (and I doubt it will help) - if you
don’t want nginx to serve files directly, just don’t configure it
to do so. Just commenting out the location in question will do
the trick.

It may be also a good idea to re-read the configuration you are
using to make sure you understand what it does. It looks like
most, if not all, your question are results of misunderstanding of
what’s written in your nginx.conf.


Maxim D.
http://nginx.org/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs