Пардон,
я одно письмо из этого thread прощелкал и увидел только сейчас.
Оно достаточно конструктивное, чтобы потрепаться еще.
alr> Естественно. Но так делать не стоит - далеко не всегда можно обработать
alr> по "сильным признакам" и именно поэтому нужно (когда нет/не
alr> срабатывают сильные) проверять и слабые признаки. В том числе и
alr> accept-charset. А предложенный метод отключает его "насовсем".
У нас разное понятие о сильных и слабых признаках :). В моем понимании,
самый сильный признак - Accept-Charset (т.к. описан в стандарте), сильные -
URL-encoded, слабый - User-Agent
alr> С этим я и не спорил. Я же говорил о том, что Vary в выдаче русского
alr> пачаа формируется _независимо_ от наличия accept-charset в запросе
alr> браузер и _независимо_ от того, по какому признаку (например порту,
alr> директориии и т.д,) выбрана кодировка.
Чистая правда. Потому как Accept-Charset считается самым сильным и
при его наличии будет учитываться только он.
alr> каких-то "высокотеоретических соображений", а просто потому, что без
alr> обсуждаемой правки (в том или ином виде) работать с документами с
alr> фрэймами и использованием старшие msie просто невозможно.
К сожалению, старшие MSIE - HTTP/1.1-агенты и обязаны соблюдать RFC.
Поэтому хотелось бы удовлетворить их не отказываясь от Vary.
На крайний случай есть решение вида
<VirtualHost www:8100>
CharsetDisableAcceptCharset On
</VirtualHost>
Да, это несколько усложняет конфигурацию, но если у вас много virtualhost,
то вы все-равно не вручную их конфигурируете, а если мало, то можно и руками.
AT>> 1) признать, что если приходит разумный Accept-Charset (т.е. запрос
AT>> кодировки, известной серверу), то ТАКОЕ пожелание имеет НАИВЫСШИЙ
AT>> приоритет. Как оно и должно быть по стандарту HTTP. В этом случае мы
AT>> ОБЯЗАНЫ выдавать Vary:
alr> Согласен со второй частью но КАТЕГОРИЧЕСКИ не согласен с первой.
alr> Наивысший приоритет задаётся "оператором" сервера.
Приоритет описан в RFC. Но у оператора таки есть возможность его поменять.
Переносить Accept-Charset в хвост списка CharsetSelectionOrder просто
неправильно.
alr> Так. Что-то я перестал понимать. Положим мы проставили в настройках
alr> CharsetByPort windows-1251 8080
alr> и
alr> CharsetSelectionOrder Portnumber...
alr> Не поделитесь - откуда возьмётся "вариантность" при запросе url:8080?
alr> Только не забудьте то что _Вы_ же написали несколькими строками выше
alr> "2) Можно считать, что клиентов с "правильным" Accept-Charset практически
alr> нет"
Это я описал "распространенную точку зрения". Т.е. соображения, которыми можно
руководствоваться при настройке. Станислав, например, с этим не согласен :)
AT>> То MS IE 5.x такой ответ таки кэширует. Это так ?
alr> Почти. К сожалению я не совсем точно описал тогда ситуацию - при наличии
alr> Content-Language и нажатии Refresh msie _иногда_ не проводит перезапрос
alr> от индекса. А иногда - проводит. Понять до конца его логику я так и не
alr> смог :(, но вот при убирании Vary он всегда отрабатывает правильно :) Что
alr> же до Content-charset - я просто переносил свои старые патчи. Сейчас
alr> специально посмотрел по текстам msie - похоже они теперь этого не
Что-то я еще меньше понимаю. У вас есть тексты MS IE ?
Тогда посмотрите, что он делает получив Vary, если это можно.
AT> alr>> текстов поминавшейся уже альтернативной разработки.
AT>> Из какой такой альтернативной разработки ? HTTP-NG ? В настоящее время
AT>> есть
alr> Нет. Я имел ввиду альтернативный проект руссификации апача. Где-то у меня
alr> их старые урлы были - поискать?
Да нет, не надо. На ранних этапах этой битвы (году в 93-95-м) наворотили
столько всего разного, что лучше не вспоминать. Мироновский NCSA, например,
анализировал поле Accept и Миронов всерьез предлагал запатчить всех клиентов
(Mosaic был в исходниках, а Мозиллы еще не было).
alr> 3. Предлагаемое мной "отклонение от RFC" вполне укладывается в рамки
alr> "расширений" и не приводит к нарушению работы кэшей
alr> то мне не пришлось бы патчить и все последущие версии :)
А чем вам не подходит DisableAcceptCharset для всех URL, кроме "с
авто-выбором" ? Мы натурально выключаем эту вариантность и все.
С уважением,Alex Tutubalin
--- GoldED 2.42.G1114+
"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.