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

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

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

IK> Monday, May 24, 1999, you wrote:

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

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

"Все RFC равны, но некоторые равнее других". RFC, которые ДЕЙСТВИТЕЛЬНО
важны (прошли через обсуждение и утверждение в IETF, "задевают" массу
народа и помечены как "Standards Track") редко бывают такими уж "сырыми и
неувязанными". Кроме того набор RFC -- это фундамент всей системы. Это
единственная вещь, которая превращает Internet в единое целое. И даже если
фундамент не слишком хорош и надежен это еще не повод его расшатывать, чтобы
потом удивиться "а чего это оно все рухнуло-то, а?"...

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

А это уже вопрос субъективный. Мне (как человеку, ходящему по Internet'у
с правильным Accept-Charset) этот вариант нравится меньше...

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...
IK> Да не защищаю я мс "вообще"!  И вовсе не говорю о том, что msie это
IK> "хорошо". Наоборот. Только что это меняет? Надеяться изменить их
IK> политику не стоит, не получится. Такими методами во всяком случае.

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

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

Просто потому, что если обнаружится очередной "buffer overflow", то все
проверки (и встроенные в Apache и ваши собственные :-) "пойдут побоку"...

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

Какого, я извиняюсь ? Достаточно Apache 1.1.3 и PHP 2.0 :-)) Если вы
действительно об HTML'е, а не о HTTP. BTW я АБСОЛЮТНО уверен, что в этом
случае просто появится масса серверов, которые можно будет смотреть только
в MS IE или только в Netscape и опять же перехода не произойдет. Я не говорю,
что Apache 1.2 через 10 лет будет стоять на бОльшей части web-серверов. Но то,
что он будет стоять на внушительном количестве серверов -- совершенно очевидно.
Вы переоцениваете влияние MS, Netscape и т.п. на развитие "процесса" и
недооцениваете человеческую лень :-))

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 ...
IK> Я бы согласился с Вашей цепочкой рассуждений, кабы не одно "маленькое но" - koi7.
IK> И если всё остальное можно обойти со стороны клиента, то это - нет.

За название "koi7" вообще убивать нужно: взяли название хорошей такой кодировки
и использовали его совершенно не по назначению :-(( В koi7 есть полный набор
русских букв ! Там нет символов "{" и "}", но это уже другая история...