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

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

   Hi Khimenko!

Monday, May 24, 1999, you wrote:

IK>> сильных мы, действительно, _принципиально_ расходимся. Вы ставите на первое
IK>> место RFC (невзирая на то, что его практически никто не поддерживает в этой
IK>> части "как надо"), я - именно в силу вышеуказанной причины - "волю оператора
IK>> сервера". Ну, честное слово, не стоит аппелировать к чему-то вида "согласно
IK>> инструкции ВЦСПС от ...1929г" :)

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

AT>>>  alr> директориии и т.д,) выбрана кодировка.
AT>>> Чистая правда. Потому как Accept-Charset считается самым сильным и
AT>>> при его наличии будет учитываться только он.
IK>> А при его _отсутствии_? В том-то и состоит проблема (сколько Вы от неё
IK>> не отмахивайтесь), что минимум 80% запросов приходят _без_ него. И
IK>> _принудительно_ ставить его на первое место есть абсолютно _законно_, но
IK>> крайне _неразумно_.
KV> Вопрос в другом: его нельзя ставить после слабых признаков (User-Agent и т.п.)
Почему? Нет, я готов признать Вашу аргументацию в части "поведения по
умолчанию", но сейчас-то речь не о том. Кроме того никто и никогда не
предлагал его ставить после User-Agent. _Вся_ дискуссия идёт только вокруг
обсуждения "после порта" или "после префикса", сиречь после _url'a_. А это
ни в коей мере не противоречит RFC. Ну, давайте Вы попробуете посмотреть на
проблему вот под каким углом зрения. Значит берём обычный апач (не russian
apache). Делаем несколько виртуальных серверов (допустим на разных портах).
Каждому серверу делаем свой DocumentRoot. Дальше ставим робота который все
документы из одного D_R перекладывает в соседние попутно перекодируя их из
koi8-r в 1251 и т.п. Чем бы поведение каждого из таких серверов нарушало
RFC? А всех вместе? Речь же и идёт именно о том, что ByPort (/ByPrefix) надо
рассматривать как "конгломерат" _обычных_ серверов (без всякой перекодировки).
(Hint: "надо" не в смысле "положено", а в смысле "удобнее/естественнее").

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

IK>> том, что _большинство_ пользователей русского апача оставляют конфигурацию в
IK>> состоянии близком к conf.default. И основной смысл моих попыток, как-то
IK>> защитить свою позицию перед Вами восе не в том, что бы не ставить патч на
IK>> следущие версии апача (всё одно прийдётся из-за security :), а в том, что бы
IK>> изменилось поведение их серверов.

KV> Интересно -- какие такие дыры с security apache'а имеются, что нужно обязательно
KV> свой patch ставить ?
Отсуствие контроля путей. И все их попытки защитить это через проверки
линков и иже с ними выглядят достаточно смешно. Особенно учитывая, что
сделать можно много проще.
KV> И почему еще через эти дыры половину всех site'ов не
KV> заломали ? Хотя к Russian Apache это отношения не имеет...
А кому они нужны? :) Если же серъёзно - проблемы начинаются не когда у Вас
нормальные сайты с нормальным администрированием, а когда Вы вынуждены
разрешать пользователям работу с собственными скриптами и т.п. "глупости".
Никогда не задумывались почему у большинства провайдеров на машинах апач
идёт либо под chroot'ом, либо на совсем отдельных машинах?

IK>> в том "светлом будущем", когда это произойдёт. Потому-то я и пытаюсь сдвинуть
IK>> Вас с позиции "строгого соблюдения буквы закона".
KV> Не удастся. Дело просто в том, что СУЩЕСТВУЮЩИЕ Apache будут стоять в том самом
KV> светлом будущем (я буду удивлен, если через 10 лет уже не будет site'ов с
KV> Apache 1.2.x rus/PLxx.yy :-) и тогда проблемой станет то, что они не выдают
KV> Vary :-))
Думаю, зря "будете удивлены". Если в ближайший год не будет достигнут
консенсус между ms и netscape (а шансы на это почти нулевые), то "развал"
html'я зайдёт настолько далеко, что это _прийдётся_ поддерживать на уровне
сервера. Как следствие уход c apache 1.2 (ну, хотя бы на 1.5 :).

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

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


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