Firefox не использует кэшированную копию файла после 304 - PullRequest
2 голосов
/ 11 мая 2011

Я вижу поведение в Firefox, которое кажется мне неожиданным.Это не особенно повторяется (к сожалению), но время от времени возникает. После запуска повторяется при обновлении страницы до полного обновления (ctrl-f5).В прошлый раз мне удалось получить трассировку.

По сути, FF4.0.1 запрашивает ресурс (из приложения ASP.NET MVC 3, работающего под IIS7):

GET http://www.notarealdomain.com/VersionedContent/Scripts/1.0.40.5653/jquery.all.js HTTP/1.1
Host: www.notarealdomain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: */*
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://www.notarealdomain.com/gf
If-Modified-Since: Sat, 01 Jan 2000 00:00:00 GMT

Затемполучает следующий ответ от сервера (через прокси-сервер, но в журналах сервера IIS я вижу, что запрос был выполнен до самого сервера):

HTTP/1.1 304 Not Modified
Date: Mon, 09 May 2011 14:00:47 GMT
Cache-Control: public
Via: 1.1 corp-proxy (NetCache NetApp/6.0.3P2D5)

Это кажется разумным - клиент делает условный запрос (если изменен с тех пор), и сервер отвечает «хорошо - используйте вашу копию» (304 Не изменено).

Проблема в том, что клиент в этом случае тогдане заполняет файл - он ведет себя так, как если бы не было содержимого (т. е. если изображение, оно не отображается, если js ведет себя так, как будто файл .js отсутствует на странице, если .css, то страница отображаетсябез стилей CSS и т. д.).Это видно как на самой веб-странице, так и при использовании превосходного инструмента HttpWatch .HttpWatch ясно показывает, что в браузере был элемент в кэше, но он не использовал его в качестве источника контента.

Что мне здесь не хватает?Вышеприведенный разговор кажется разумным, так почему же FF делает условный запрос, а затем не использует свою кэшированную копию, когда это сказано?Если затем нажать Ctrl-F5 для принудительного полного обновления, поведение исчезнет и будет возвращаться только время от времени.

У нас также есть некоторые неподтвержденные доказательства того, что это происходит и с FF3 и Chrome, но мы не подтвердили этос любыми данными судебной экспертизы.

Кто-нибудь еще видел это, и кто-нибудь знает, что может пойти не так, или какие дальнейшие действия могут изолировать проблему?

1 Ответ

3 голосов
/ 01 июня 2011

ОК - я дошел до сути этой проблемы.Как всегда - ответ пялился мне в лицо!

Проблема была вовсе не в поведении кэширования.Другая часть системы время от времени вызывала сбои и записывала файл нулевой длины , который кэшировался Firefox.

Поэтому, когда Firefox отправил условный запрос на сервер и получил его 304 /Не измененный, он покорно ушел и использовал поврежденную версию файла нулевой длины, которую он нашел в своем кеше.

Все признаки были там для меня, чтобы увидеть - просто потребовалось немного времени, чтобы добраться туда:)

Спасибо всем за ваши комментарии и предложения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...