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

["Khimenko Victor" <khim@mccme.ru>]

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

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

IK>>> неувязанный материал там проходит. Да и чего ждать от "запросов" если даже
IK>>> годами обсуждаемые стандарты имеют дыры? :(
KV>> "Все RFC равны, но некоторые равнее других". RFC, которые ДЕЙСТВИТЕЛЬНО
KV>> важны (прошли через обсуждение и утверждение в IETF, "задевают" массу
KV>> народа и помечены как "Standards Track") редко бывают такими уж "сырыми и
KV>> неувязанными".
IK> ICMP проходил и помечен? А FTP? Ну и так далее...

"Это было давно и неправда" :-)) А если серъезно, то да, конечно. Тем количеством
народа, который тогда наличествовал и был доступен для обсуждения (человек 30 в
лучшем случае :-).

KV>> Кроме того набор RFC -- это фундамент всей системы. Это
KV>> единственная вещь, которая превращает Internet в единое целое. И даже если
KV>> фундамент не слишком хорош и надежен это еще не повод его расшатывать, чтобы
KV>> потом удивиться "а чего это оно все рухнуло-то, а?"...
IK> А кто предлагает его "расшатывать"? Просто _если_ авторы стандарта (не суть
IK> имеет ли он такой статус или фактически им является) допускают неоднозначное
IK> прочтение, это проблемы стандарта. И не стоит после этого "вставать грудью" на
IK> защиту какого-то конкретного прочтения по мотивам "так получается разумнее".
IK> Всё одно кто-нибудь прочитает по другому.

Все ОЧЕНЬ просто. Те места, которые прочитываются однозначно должны
реализовываться так, как реализуются. Те, которые не прочитываются однозначно
должны реализовываться так, как автор продукта решит. В данном случае -- Alex.

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: "надо" не в смысле "положено", а в смысле "удобнее/естественнее").

KV>> А это уже вопрос субъективный. Мне (как человеку, ходящему по Internet'у
KV>> с правильным Accept-Charset) этот вариант нравится меньше...
IK> О! Отлично. Итак мы _договорилсиь_ до того, что это "вопрос субъективный". В
IK> таком случае почему Ваше "субъективное восприятие" должно превалировать над
IK> моим "субъективным восприятием"? :) Я же не говорю "выкинуть Vary насовсем и
IK> не давать возможности его ставить". Речь шла о _умолчании_. И критерием
IK> приводилось не то, что "мне так удобнее" - это не аргумент. А _средняя_
IK> частота запросов. "Правильных" и "неправильных" соответственно. Вот когда
IK> число людей подобных Вам (в части "ходящих с правильным Accept-Charset")
IK> будет хотя бы приближаться к половине, можно будет изменить умолчание на то
IK> что есть сейчас. Причём если аргумент "пусть правильно настроят" я принять
IK> готов, то "пусть поменяют браузер" - нет. Я не настолько дон Кихот что бы
IK> пытаться втеснить мс с рынка :)

Это ВАШЕ право. Можете делать что хотите. Но так как вопрос субъективен, то
ЛЮБОЕ решение, которое принял Alex обжалованию не подлежит. Хотите --
организуйте альтернативную контору и убедите всех перейти на вашу версию.

IK>>> Никогда не задумывались почему у большинства провайдеров на машинах апач
IK>>> идёт либо под chroot'ом, либо на совсем отдельных машинах?
KV>> Просто потому, что если обнаружится очередной "buffer overflow", то все
KV>> проверки (и встроенные в Apache и ваши собственные :-) "пойдут побоку"...
IK> В отличии от "разработчиков" от мс или нетшкафа, я что такое "червь Морриса"
IK> помню ещё с первого раза - так что "не пойдут" :)

Вы-то, может, и помните, а вот разработчики модулей для Apache, увы, не всегда.
В том числе и тех, что входят в комплект и используются вами (mod_cgi
какой-нибудь). Или вы пересмотрели все их исходники и убедились, что там нигде
не может возникнуть висячих указателей, переполнения буфферов и т.п. ?
Завидую -- я такой проницательностью не обладаю...

IK>>> Думаю, зря "будете удивлены". Если в ближайший год не будет достигнут
IK>>> консенсус между ms и netscape (а шансы на это почти нулевые), то "развал"
IK>>> html'я зайдёт настолько далеко, что это _прийдётся_ поддерживать на уровне
IK>>> сервера. Как следствие уход c apache 1.2 (ну, хотя бы на 1.5 :).
KV>> Какого, я извиняюсь ?
IK> Думаете будет уже 5.1? ;-)

Нет. Думаю, что масса народа так и будет жить с 1.1, 1.2 и 1.3.
Особенно те, кто купят какую-нибудь "коробку" с FreeBSD или Linux'ом и
зашитым Apache'м.

KV>> Достаточно Apache 1.1.3 и PHP 2.0 :-)) Если вы
IK> Думаете php выживет? Я, честно говоря, сомневаюсь.

А куда он денется ? Ну живет у твоего магазина (действительно магазина в
10 человек, а не сети супермаркетов :-) web-сервер, который ты когда-то купил...
И как часто ты будешь обновлять на нем ПО ? Раз в несколько лет (5-10-15) в
лучшем случае :-)) Вас же не удивляет, что сейчас еще используется
Borland C++ 3.1 (сколько ему годков-то?) и PDP-10 (а этим -- вообще лет 20 и
хотя обычно в конторах, где они используются последние 10 лет вяло обсуждается
тема "хорошо бы наконец это старье списать в утиль и поставить взамен что-нибудь
посовременнее", но воз и ныне там). Так что про то, что PHP 2.0 будет
использоваться даже и вопросов не возникает -- конечно будет :-))

KV>> действительно об HTML'е, а не о HTTP. BTW я АБСОЛЮТНО уверен, что в этом
KV>> случае просто появится масса серверов, которые можно будет смотреть только
KV>> в MS IE или только в Netscape и опять же перехода не произойдет. Я не говорю,
IK> Гм. Возможный, конечно, вариант, только вот почему-то даже "самые
IK> навороченные" сервера сегодня (я не говорю о уровне "вася пупкин лтд")
IK> делаются так что их даже lynx'ом можно смотреть. Несколько противоречит
IK> Вашему прогнозу, не находите? Если же Вы имели ввиду, что хозяину сервера
IK> придётся держать у себя несколько альтернативных наборов документов, то это
IK> и есть то, о чём я говорил "придётся поддерживать на уровне сервера".

Вы это проверяли или просто так думаете ? Как человек, ходящий по Internet'у
Lynx'ом (и который запускает Netscape только по необходимости :-) я вам
скажу -- очень многие ltd, Inc и т.п. имеют сранички, по которым Lynx'ом ходить
невозможно: заходишь на какую-нибудь www.sony.com и обнаруживаешь, что страница
содержит 20 ссылок на другие страницы и каждая называется "[IMAGE]"... А на
www.hp.com без JavaScript'а драйвера не получить :-(( А вот информационные
агенства -- те действительно про Lynx не забывают (ибо им нужно, чтобы все
это действительно можно было прочитать :-)

KV>> что Apache 1.2 через 10 лет будет стоять на бОльшей части web-серверов. Но то,
KV>> что он будет стоять на внушительном количестве серверов -- совершенно очевидно.
KV>> Вы переоцениваете влияние MS, Netscape и т.п. на развитие "процесса" и
KV>> недооцениваете человеческую лень :-))
IK> На каком проценте машин нонче стоит win...? А 10 лет назад Вы бы какую цифру
IK> назвали? :)

А меня мало интересует "проблемы мировой революции". В MCCME, скажем, в
компьютерном кабинете нет НИ ОДНОЙ машины с Windows, а всего их в заведении
штук 5-6. А машин с Linux'ом (и OpenDOS'ом) -- не один десяток...

IK>>> Я бы согласился с Вашей цепочкой рассуждений, кабы не одно "маленькое но" - koi7.
IK>>> И если всё остальное можно обойти со стороны клиента, то это - нет.
KV>> За название "koi7" вообще убивать нужно: взяли название хорошей такой кодировки
KV>> и использовали его совершенно не по назначению :-(( В koi7 есть полный набор
KV>> русских букв ! Там нет символов "{" и "}", но это уже другая история...
IK> Вот тут у нас полный консенсус :). Я в этом самом кои7 столько лет
IK> проработал, что до сих пор ностальгически вспоминаю "дежице еррор"... :)
IK> Но слово 'транслитерация' несколько дольше набивать, а про "человеческую лень"
IK> Вы писали абсолютно справедливо :)

Дык его можно сократить до t13n и дело с концом :-)

P.S. Кстати смею вас заверить -- машины с koi7 еще в ходу...