Подтвердить что ты не робот

Как я могу получить контроль над кешированием Google App Engine в WebKit (etags сошел с ума)?

Ситуация: работает сайт Google App Engine с моим статическим содержимым default_expiration, установленным на "14d"

Проблема: в Chrome и Safari, посетив URL-адрес (не перезагружая, просто поместив курсор в адресную строку и нажав Enter), вызывает тонну запросов, которые будут запущены с If-None- Заголовки матчей. Ответы всегда 304 не изменены, как и ожидалось. Я могу наблюдать, как эти запросы увольняются в прокси-отладке, таком как Charles или Fiddler.

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

Мы используем стандартный "статический контент кеша" в течение очень долгого времени, мы позаботимся о внесении изменений в версию version = {version} в наши строки запросов, когда нам нужно перегрузить систему кеша, поэтому мы действительно как избежать 304-х годов.

Вера: Я думаю, что это вызвано заголовком etag, который движок приложения отправляет с каждым статическим контентом. SDK приложения не отправляет этот заголовок вниз, и я не вижу этого поведения 304, когда возился с SDK.

Любые советы? Можете ли вы отключить etags для статического содержимого движка приложения?

Обновлено с примером части статического контента: http://www.khanacademy.org/stylesheets/shared-package/compressed.css

4b9b3361

ОТВЕТЫ

Ответ 1

Хотя я не верю, что есть какой-либо способ контролировать поведение заголовка etags для GAE, это вызвано ошибкой в ​​WebKit, которая заставляет все статические материалы повторно загружаться при получении перенаправления 302 после Запрос POST.

Как только WebKit исправляет эту ошибку, проблема должна исчезнуть.

Если вам нужно, вы можете временно обойти эту конкретную ошибку redirect-after-POST, перенаправив ее через заголовок Refresh вместо использования перенаправления 302.

https://bugs.webkit.org/show_bug.cgi?id=38690

Перезагрузка образа WebKit в Post/Redirect/Get

http://www.google.com/support/forum/p/Chrome/thread?tid=72bf3773f7e66d68&hl=en

Ответ 2

Вам нужно удалить заголовки Last-Modified и ETag.

Удалив заголовок ETag, вы отключите кеши и браузеры от возможности проверки файлов, поэтому они вынуждены полагаться на заголовок Cache-Control и Expires. Теги объектов (ETags) - это механизм проверки более новой версии кэшированного файла.

Удаление заголовка Last-Modified и ETag полностью исключает запросы If-Modified-Since и If-None-Match и их ответы 304 Not Modified, поэтому файл будет храниться в кеше без проверки обновлений до заголовка Expires указывает, что доступно новое содержимое.

Дополнительная информация здесь: http://www.samaxes.com/2008/04/htaccess-gzip-and-cache-your-site-for-faster-loading-and-bandwidth-saving/.

К сожалению, я не знаю, как вы можете отключить их для статического содержимого GAE.

Ответ 3

Chrome 9.0, Windows. При загрузке вашей домашней страницы default.css, а также все другие .css файлы подаются из кеша без запроса. Я думаю, что это поведение, характерное для браузера, вам нужно также проверить другие браузеры.

Кроме того, ознакомьтесь с инструкциями Google, они очень помогли мне при настройке параметров кэширования: http://code.google.com/speed/page-speed/docs/caching.html

Ответ 4

Поскольку это проблема с Chrome и Safari, вы можете использовать кэш-память HTML5, чтобы полностью исключить вызовы сервера на статических ресурсах. Пример здесь.

Ответ 5

Ваше значение ETag прекрасное. ETag не вызывает повторной аттестации. Он просто позволяет ему быть более надежным, чем последняя дата модификации. Я просто просмотрел ваш статический контент, используя Chrome 9, и ваш контент кэшируется и не переутверждается. Проблема, которую вы видели, может быть связана с настройками браузера "всегда повторно проверять", которые не являются стандартными для большинства браузеров. Это также может быть ошибка, связанная с веб-сайтом Mac.

Ответ 6

Попробуйте выяснить, произойдет ли одно и то же, когда вы не нажмете "enter" или обновите, но просто следуйте ссылке. В этом случае ваш браузер делает что-то другое. Safari, в частности, делает запросы только так, как они должны выполняться, если вы не используете обновление или явно запрашиваете страницу еще раз.

Вы можете попробовать это очень просто на Mac. Запустите простой сервер с netcat (nc) на каком-то порту, скажем, 9090:

nc -l 9090

Создайте простую страницу со ссылкой на http://localhost:9090 в ней, щелкните ее и посмотрите заголовки, отображаемые командой nc.

Вручную вернуть ответ, введя его в nc, например. что-то вроде

HTTP/1.0 200 OK
ETag: "xyz"
Content-type: text/plain

Some text.

Нажмите ссылку еще раз и посмотрите заголовок If-None-Match в запросе. Сделайте возврат после адреса в адресной строке, и вы увидите, что Safari не отправляет заголовок.