nginx-0.3.61

Daniel Rx rx.daniel at gmail.com
Tue Aug 29 14:00:08 MSD 2006


Здравствуйте! Извините за оффтоп, но, прочитав это
"За некоторыми MSIE 6 замечено, что
если после редиректа он берёт страницу из кэша, то он не обращает
внимание даже на meta. Возможно, дело в том, что страница была сжата,
но не уверен. Научные исследования показали, что если вместо редиректа",
вспомнил, что была (и вобщем-то есть) такая проблема (если это проблема):
когда IE в Win2k и WinXP (с другими версиями IE не сталкивался) принимает
сжатую страничку
и имеется заголовок Cache-Control: no-cache, он почему-то не дает смотреть
исходник страницы,
т.е. просто не грузит ассоциированную программу (notepad или wordpad). В
опере и firefoxe такой
проблемы нет. Поэтому приходится менять Cache-Control: no-cache на
Cache-Control: must-revalidate, max-age=0
(для сессионных страниц). Кто-нить сталкивался с такой проблемой?

29.08.06, Igor Sysoev <is at rambler-co.ru> написал(а):
>
> On Tue, 29 Aug 2006, Михаил Монашёв wrote:
>
> > IS>      *) Добавление: директива msie_refresh.
> >
> >> Директива разрешает или запрещает выдавать для MSIE refresh'ы вместо
> редиректов.
> >
> > А в чём проблема была и что такое рефрешы?
>
> Если у MSIE стоит автоопределение кодировки, то когда он берёт русскую
> страницу из кэша, он может показать её в западноевропейской, турецкой,
> или даже японской кодировке. Частично это лечится указанием кодировки
> с помощью
> <meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
>
> Но это тоже помогает не всегда. За некоторыми MSIE 6 замечено, что
> если после редиректа он берёт страницу из кэша, то он не обращает
> внимание даже на meta. Возможно, дело в том, что страница была сжата,
> но не уверен. Научные исследования показали, что если вместо редиректа
> выдавать
> <meta http-equiv="Refresh" content="0; URL=http://....">
> то MSIE натурально идёт за страницей на сайт и тогда показывает её
> в правильной кодировке.
>
>
> Игорь Сысоев
> http://sysoev.ru
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20060829/81d20fc9/attachment.html>


More information about the nginx-ru mailing list