Nginx не запрашивает запросы кэширования через ELB

Question

У меня есть nginx, сидящий между ELB. У меня есть несколько пулов приложений за ELB, на которые nginx передает трафик, и я хочу кэшировать статический контент. Моя проблема - nginx, похоже, не кэширует никаких ответов. Это конфигурация кэша:

proxy_cache_path /usr/share/nginx/cache/app levels=1:2 keys_zone=cms-cache:8m max_size=1000m inactive=600m; 
proxy_temp_path /usr/share/nginx/cache/; 

    location/{ 
    proxy_pass http://cms-pool; 
    proxy_cache cms-cache; 
    proxy_cache_valid 200 302 60m; 
    proxy_cache_valid 404  1m; 
    } 

После некоторого чтения я нашел там могут быть некоторые заголовки, вызывающие проблемы, но после того, как скрытие очевидные я не заладилась и в конечном итоге разорвать приложение, так как я прятался все серверные куки , Это заголовки я попытался удалить:

proxy_ignore_headers Cache-Control Expires Set-Cookie; 
proxy_hide_header Cache-Control; 
proxy_hide_header Set-Cookie; 

Я теряюсь прямо сейчас, почему запросы не кэшируются, вот выход из завитка заголовков, проникал с конфигурацией выше заголовка (печенье и такие были установлены с Nginx/УДР перед Nginx):

Accept-Ranges: bytes 
Connection: keep-alive 
Content-length: 6821 
Content-Type: text/html 
Date: Sun, 16 Nov 2014 19:25:41 GMT 
ETag: W/"6821-1415964130000" 
Expires: Thu, 01 Jan 1970 00:00:00 GMT 
HTTP/1.1 200 OK 
Last-Modified: Fri, 14 Nov 2014 11:22:10 GMT 
Pragma: no-cache 
Server: nginx/1.7.6 
Set-Cookie: AWSELB=4BB7AB49169E74EC05060FB9839BD30C2CB1D0E43D90837DC593EB2BA783FB372E90B6F6F575D13C6567102032557C76E00B1F5DB0B520CF929C3B81327C1D259A9EA5C73771C4EA3DB6390EB40484EDF56491135B;PATH=/ 
Set-Cookie: frontend=CgAAi1Ro+jUDNkZYAwMFAg==; path=/ 

---

Update Я обнаружил, что выше было не совсем точным, поскольку есть в 302, который направляет пользователя для входа в систему, которая поражает другой бэкэнд, который не имеет tic-ресурсы, поэтому заголовки выше поступают из бэкэнда входа. Я скорректировал URI, чтобы указать только на изображения, но кэширование не происходит. Я использую следующие местоположения блок:

location /app/images { 
    proxy_pass http://cms-pool/app/images; 
    proxy_cache cms-cache; 
    proxy_cache_valid 200 302 60m; 
    proxy_cache_valid 404  1m; 
    proxy_ignore_headers Cache-Control Expires Set-Cookie; 
    proxy_hide_header Cache-Control; 
    proxy_hide_header Set-Cookie; 
    } 

Это заголовки, которые приходят через в настоящее время:

Accept-Ranges: bytes 
Connection: keep-alive 
Content-length: 12700 
Content-Type: image/png 
Date: Mon, 17 Nov 2014 09:25:38 GMT 
ETag: "0cd80ce9afecf1:0" 
HTTP/1.1 200 OK 
Last-Modified: Wed, 12 Nov 2014 17:05:06 GMT 
Server: nginx/1.7.6 
Set-Cookie: AWSELB=4BB7AB49169E74EC05060FB9839BD30C2CB1D0E43D638163025E92245C6C6E40197CA48C5B22F3E8FDA53365109BC1C16C808322881855C100D4AC54E5C0EC6CDE91B96151F66369C7B697B04D2C08439274033D81;PATH=/ 
Set-Cookie: tscl-frontend=CgAK1FRpvxI4b0bQAwMEAg==; path=/ 
X-Powered-By: ASP.NET 

Answer 1

Это вызван шаткими реализациями заголовков HTTP кэширования в то, что за УДРО.

Per RFC 2616 (HTTP 1.1):

директивы Pragma должны быть прошли через прокси-сервером или шлюзом приложения, независимо от их значимости к этому приложению, поскольку директивы могут быть применимы ко всем получателей по цепочке запроса/ответа .

HTTP/1.1 кэши ДОЛЖЕН обработать "Pragma: нет-кэш" как если бы клиент был послал "Cache-Control: нет кэша". Никаких новых директив Pragma не будет , определенных в HTTP.

Примечание: поскольку смысл «Pragma: нет кэша как поле заголовка ответа на самом деле не указано, она не обеспечивает надежную замену„Cache-Control: нет-кэша“в ответ

заголовок Pragma: no-cache ничего в качестве HTTP-ответа не значит, потому что это поведение неопределенные от РЛК.

Но Nginx выступает в качестве (реверс) прокси-сервер в вашем случае, это будет чтить час eader, как будто это был заголовок Cache-Control: no-cache, чтобы поддерживать совместимость с заголовком Pragma протокола протокола HTTP 1.0, определенным в RFC 1945.

Он также передаст его через заголовки ответов клиента, поскольку он не должен ничего предполагать о фактическом значении этого.

Так что либо исправить эту плохую реализацию, либо добавить Pragma заголовок в proxy_ignore_headers и proxy_hide_header директивы.