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

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

   Hi Alex!

Sunday, May 23, 1999, you wrote:

AT>  alr> сильных мы, действительно, _принципиально_ расходимся. Вы ставите на
AT>  alr> первое место RFC (невзирая на то, что его практически никто не
AT>  alr> поддерживает в этой части "как надо"), я - именно в силу вышеуказанной
AT>  alr> причины - "волю оператора сервера". Ну, честное слово, не стоит
AT> Да, я ставлю на первое место RFC.
AT> Дело в том, что RFC - это единственный документ, который реально связывает
AT> всю эту халабуду (серверы, прокси, клиенты) воедино. Никакого другого документа 
AT> нет (ну еще internet draft, но в этой части он полностью такой же) и 
AT> руководствоваться чем-то еще не получается. И мне совершенно не хочется, вслед 
AT> за известной фирмой, объявлять темноту новым стандартом.
Могу понять. А попасть в положение нетшкафа и начать терять рынок не
боитесь? :) Я эту "известную фирму" не люблю существенно больше Вас (поводов
хватает), однако не учитывать реалий не могу. Потому что _реальные_
пользователи это 3 категории - те самые 1251 (порядка 60%), koi8-r (порядка
20%), транслитерация (10-15%) и "все прочие". Я готов "наплевать" на
последнюю категорию но не имею права игнорировать остальные. Причём
_вынужден_ учитывать, что те ради которых нужна транслитерация, зачастую
ничего "у себя" переключить не могу, а те которые 1251 просто не умеют этого
делать.
 Что же до аргумента "стандарт велел", давайте проведём простенькую
 паралель. Стандарт на ftp-протокол говорит о том, что сервер не обязан
 поддерживать resend? Говорит. "Известная фирма" так сделала в своём
 сервере? Сделала, Какое мы имеем среднее отношения к её фтп-серверам?
 [вырезано цензуройъ ;-)

AT> При этом, моя позиция не максимально жесткая (я все-таки не ache :). Идея такая 
AT> - если сообщество требует (в данном случае, отмены Vary), то такую возможность 
AT> нужно предоставить (благо она и так есть). Но пользование этой возможностью
AT> должно быть затрудненным, чтобы нарушение RFC происходило осмысленно.
А кто против? Только надо её сделать не только затруднённой но и дефолтовой
одновременно :)

AT>  alr> буду считать что цель достигнута :).
AT> Такое поведение не будет дефолтным в силу вышенаписанного. Если такое решение
AT> будет по-умолчанию, то нужную функциональность к squid-у никто не напишет :)
Гм. Написать что ли Вам кусок к squid взамен на эту правку? :)
В то-то и дело, что если поправить squid муторно, но не сложно, и с
нетшкафом тоже самое, то с msie мы ничего сделать не можем. Вообще. И если они
сделают завтра "полностью свой" протокол, то и apache и Вы _вынуждены_
будете его поддержать. Иначе рынок существенно сузится. Я _категорически_ не
одобряю такого их поведения (и с IBM 20лет назад в аналогичной ситуации
пытался бороться :), но (увы!) не учитывать это просто не могу.

AT>  alr> начнут соблюдать RFC в такой интерпретации. А работают сервера на русском
AT>  alr> апаче сегодня, а не в том "светлом будущем", когда это произойдёт.
AT> Угу. А если не будет проблемы Vary и все будет кое-как работать "само" (с 
AT> залипанием в кэшах и так далее), то броузеры и кэши никогда не будут соблюдать 
AT> RFC. Раз нет проблемы, то никто и не будет ее решать.
Что-нибудь одно из двух. Либо "не будет проблемы", либо "не будут решать".
А проблему которая никому не мешает и решать не зачем - что мы "борцы за
чистоту стандартов", что ли? ;-)



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