Reverse proxy deleting ETag header from response

I have a simple config that proxies to/from a django app:

upstream django_app{
server 127.0.0.1:4567;
}

server {
listen 80;
server_name xxxxxxxxx;

location / {
    proxy_pass_header Set-Cookie;
    proxy_pass_header ETag;
    proxy_pass http://django_app;
}

}

My problem is that nginx deletes the ETag header from the response even
if I
specify proxy_pass_header ETag.
The upstream server does return the correct headers:

curl -v http://127.0.0.1:4567/

  • About to connect() to 127.0.0.1 port 4567 (#0)
  • Trying 127.0.0.1…
  • Connected to 127.0.0.1 (127.0.0.1) port 4567 (#0)

GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: 127.0.0.1:4567
Accept: /

< HTTP/1.1 200 OK
< Server: gunicorn/0.17.2
< Date: Thu, 12 Sep 2013 11:06:18 GMT
< Connection: close
< Transfer-Encoding: chunked
< ETag: 495e0dc4-923c-4a99-8957-e6bbbc89cf5a
< Content-Type: text/html; charset=utf-8
< Cache-Control: Cache-Control:private, must-revalidate,
proxy-revalidate

Any ideas? Thanks in advance.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,242807,242807#msg-242807

Hello!

On Thu, Sep 12, 2013 at 07:07:29AM -0400, ochronus wrote:

[…]

My problem is that nginx deletes the ETag header from the response even if I
specify proxy_pass_header ETag.
The upstream server does return the correct headers:

The ETag header is removed if nginx changes a response returned.
That is, if you have gzip, gunzip, sub, addition, ssi or xslt
filters applied to responses returned.


Maxim D.
http://nginx.org/en/donation.html

Thanks a lot for the quick response!
Indeed, I had gzip turned on globally.
This is still strange though, is there no way to pass the Etag header
from
the upstream in this case?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,242807,242810#msg-242810

Hello!

On Thu, Sep 12, 2013 at 08:07:00AM -0400, ochronus wrote:

Thanks a lot for the quick response!
Indeed, I had gzip turned on globally.
This is still strange though, is there no way to pass the Etag header from
the upstream in this case?

The ETag header used in it’s strong from means that it must be
changed whenever bits of an entity are changed. This basically
means that ETag headers have to be removed by filters which change
a response content.

Weak ETags may be preserved, though they are not supported by
nginx yet. Mostly because Last-Modified is good enough
alternative to week ETags.


Maxim D.
http://nginx.org/en/donation.html

Thank you again for your exhaustive answer.
I think I won’t drop HAProxy so soon :wink:

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,242807,242812#msg-242812

On 12 Sep 2013 14:06, “ochronus” [email protected] wrote:

Thank you again for your exhaustive answer.
I think I won’t drop HAProxy so soon :wink:

As an aside, I’m pretty sure HAP doesn’t do /anything/ meaningful with
etags as it doesn’t examine response bodies’ content, nor does it cache.
Very happy to be told otherwise, but you may merely be seeing
unintended
consequences if HAP seems to be doing something more appropriate with
your
upstream’s replies.

HTH,
J

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