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

["Khimenko Victor" <khim@sch57.msk.ru>]

In <2828.990523@styx.cabel.net> Iouri Kharon (bc-info@styx.cabel.net) wrote:
IK>    Hi Alex!

IK> Sunday, May 23, 1999, you wrote:

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

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

Сама эта дискуссия возможна ТОЛЬКО потому, что кто-то когда-то не отказался
от "соблюдения инструкций ВЦСПС от ...197xг". Ибо если бы с самого начала
не были приложены титанические усилия по приведению реализаций TCP/IP в
соответствие с "инструкциями ВЦСПС", то сейчас не было бы Internet'а (в его
сегодняшнем виде уж точно, а возможно и вообще бы не было) -- была бы масса
не связанных друг с другом сетей и общение между абонентами разных сетей
было бы весьма проблематично...

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

Вопрос в другом: его нельзя ставить после слабых признаков (User-Agent и т.п.)
Можно, конечно, просто отвергать конфигцрацию, в которой он стоит после
_слабых_ признаков, но IMNSHO здесь путаницы будет уж точно больше, чем
выигрыш от исчезновения несколько virtualhost'ов...

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

Нет. Оно не укладывается в RFC. Правда в другом месте:
-- cut --
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URL used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
-- cut --
Создайте у себя на site документ, скажем, README.DOC, назначьте ему тип
text/plain и вы увидите, как этот $#%&* соблюдает RFC 2068...

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

Интересно -- какие такие дыры с security apache'а имеются, что нужно обязательно
свой patch ставить ? И почему еще через эти дыры половину всех site'ов не
заломали ? Хотя к Russian Apache это отношения не имеет...

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

Не удастся. Дело просто в том, что СУЩЕСТВУЮЩИЕ Apache будут стоять в том самом
светлом будущем (я буду удивлен, если через 10 лет уже не будет site'ов с
Apache 1.2.x rus/PLxx.yy :-) и тогда проблемой станет то, что они не выдают
Vary :-))

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>> руководствоваться при настройке. Станислав, например, с этим не согласен :)
IK> Его право. Но мы-то согласны с этим тезисом? :) Так откуда?

Еще раз: с тем же успехом можно считать, что пользователей, не понимающих
windows-1251 не бывает (Lynx 2.7.x и 2.8.x под *nix его понимают, Netscape 4.5+
тоже) и выкинуть все эти перекодировки... Или что пользователей, не понимающих
koi8-r не бывает (MS IE 3+ и Netscape 4+ for Windows koi8-r понимают)
Что будет значительно проще и у меня не будет возникать на экране китайские
иероглифы, когда я получу по почте URL с :8103 ...