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 Releases · nginx/nginx · GitHub.
My config looks as following:
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).
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.
Do you have a link to a documentation that has info about this then?
Because in the below link, and in Module ngx_http_proxy_module theres nothing
about what it accepts.
Do you have a link to a documentation that has info about this then?
Because in the below link, and in Module ngx_http_proxy_module theres nothing
about what it accepts.
How about the doc you already found, and then the link that it contains:
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.
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.
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.
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.
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.)
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.
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.
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.
