Hi Khimenko!
Monday, May 24, 1999, you wrote:
IK>> неувязанный материал там проходит. Да и чего ждать от "запросов" если даже
IK>> годами обсуждаемые стандарты имеют дыры? :(
KV> "Все RFC равны, но некоторые равнее других". RFC, которые ДЕЙСТВИТЕЛЬНО
KV> важны (прошли через обсуждение и утверждение в IETF, "задевают" массу
KV> народа и помечены как "Standards Track") редко бывают такими уж "сырыми и
KV> неувязанными".
ICMP проходил и помечен? А FTP? Ну и так далее...
KV> Кроме того набор RFC -- это фундамент всей системы. Это
KV> единственная вещь, которая превращает Internet в единое целое. И даже если
KV> фундамент не слишком хорош и надежен это еще не повод его расшатывать, чтобы
KV> потом удивиться "а чего это оно все рухнуло-то, а?"...
А кто предлагает его "расшатывать"? Просто _если_ авторы стандарта (не суть
имеет ли он такой статус или фактически им является) допускают неоднозначное
прочтение, это проблемы стандарта. И не стоит после этого "вставать грудью" на
защиту какого-то конкретного прочтения по мотивам "так получается разумнее".
Всё одно кто-нибудь прочитает по другому.
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) этот вариант нравится меньше...
О! Отлично. Итак мы _договорилсиь_ до того, что это "вопрос субъективный". В
таком случае почему Ваше "субъективное восприятие" должно превалировать над
моим "субъективным восприятием"? :) Я же не говорю "выкинуть Vary насовсем и
не давать возможности его ставить". Речь шла о _умолчании_. И критерием
приводилось не то, что "мне так удобнее" - это не аргумент. А _средняя_
частота запросов. "Правильных" и "неправильных" соответственно. Вот когда
число людей подобных Вам (в части "ходящих с правильным Accept-Charset")
будет хотя бы приближаться к половине, можно будет изменить умолчание на то
что есть сейчас. Причём если аргумент "пусть правильно настроят" я принять
готов, то "пусть поменяют браузер" - нет. Я не настолько дон Кихот что бы
пытаться втеснить мс с рынка :)
IK>> Никогда не задумывались почему у большинства провайдеров на машинах апач
IK>> идёт либо под chroot'ом, либо на совсем отдельных машинах?
KV> Просто потому, что если обнаружится очередной "buffer overflow", то все
KV> проверки (и встроенные в Apache и ваши собственные :-) "пойдут побоку"...
В отличии от "разработчиков" от мс или нетшкафа, я что такое "червь Морриса"
помню ещё с первого раза - так что "не пойдут" :)
IK>> Думаю, зря "будете удивлены". Если в ближайший год не будет достигнут
IK>> консенсус между ms и netscape (а шансы на это почти нулевые), то "развал"
IK>> html'я зайдёт настолько далеко, что это _прийдётся_ поддерживать на уровне
IK>> сервера. Как следствие уход c apache 1.2 (ну, хотя бы на 1.5 :).
KV> Какого, я извиняюсь ?
Думаете будет уже 5.1? ;-)
KV> Достаточно Apache 1.1.3 и PHP 2.0 :-)) Если вы
Думаете php выживет? Я, честно говоря, сомневаюсь.
KV> действительно об HTML'е, а не о HTTP. BTW я АБСОЛЮТНО уверен, что в этом
KV> случае просто появится масса серверов, которые можно будет смотреть только
KV> в MS IE или только в Netscape и опять же перехода не произойдет. Я не говорю,
Гм. Возможный, конечно, вариант, только вот почему-то даже "самые
навороченные" сервера сегодня (я не говорю о уровне "вася пупкин лтд")
делаются так что их даже lynx'ом можно смотреть. Несколько противоречит
Вашему прогнозу, не находите? Если же Вы имели ввиду, что хозяину сервера
придётся держать у себя несколько альтернативных наборов документов, то это
и есть то, о чём я говорил "придётся поддерживать на уровне сервера".
KV> что Apache 1.2 через 10 лет будет стоять на бОльшей части web-серверов. Но то,
KV> что он будет стоять на внушительном количестве серверов -- совершенно очевидно.
KV> Вы переоцениваете влияние MS, Netscape и т.п. на развитие "процесса" и
KV> недооцениваете человеческую лень :-))
На каком проценте машин нонче стоит win...? А 10 лет назад Вы бы какую цифру
назвали? :)
IK>> Я бы согласился с Вашей цепочкой рассуждений, кабы не одно "маленькое но" - koi7.
IK>> И если всё остальное можно обойти со стороны клиента, то это - нет.
KV> За название "koi7" вообще убивать нужно: взяли название хорошей такой кодировки
KV> и использовали его совершенно не по назначению :-(( В koi7 есть полный набор
KV> русских букв ! Там нет символов "{" и "}", но это уже другая история...
Вот тут у нас полный консенсус :). Я в этом самом кои7 столько лет
проработал, что до сих пор ностальгически вспоминаю "дежице еррор"... :)
Но слово 'транслитерация' несколько дольше набивать, а про "человеческую лень"
Вы писали абсолютно справедливо :)
Best regards,
Iouri mailto:bc-info@styx.cabel.net
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/) See
Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.