To francis

Thank you for your answer.

> the thing that your upstream sends is not a thing that nginx recognizes as a strong etag.
> The HTTP/1.1 RFC (https://tools.ietf.org/html/rfc7232#section-2.3) says that the etag header must be of the form

Oh, I wasn't aware of the thing.

> The best fix in your case is probably to change your upstream to send valid headers.

I tried making my upstream's header comply with the form that nginx recognize as a strong etag like below, then nginx got working to downgrade the strong etag to a weak one as I expected.

```diff
location /strong_etag {
- add_header Etag d41d8cd98f00b204e9800998ecf8427e;
+ add_header Etag '"d41d8cd98f00b204e9800998ecf8427e"';
default_type application/json;
return 200 '{"message": "Hello, this is from upstream!"}';
}
```

```shell
$ curl http://localhost:80/strong_etag -i -H "Accept-Encoding: gzip"
HTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Thu, 02 Jan 2020 16:49:06 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Etag: W/"d41d8cd98f00b204e9800998ecf8427e"
Content-Encoding: gzip

�V�M-.NLOU�RP�H����Q(��,V����\�҂⒢��\E�Z5[,%
```

The riddle was resolved.

---

To J.R.

Thanks for introducing https://github.com/openresty/headers-more-nginx-module
I'll check it.

---

Again, many thanks!