# Reverse proxy deleting ETag header from response

**URL:** <https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209>\
**Category:** NGINX\
**Created:** [September 12, 2013, 1:08pm UTC](https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209 "2013-09-12T13:08:16Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\
**Post date:** [September 12, 2013, 1:08pm UTC](https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209/1 "2013-09-12T13:08:16Z")

</div>

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/](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:

> **[Reverse proxy deleting ETag header from response](https://forum.nginx.org/read.php?2,242807,242807#msg-242807)**
>
> 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;

---

<div class="post-metadata">

**Author:** ![ochronus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/8491ac/32.png) [@ochronus](https://www.ruby-forum.com/u/ochronus)\
**Post date:** [September 12, 2013, 1:59pm UTC](https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209/2 "2013-09-12T13:59:41Z")

</div>

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.

> **[nginx: donation](http://nginx.org/en/donation.html)**

---

<div class="post-metadata">

**Author:** ![ochronus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/8491ac/32.png) [@ochronus](https://www.ruby-forum.com/u/ochronus)\
**Post date:** [September 12, 2013, 2:07pm UTC](https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209/3 "2013-09-12T14:07:51Z")

</div>

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:

> **[Re: Reverse proxy deleting ETag header from response](https://forum.nginx.org/read.php?2,242807,242810#msg-242810)**
>
> 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;

---

<div class="post-metadata">

**Author:** ![ochronus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/8491ac/32.png) [@ochronus](https://www.ruby-forum.com/u/ochronus)\
**Post date:** [September 12, 2013, 2:46pm UTC](https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209/4 "2013-09-12T14:46:25Z")

</div>

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.

> **[nginx: donation](http://nginx.org/en/donation.html)**

---

<div class="post-metadata">

**Author:** ![ochronus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/8491ac/32.png) [@ochronus](https://www.ruby-forum.com/u/ochronus)\
**Post date:** [September 12, 2013, 3:06pm UTC](https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209/5 "2013-09-12T15:06:52Z")

</div>

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

Posted at Nginx Forum:

> **[Re: Reverse proxy deleting ETag header from response](https://forum.nginx.org/read.php?2,242807,242812#msg-242812)**
>
> 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;

---

<div class="post-metadata">

**Author:** ![ochronus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/8491ac/32.png) [@ochronus](https://www.ruby-forum.com/u/ochronus)\
**Post date:** [September 12, 2013, 5:24pm UTC](https://www.ruby-forum.com/t/reverse-proxy-deleting-etag-header-from-response/246209/6 "2013-09-12T17:24:13Z")

</div>

On 12 Sep 2013 14:06, “ochronus” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

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

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