Forum: NGINX proxy_pass_header not working in 1.6.0

9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 06:58
(Received via mailing list)
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
34011bc56457235a2caa5ed1d4a29f3c?d=identicon&s=25 Jonathan Matthews (Guest)
on 2014-07-01 09:11
(Received via mailing list)
On 1 Jul 2014 07:58, "Lucas Rolff" <lucas@slcoding.com> 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.
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 09:20
(Received via mailing list)
Well, it used to work before 1.6.0..

For me
http://nginx.org/en/docs/http/ngx_http_proxy_modul...
shows that I should do:

proxy_pass_header Cache-Control;

So that should be correct

Best regards,
Lucas Rolff
34011bc56457235a2caa5ed1d4a29f3c?d=identicon&s=25 Jonathan Matthews (Guest)
on 2014-07-01 09:29
(Received via mailing list)
On 1 Jul 2014 10:20, "Lucas Rolff" <lucas@slcoding.com> wrote:
>
> Well, it used to work before 1.6.0..
>
> For me
http://nginx.org/en/docs/http/ngx_http_proxy_modul...
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 *re*read the _pass_ AND _hide_ documentation as I
suggested.
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 09:34
(Received via mailing list)
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
34011bc56457235a2caa5ed1d4a29f3c?d=identicon&s=25 Jonathan Matthews (Guest)
on 2014-07-01 09:54
(Received via mailing list)
On 1 Jul 2014 10:34, "Lucas Rolff" <lucas@slcoding.com> 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" <lucas@slcoding.com> wrote:
>> > For me
http://nginx.org/en/docs/http/ngx_http_proxy_modul...
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 10:02
(Received via mailing list)
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
34011bc56457235a2caa5ed1d4a29f3c?d=identicon&s=25 Jonathan Matthews (Guest)
on 2014-07-01 10:09
(Received via mailing list)
On 1 Jul 2014 11:01, "Lucas Rolff" <lucas@slcoding.com> 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.
111a08d93ad6b7c5b4f5eb09c45c746d?d=identicon&s=25 Robert Paprocki (Guest)
on 2014-07-01 10:26
(Received via mailing list)
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?
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 10:31
(Received via mailing list)
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
40b4c848b8fcd63b0cb60b9d170c3a77?d=identicon&s=25 Valentin V. Bartenev (Guest)
on 2014-07-01 12:41
(Received via mailing list)
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
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 12:41
(Received via mailing list)
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
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 13:00
(Received via mailing list)
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/...
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
111a08d93ad6b7c5b4f5eb09c45c746d?d=identicon&s=25 Robert Paprocki (Guest)
on 2014-07-01 13:03
(Received via mailing list)
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.
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 13:32
(Received via mailing list)
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 Paprocki 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.
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-07-01 14:17
(Received via mailing list)
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 Dounin
http://nginx.org/
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 14:34
(Received via mailing list)
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
40b4c848b8fcd63b0cb60b9d170c3a77?d=identicon&s=25 Valentin V. Bartenev (Guest)
on 2014-07-01 14:39
(Received via mailing list)
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
9c50ac7dd6daee206e621bddce7b8877?d=identicon&s=25 Lucas Rolff (Guest)
on 2014-07-01 14:51
(Received via mailing list)
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
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-07-01 14:51
(Received via mailing list)
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 Dounin
http://nginx.org/
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.