Russian Apache Switch to English
Switch to Russian koi8-r
windows=1251
cp-866
iso8859-5
Russian Apache Как это работает Рекоммендации Где взять Как установить Как настроить Статус и поддержка
Краткий обзор FAQ Список рассылки Благодарности Поиск по серверу Powered by Russian Apache
Russian Apache mailing list archive (apache-rus@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-rus] Vary (кажись, в самое время :)



   Hi Alex!

Saturday, May 22, 1999, you wrote:

AT>  alr> исключить возможность "залипания" страниц с одной кодировкой в кэше. в
AT>  alr> качестве кэше имеется в виду squid.
AT> Задача не решается.
Решается. И даже решена. Патчами.

AT> Отцы, вы что, все с ума посходили ? Я уже много раз приводил один и тот же 
AT> пример, суть которого сводится к тому, что:
AT>  - если мы не выдаем Vary: что-то, то документ таки залипнет в кэше
AT>  - если он залип в кэше, то следующий клиент, у которого стоит заголовок
AT>    Что-То: value
AT>    получит этот документ из кэша, а не с сервера. И, соответственно, с
AT>    неправильным содержимым.
Угу. А можно попросить перейти от общетеоретических рассуждений к конкретным
примерам? Пример должен содержать в себе указание на конкретный браузер
пришедший с _правильным_ accept-charset, который в результате вышеописанного
поведения получит неправильную кодировку. А так же частоту использования
оного браузера на фоне "неправильных", для которых такое поведение более
приемлимо. Иначе эта логика выглядит следующим образом "мы делаем строго по
стандарту, а то что в 90% случаев это не помогает, а мешает нас не интересует".
Может вся рота авторов браузеров и посходила с ума, конечно, но что это
меняет-то?

AT> Ну не бывает чудес. Если мы хотим кэшировать server-negotiated документы,
AT> то для части пользователей они будут negotiated неправильно т.к. отданы
AT> будут из кэшей, а не с сервера. С редиректами та же фигня. Если клиент
AT> пришел с Accept-Charset: ibm866  на port 8100 (подразумеваем koi8),
AT> то кэш отдаст ему документ в koi8, а не редирект на другой порт (что сделал бы 
AT> сервер).
А как же. Конечно. Только после такого рассуждения очень невредно задуматься
над мелким вопросом - для _какой_ "части клиентов".
Это - во-первых. Но есть ещё и во-вторых, который куда как важнее.
Значит ради тех самых "ручных запросов" - а зачем бы пользователю иначе вводить
порт руками, кроме желания "потестировать систему" - будем игнорировать все
остальные соображения? _Реальный_ клиент не будет приходить (первично)
на конкретный порт. И если его браузер поддерживет accept-charset он свой
Vary получит. Или Вы предполагаете, что браузер затребовавший index в koi8
захочет получать остальные в ibm866? ;-)
Ещё раз - давайте рассмотрим предлагаемую Вами ситуацию. Итак пришёл
клиент с неправильным accept-charset (точнее без него) по каким-то
соображениям отредиректился на 8081 и в кэше осел документ бех Vary в
koi8-r. После этого пришёл другой клиент который имеет правильный
accept-charset и желает ibm-866. Но он пришёл не с урлом документа! Он
пришёл с запросом индекса. На 80й порт. И получил свой документ с Vary. А
пготом тот документ который сидел в кэше он получил с 8084 в koi8-r. И с
точки зрения кэша это _другой_ документ. Который прекраснейшим образом
кэщируется.
Всё отличе Вашего подхода и описываемого состоит в следующем - Вы
рассматривает все порты как "автоматические многоязыковые сервера". А я (мы)
говорим о том, что ситуация _одного_ "автоматического" и нескольких
"фиксированных" серверов значительно более полезна.

AT> У меня такое впечатление, что на эту тему я общаюсь с какими-то роботами.
AT> Ну поэкспериментируйте с тем же сквидом и вручную сделанными запросами, если
AT> объяснения не доходят. Извините если кого обидел.
А можно попросить об ответном эксперименте? Спасибо :). Возьмите свой
собственный сервер (а лучше не только его) и попробуйте посмотреть статистику
запросов с правильным accept-charset от клиента. Интересно процентов 10
наберётся?

AT>  alr> будет иметь не очень удобный вид. Тут, думаю, возможно такое решение -
AT>  alr> если сервер принимая запрос на 80-том порту, исходя из запроса клиента
AT>  alr> не может сделать вывод о требуемой кодировке
AT> Сервер всегда может сделать вывод о требуемой кодировке. На то есть 
AT> CharsetDefault, а если его нет, то используется Charset, описанный первым.
И кто изображает из себя робота, а? :) Несколько раз уже говорено - надо
отличать ситуацию дефолтов от ситуации (например) портов. Рассматривать порт
как _уникальный_ сервер с _фиксированным_ charset. Как и почему происходит
редирект на этот порт, ворос отдельный и сейчас речь совсем не о том.

AT> p.s. Витя (Хименко), помоги мне от них отбиться. У меня красноречия что-то не
AT> хватает.
А может проще патч сделать? :) О! Могу предложить простой вариант - сделайте
это условной трансляцией.

Best regards,
 Iouri                            mailto:bc-info@styx.cabel.net







Спонсоры сайта:

[ Russian Apache ] [ Как это работает ] [ Рекомендации ] [ Где взять ] [ Как установить ] [ Как настроить ] [ Статус и поддержка ] [ Краткий обзор ] [ FAQ ] [ Список рассылки ] [ Благодарности ] [ Поиск по серверу ] [ Powered by Russian Apache ] [ Apache-talk archive ]

"Russian Apache" includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/) See Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C) 1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.