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

[Iouri Kharon <bc-info@styx.cabel.net>]

   Hi Alex!

Sunday, May 23, 1999, you wrote:


AT> я одно письмо из этого thread прощелкал и увидел только сейчас.
AT> Оно достаточно конструктивное, чтобы потрепаться еще.
Как скажете :)

AT>  alr> Естественно. Но так делать не стоит - далеко не всегда можно обработать
AT>  alr> по "сильным признакам" и именно поэтому нужно (когда нет/не
AT>  alr> срабатывают сильные) проверять и слабые признаки. В том числе и
AT>  alr> accept-charset. А предложенный метод отключает его "насовсем".
AT> У нас разное понятие о сильных и слабых признаках :). В моем понимании,
AT> самый сильный признак - Accept-Charset (т.к. описан в стандарте), сильные -
AT> URL-encoded, слабый - User-Agent
Вот! Вот тут и зарыта собака наших с Вами "разногласий". Я абсолютно
согласен с тем что User-Agent это самый слабый признак, а вот в части
сильных мы, действительно, _принципиально_ расходимся. Вы ставите на первое
место RFC (невзирая на то, что его практически никто не поддерживает в этой
части "как надо"), я - именно в силу вышеуказанной причины - "волю оператора
сервера". Ну, честное слово, не стоит аппелировать к чему-то вида "согласно
инструкции ВЦСПС от ...1929г" :)

AT>  alr> С этим я и не спорил. Я же говорил о том, что Vary в выдаче русского
AT>  alr> пачаа формируется _независимо_ от наличия accept-charset в запросе
AT>  alr> браузер и _независимо_ от того, по какому признаку (например порту,
AT>  alr> директориии и т.д,) выбрана кодировка.
AT> Чистая правда. Потому как Accept-Charset считается самым сильным и
AT> при его наличии будет учитываться только он.
А при его _отсутствии_? В том-то и состоит проблема (сколько Вы от неё
не отмахивайтесь), что минимум 80% запросов приходят _без_ него. И
_принудительно_ ставить его на первое место есть абсолютно _законно_, но
крайне _неразумно_.

AT>  alr> каких-то "высокотеоретических соображений", а просто потому, что без
AT>  alr> обсуждаемой правки (в том или ином виде) работать с документами с
AT>  alr> фрэймами и использованием старшие msie просто невозможно.
AT> К сожалению, старшие MSIE - HTTP/1.1-агенты и обязаны соблюдать RFC.
AT> Поэтому хотелось бы удовлетворить их не отказываясь от Vary.
Согласен. Но мне добиться такого его поведения "надёжно" так и не удалось.
Увы. И - не побоюсь повторить ещё раз - поведение старших msie
_укладывается_ в RFC. Толкуют они его, правда, по другому - ну так это к
авторма RFC претензии, а не к мс ;-)

AT> На крайний случай есть решение вида
AT> <VirtualHost www:8100>
AT> CharsetDisableAcceptCharset On
AT> </VirtualHost>
AT> Да, это несколько усложняет конфигурацию, но если у вас много virtualhost,
AT> то вы все-равно не вручную их конфигурируете, а если мало, то можно и руками.
Логично. И если Вы согласитесь сделать такое поведение дефолтным, то я буду
считать что цель достигнута :). Я ведь, говорил уже, дело не в том, как мне
настроить свои сервера - для этого существует много разных способов. Дело в
том, что _большинство_ пользователей русского апача оставляют конфигурацию в
состоянии близком к conf.default. И основной смысл моих попыток, как-то
защитить свою позицию перед Вами восе не в том, что бы не ставить патч на
следущие версии апача (всё одно прийдётся из-за security :), а в том, что бы
изменилось поведение их серверов.

AT>  alr> Согласен со второй частью но КАТЕГОРИЧЕСКИ не согласен с первой.
AT>  alr> Наивысший приоритет задаётся "оператором" сервера.
AT> Приоритет описан в RFC. Но у оператора таки есть возможность его поменять.
Это как? Не _отменить_, а именно "поменять приоритет"?
AT> Переносить Accept-Charset в хвост списка CharsetSelectionOrder просто 
AT> неправильно.
Я же которое письмо предлагаю перейти от позиции "правильно/неправильно"
(что у нас - конституционный суд, что ли? :) к вопросам _необходимости_.
Допустим, я принял Вашу интерпретацию RFC. И мы совместными усилиями
добились того самого "постановления ВЦСПС" :). И что от этого изменится? А
ничего - то тех пор пока большинство браузеров (и кэшей) не начнут соблюдать
RFC в такой интерпретации. А работают сервера на русском апаче сегодня, а не
в том "светлом будущем", когда это произойдёт. Потому-то я и пытаюсь сдвинуть
Вас с позиции "строгого соблюдения буквы закона".

AT>  alr> Так. Что-то я перестал понимать. Положим мы проставили в настройках
AT>  alr> CharsetByPort windows-1251 8080
AT>  alr> CharsetSelectionOrder Portnumber...
AT>  alr> Не поделитесь - откуда возьмётся "вариантность" при запросе url:8080?
AT>  alr> Только не забудьте то что _Вы_ же написали несколькими строками выше
AT>  alr> "2) Можно считать, что клиентов с "правильным" Accept-Charset практически
AT>  alr> нет"
AT> Это я описал "распространенную точку зрения". Т.е. соображения, которыми можно 
AT> руководствоваться при настройке. Станислав, например, с этим не согласен :)
Его право. Но мы-то согласны с этим тезисом? :) Так откуда?

AT>  alr> от индекса. А иногда - проводит. Понять до конца его логику я так и не
AT>  alr> смог :(, но вот при убирании Vary он всегда отрабатывает правильно :) Что
AT>  alr> же до Content-charset - я просто переносил свои старые патчи. Сейчас
AT>  alr> специально посмотрел по текстам msie - похоже они теперь этого не
AT> Что-то я еще меньше понимаю. У вас есть тексты MS IE ?
У меня есть бинарники и приличный опыт работ по отладке чужих программ :)
Впрочем, что бы поискать наличие заголовков достаточно фара :) оно там лежит
во вполне непакованном виде.
AT> Тогда посмотрите, что он делает получив Vary, если это можно.
Могу попробовать посмотреть в его SDK,- может там что-то есть на эту тему.
... Нету. ВО всяком случае - на виду :(

AT>  alr> 3. Предлагаемое мной "отклонение от RFC" вполне укладывается в рамки
AT>  alr>    "расширений" и не приводит к нарушению работы кэшей
AT>  alr> то мне не пришлось бы патчить и все последущие версии :)
AT> А чем вам не подходит DisableAcceptCharset для всех URL, кроме "с
AT> авто-выбором" ? Мы натурально выключаем эту вариантность и все.
Почти убедили. Вот если Вы такое повелдение включите в "рекомендованные
примеры настройки" - убедите окончательно :)


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