Как я могу контролировать поведение кэширования Google App Engine в WebKit (etags gone crazy)?
Ситуация: запуск сайта Google App Engine с параметром default_expiration моего статического содержимого " 14d "
Проблема: в Chrome и Safari, посетив URL (не перезагрузка, просто поместите курсор в адресную строку и нажмите Enter), вызывает тонну запросов, которые будут запущены с заголовками If-None-Match. Ответы всегда остаются неизменными, как и ожидалось. Я могу наблюдать, как эти запросы запускаются в отладочном прокси-сервере, таком как Charles или Скрипач.
Хотите: чтобы избежать этих запросов и 304 ответов полностью для статического контента - просто доверяйте кэшированному контенту браузера, когда он доступен.
Мы используем стандартный " кэш статического содержимого в течение действительно длительного времени, мы будем заботиться о добавлении ?version = {version} модификации наших строк запроса, когда нам нужно сломать систему кэша, поэтому мы действительно хотели бы избежать 304-х.
Вера: я думаю, что это вызвано заголовком etag, который движок приложения посылает вниз с каждым статическим ответом контента. SDK App engine неотправляет этот заголовок вниз, и я не вижу такого поведения 304, когда возишься с SDK.
Какой-нибудь совет? Можно ли отключить etags для статического содержимого app engine?
Обновлено с помощью примера фрагмента статического содержимого: http://www.khanacademy.org/stylesheets/shared-package/compressed.css
7 ответов:
Хотя я не верю, что существует какой-либо способ контролировать поведение заголовка etags для GAE, это вызвано ошибкой в WebKit, которая заставляет все статическое содержимое повторно загружаться при получении 302 перенаправления после запроса POST.
Как только WebKit исправит эту ошибку, проблема должна исчезнуть.
Если необходимо, вы можете временно обойти эту конкретную ошибку перенаправления после публикации, перенаправив ее через заголовок обновления вместо использования 302 перенаправлять.
Https://bugs.webkit.org/show_bug.cgi?id=38690
WebKit image reload on Post / Redirect / Get
Http://www.google.com/support/forum/p/Chrome/thread?tid=72bf3773f7e66d68&hl=en
Необходимо удалить заголовки Last-Modified и ETag.
Удалив заголовок ETag, вы отключаете кэш и браузеры от возможности проверки файлов, поэтому они вынуждены полагаться на ваш заголовок Cache-Control и Expires. Теги сущностей (ETags) - это механизм проверки новой версии кэшированного файла.
Удалив заголовок Last-Modified и ETag, вы полностью исключите запросы If-Modified-Since и If-None-Match и их 304 не измененных ответа, так что файл будет оставаться в кэше без проверки наличия обновлений, пока заголовок Expires не укажет, что новое содержимое доступно.
Подробнее здесь: http://www.samaxes.com/2008/04/htaccess-gzip-and-cache-your-site-for-faster-loading-and-bandwidth-saving/.
К сожалению, я не знаю, как вы можете отключить их для статического контента Гая.
Chrome 9.0, Windows. При загрузке домашней страницы-по умолчанию.css, как и все остальное .css файлы подаются из кэша, без запроса. Я думаю, что это специфическое поведение браузера,вам нужно проверить и другие браузеры.
Кроме того, проверьте эту инструкцию Google, они очень помогли мне при настройке параметров кэширования: http://code.google.com/speed/page-speed/docs/caching.html
Поскольку это проблема с Chrome и Safari, вы можете использовать HTML5 App Cache, чтобы полностью предотвратить вызовы сервера на статические ресурсы. Посмотрите пример здесь .
Ваше значение ETag в порядке. ETag не вызывает повторной валидации. Это просто позволяет ему быть более надежным, чем дата последней модификации. Я только что просмотрел ваш пример статического контента с помощью Chrome 9, и ваш контент кэшируется и не подвергается ненужной переоценке. Проблема, которую вы видели, может быть связана с настройками браузера" всегда повторно проверять", которые не являются стандартными для большинства браузеров. Это также может быть ошибка, связанная с Mac webkit.
Попробуйте посмотреть, происходит ли то же самое, когда вы не нажимаете "enter" или "обновить", а просто переходите по ссылке. Ваш браузер делает что-то другое в этом случае. Safari, в частности, делает запросы только так, как они должны быть сделаны, если вы не используете refresh или явно не запрашиваете страницу снова.
Вы можете попробовать это очень просто на 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 не отправляет заголовок.