Вопрос:

Кэширование с помощью Rails-приложения и браузера Chrome

google-chrome ruby-on-rails-4 browser-cache

317 просмотра

1 ответ

4467 Репутация автора

Я ожидаю, что приложение должно ответить кодом 304 вместо 200. Но даже если IF-NONE-MATCH равно ETAG, этого не происходит.

Я использую «Cache-Control: no-cache», чтобы не хранить ответ в кэше, который будет проверяться каждый раз. В противном случае Chrome использует дисковый кеш, что недопустимо.

Запрос:

GET /api/v4/record/11728 HTTP/1.1
Host: host.domain.com
Connection: keep-alive
Authorization: Basic YWRtaW467Uc2Zs0eTIwMTM=
Origin: https://host.domain.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Accept: application/json, text/plain, */*
DNT: 1
Referer: https://host-ui.domain.com/some_page
Accept-Encoding: gzip, deflate, sdch, br
If-None-Match: W/"39dcd8467e47701a69c617333f7b6dac"
If-Modified-Since: Thu, 13 Apr 2017 16:09:25 GMT
Name

Отклик:

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,PATCH,HEAD,OPTIONS
Access-Control-Allow-Origin: https://host-ui.domain.com
Cache-Control: no-cache
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Thu, 13 Apr 2017 16:20:31 GMT
ETag: W/"39dcd8467e47701a69c617333f7b6dac"
Last-Modified: Thu, 13 Apr 2017 16:09:25 GMT
Server: nginx/1.8.1 + Phusion Passenger 4.0.60
Status: 200 OK
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Powered-By: Phusion Passenger 4.0.60
X-Request-Id: ab87433e-62bd-437f-ad7c-0e1d3f95257b
X-Runtime: 0.209121
X-XSS-Protection: 1; mode=block
transfer-encoding: chunked
Connection: keep-alive

В приложении общее действие выглядит так:

  def action

    record = Model.find(params['id'])

    if stale?(record)
      hard_work_result = to_do_somethig
      render json: {
          success: 0,
          result: hard_work_result
      }
    end
  end
Автор: NeverBe Источник Размещён: 13.04.2017 04:35

Ответы (1)


2 плюса

2161 Репутация автора

Кажется, за этим стоит история, но короткая история: gzip работает с
Weak ETag Weak ETag: ETag: W/"8763458...
Strong ETag:ETag: "8763458...

Вы можете проверить, что это проблема, если вы используете cURL и отключаете gzip Accept-Encoding(или используете modheaders в chrome: отключите сжатие gzip в chrome )

Рекомендации:

Получение ответа 304 в Chrome / Safari, но с помощью curl
https://masa331.github.io/2016/01/06/roda-etag-caching-gotcha.html
Слабые ETAG в Rails?

Решение?

При запуске из самого nginx проблема не возникала. Первая ссылка выше предполагает, что если у вас возникла проблема изнутри nginx, то добавление etag on;после после gzip on;исправления проблемы. В частности, хотя слабые этаги не были возвращены. Казалось бы, запуск изнутри nginx - единственный вариант, если вы хотите включить gzip.

мои версии

Server: nginx/1.10.2 + Phusion Passenger 5.1.2`)

ii  ruby-rails                      2:4.2.6-1
ii  ruby2.3                         2.3.1-2~16.04

Мне удалось обойти эту проблему при работе в автономном режиме пассажира, отредактировав файл nginx.conf.erb и отключив gzip. Для этого сначала нужно получить шаблон файла conf:

passenger start --debug-nginx-config

это поместит файл с именем nginx.conf.erb в ваш текущий каталог. Затем вы можете отредактировать этот файл, чтобы сказать:

gzip off;

а затем начать пассажир снова с этим файлом

passenger start --nginx-config-template nginx.conf.erb

смотрите здесь для получения подробной информации о загрузке и использовании nginx.conf.erb

В любом случае вы должны увидеть, что слабые etags не возвращаются

Автор: spacepickle Размещён: 25.04.2017 04:30
Вопросы из категории :
32x32