Along with nginx-1.1.4, a new directive named ‘proxy_http_version’
introduced
I thought it was something related to the communication between nginx
cache and upstream web server, right?
But per my tests with latest v-1.2.1, Nginx is still using HTTP/1.0 to
access upstream web server.
+++++++++
abc $ curl -I -H ‘If-None-Match: “9cx7b1-x2e-44xa4x9axd0x0”’ http://test.stg/crossdomain.xml
HTTP/1.1 200 OK
Server: nginx/1.2.1
…
+++++++++ end
Which intends to return 3.4 if it’s using HTTP/1.1, did I misunderstand
this directive?
On Tue, Jul 03, 2012 at 04:22:14AM -0400, admon.org wrote:
Hi there,
Along with nginx-1.1.4, a new directive named ‘proxy_http_version’
introduced
I thought it was something related to the communication between nginx
cache and upstream web server, right?
On Tue, Jul 03, 2012 at 09:58:12AM -0400, admon.org wrote:
Many thanks Francis!
Here are my configs, I’m using Nginx as a reverse proxy server to cache
static files from its upstream servers.
[…]
the upstream server.
Can you help have another check. Appriciated!
With cache switched on nginx strips all conditional headers in
requests to backends to make sure it’ll get full response which
may be cached. And as nginx itself doesn’t support entity tags
yet, the request with If-None-Match doesn’t return 304.
Support for entity tags are expected to appear soon, somewhere
near upcoming 1.3.3.
I’m trying to implement a smart way to purge cache e.g. by touching the
file to change its etag. This needs the HTTP/1.1 support. But per my
tests, Nginx does not return expected value.
This command gives 200 OK return code, but if I use Varnish instead, it
gives the expected value 304 Not Modified.
So I’m wondering that it may be caused by the protocal between Nginx and
the upstream server.