Среда Google App Engine Flex: заголовок ETag HTTP удален, когда ресурс gzip'd?

Question

У меня есть специальное приложение Node.js, развернутое в гибкой среде Google App Engine, в которой используются динамически вычисляемые дайджест-хэши для установки заголовков ответов ETag HTTP для определенных ресурсов. Это отлично работает на экземпляре AWS EC2. Но не в гибкой среде Google App Engine; в некоторых случаях Google App Engine, по-видимому, удаляет настраиваемый заголовок HTTP-ответа ETag моего приложения, и это серьезно снижает производительность приложения. И, будет без необходимости дорогой.

В частности, создается впечатление, что гибкая среда Google App Engine удаляет заголовок ETag моего приложения, когда оно соответствует допустимым ресурсам gzip.

Например, если я использую curl для запроса ресурса utf8 :: application / json И не указываю, что я приму ответ в сжатом формате, тогда все будет работать так, как я ожидал - ресурс возвращается вместе с моим пользовательский заголовок ETag, который представляет собой дайджест-хеш данных ресурса.

curl https://viewpath5.appspot.com/javascript/client-app-bundle.js - verbose

... мы получаем client-app-bundle.js в качестве несжатого ресурса UTF8 вместе с заголовком ответа ETag HTTP, значение которого представляет собой дайджест-хеш данных файла JavaScript.

Однако, если я эмулирую свой браузер и задаю заголовок HTTP-запроса Accept-Encoding, чтобы указать Google App Engine, что мой пользовательский агент (здесь curl) будет принимать сжатый ресурс, то я никогда не получу заголовок HTTP-ответа ETag .

$ curl --verbose https://xxxxxxxx.appspot.com/javascript/client-app-bundle.js
* Hostname was NOT found in DNS cache
*   Trying zzz.yyy.xxx.www...
* Connected to xxxxxxxx.appspot.com (zzz.yyy.xxx.www) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=*.appspot.com
*        start date: 2019-05-07 11:31:13 GMT
*        expire date: 2019-07-30 10:54:00 GMT
*        subjectAltName: xxxxxxxx.appspot.com matched
*        issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3
*        SSL certificate verify ok.
> GET /javascript/client-app-bundle.js HTTP/1.1
> User-Agent: curl/7.38.0
> Host: xxxxxxxx.appspot.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Thu, 23 May 2019 00:24:06 GMT
< Content-Type: application/javascript
< Content-Length: 4153789
< Vary: Accept-Encoding
< ETag: @encapsule/holism::kiA2cG3c9FzkpicHzr8ftQ
< Cache-Control: must-revalidate
* Server @encapsule/holism v0.0.13 is not blacklisted
< Server: @encapsule/holism v0.0.13
< Via: 1.1 google
< Alt-Svc: quic=":443"; ma=2592000; v="46,44,43,39"
< 
/******/ (function(modules) { // webpackBootstrap
/******/        // The module cache
/******/        var installedModules = {};
/******/
.... and lots more JavaScript. Importantly note ETag in HTTP response headers.

СЖАТЫЙ (ОТКАЗ) СЛУЧАЙ:

$ curl --verbose -H "Accept-Encoding: gzip" https://xxxxxxxx.appspot.com/javascript/client-app-bundle.js
* Hostname was NOT found in DNS cache
*   Trying zzz.yyy.xxx.www...
* Connected to xxxxxxxx.appspot.com (zzz.yyy.xxx.www) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=*.appspot.com
*        start date: 2019-05-07 11:31:13 GMT
*        expire date: 2019-07-30 10:54:00 GMT
*        subjectAltName: xxxxxxxx.appspot.com matched
*        issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3
*        SSL certificate verify ok.
> GET /javascript/client-app-bundle.js HTTP/1.1
> User-Agent: curl/7.38.0
> Host: xxxxxxxx.appspot.com
> Accept: */*
> Accept-Encoding: gzip
> 
< HTTP/1.1 200 OK
< Date: Thu, 23 May 2019 00:27:15 GMT
< Content-Type: application/javascript
< Vary: Accept-Encoding
< Cache-Control: must-revalidate
* Server @encapsule/holism v0.0.13 is not blacklisted
< Server: @encapsule/holism v0.0.13
< Content-Encoding: gzip
< Via: 1.1 google
< Alt-Svc: quic=":443"; ma=2592000; v="46,44,43,39"
< Transfer-Encoding: chunked
< 
�}{{G���˧�(�.rb�6`����1ƀw���,���4�$�23,���UU_碋-��

Нет ETag?

Мне кажется неправильным, что пользовательский заголовок ответа ETag HTTP моего приложения удален; Сжатие gzip на сервере и последующая распаковка в пользовательском агенте должны быть полностью инкапсулированы как подробности реализации сетевого транспорта?

Answer 1

Такое поведение вызвано прокси-контейнером на стороне прокси-сервера NGINX, который обрабатывает запросы на GAE flex.

NGINX удаляет заголовки ETag при сжатии содержимого, возможно, для соответствия строгой семантике идентификации ETag, которая является байтом-байтово, но не уверен в этом.

К сожалению, нет способа настроить прокси NGINX в GAE Flex (кроме ручного SSHing в контейнер в каждом случае, изменения nginx.comf и перезапускапрокси nginx).

Единственный известный мне обходной путь - ослабить строгость ETag, сделав его "слабым", добавив "W /" к значению, указанному в https://tools.ietf.org/html/rfc7232.

. Этоне задокументировано.Уже есть внутренний запрос на функциональность для команды разработчиков App Engine, чтобы включить это поведение в нашу общедоступную документацию.