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

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

   Hi Alex!

Saturday, May 22, 1999, you wrote:

AT>  AT>> Ничего не понял :). Директива никуда не выдается, r->pool у нас вроде
AT>  AT>> общий на всех. Поясните простыми словами.
AT>  alr> Выдаётся поле Vary. Если его кто-не не сформировал раньше.
AT> У кого-то из нас проблемы с русским языком. То-ли я переутомился на ниве 
AT> перестановки мебели в квартире, то-ли Вы как-то не так пишете.
AT> Вашу фразу я (буквально) понял так: "Поле Vary:
AT> /,если его кто-то не сформировал раньше,/ выдается Russian Apache даже при 
AT> CharsetDisableAcceptCharset On"  А если его кто-то сформировал, то не
AT> выдается ?
Код там (в http_protocol) выглядит следующим образом:

  if(ra_flag(r, RA_VARY_ACCEPT_CHARSET) {
    if(!(vary=ap_table_get(r->headers_out, "Vary"))
       || !strstr(vary, "accept-charset")))
      ap_table_merge(r->headers_out, "Vary", "accept-charset");
  }

 не знаю как насчёт русского :), а на С это значит именно то что я писал - поле
 Vary формируется (при наличии RA_VARY_ACCEPT_CHARSET) если оно
 не было кем-то сформировано раньше.

AT> Я только-что потренировался на apache.lexa.ru:8100.
AT> Если включить CharsetDisableAcceptCharset, то Vary: accept-charset
AT> НЕ ВЫДАЕТСЯ модулем mod_charset (я это уже выключил обратно и Vary опять есть).
Естественно. Но так делать не стоит - далеко не всегда можно обработать по
"сильным признакам" и именно поэтому нужно (когда нет/не срабатывают сильные)
проверять и слабые признаки. В том числе и accept-charset. А предложенный
метод отключает его "насовсем".

AT> Что я собственно и пытался сказать.
С этим я и не спорил. Я же говорил о том, что Vary в выдаче русского пачаа
формируется _независимо_ от наличия accept-charset в запросе браузер и
_независимо_ от того, по какому признаку (например порту, директориии и
т.д,) выбрана кодировка. А (повторюсь) - согласно моей "интерпретации стандарта"
выдавть Vary нужно только в том случае когда accept-charset был в запросе и/или
когда определение кодировки прошло по слабым признакам.

AT> Естественно, если какой-то модуль счел нужным его поставить, то Vary выдаваться 
AT> будет. Под рукой нет исходников, но скорее всего этот модуль называется 
AT> mod_negotiation с Options MultiViews :)
А как же. Только вот апач у меня собран с disable-module=negotiation.

AT>  AT>> А свою мысль повторю. Сервер не выдает заголовок Vary: если в данном
AT>  AT>> "измерении" нет variations. Т.е. чтобы избавиться от Vary: нужно
AT>  AT>> выключить для данного URL все  не-URL-encoded методы распознавания
AT>  AT>> клиентского charset.
AT>  alr> В том-то и дело, что это _не_ так. А я изначально и просил именно такого
AT>  alr> поведения. (см. ниже)
AT> Какая у вас версия Russian Apache ? В моей (1.3.6 pl28.15) все именно так как я 
AT> пишу. И неудивительно - я сам этот код и написал.
Версия та же. И я _не_ отрицаю того что поведение соотвествует описанному
Вами. Я отрицаю правильность такого поведения. И (тоже повторюсь) не из
каких-то "высокотеоретических соображений", а просто потому, что без
обсуждаемой правки (в том или ином виде) работать с документами с фрэймами и
использованием старшие msie просто невозможно.

AT>  alr> порту. Можно было бы ещё обсуждать "возможную вариантность" если клиент
AT>  alr> выдал Accept-charset, но при его отсутствии уж точно нету.
AT> Давайте рассмотрим сначала пример с Accept-Language и включенным MultiViews.
Не совсем адекватная ситуация. Для получения адекватной надо допустить что у
нас есть "разделение по портам" или директориям на Language.

AT> Пусть все ходят через прокси-кэш по протоколу HTTP/1.1, а сервер знает все
AT> языки.
AT> Если не выдавать Vary, то первый клиент (скажем, с Accept-Language: zh)
AT> вытянет через прокси какой-то документ (в китайском варианте), который залипнет 
AT> в кэше. После чего второй клиент (Accept-Language: cz) сможет получить чешский 
AT> вариант только нажав Shift-Reload в своем броузере (если он это умеет делать, 
AT> обычные пользователи об этой фиче не знают). Без этого он будет получать
AT> (из кэша) китайский вариант.
Это почему же? Я же подчёркивал при выборе по _сильным_ признакам. По моему
скромному мнению кэш, который считает "совпадающими" документы полученные с
разных урлов (а номер порта и/или имя директории таки делают урл уникальным)
можно смело выкидывать на помойку.:) Да и неизвестно мне таких.


AT> Теперь вернемся к ситуации с Accept-Charset. Она ничем не отличается от 
[skip]
AT> Возможные варианты поведения сервера:
AT> 1) признать, что если приходит разумный Accept-Charset (т.е. запрос кодировки,
AT> известной серверу), то ТАКОЕ пожелание имеет НАИВЫСШИЙ приоритет. Как оно и 
AT> должно быть по стандарту HTTP. В этом случае мы ОБЯЗАНЫ выдавать Vary:
Согласен со второй частью но КАТЕГОРИЧЕСКИ не согласен с первой. Наивысший
приоритет задаётся "оператором" сервера. И если задан (например) порт, то мы
не имеем никакого права считать чтобы то ни было более высоким. Такой подход
позволяет оператору настроить сервер так как он считает нужным - сиречь и
способом который Вы полагаете оптимальным и способом о котором говорю я.

AT>   как по стандарту, так и по самой сути вещей (см выше примеры) даже если
AT> этого заголовка нет в текущем запросе. Дело в том, что если в следующем запросе 
AT> через тот же кэш такой заголовок таки появится, то кэш уже должен знать, что 
AT> нужно обрабатывать варианты. Если Vary не будет в первом же ответе, то 
AT> Accept-Charset во втором запросе будет проигнорирован кэшом и
AT>   ответ (неправильный!) будет отдан из кэша.
Ещё раз - это произойдёт _только_ если урл документа тот же. В случае же
когда разделение charset идёт по портам такого произойти просто не может.

AT>   Поведение Russian Apache с настройками по-умолчанию соответствует стандарту,
AT>   цитату мы тут уже мусолили.
А консенсуса так и не достигли :). Впрочем сейчас-то речь несколько не о
том. Пусть даже я приму Ваше толкование стандарта. Факты от этого не
изменятся. Предлагаемый мной метод удовлетворяет и Вашим соображениям о
кэшах и всем трём наиболее применяемым браузерам. Реализованный Вами
усложняет работу самого распространённого. И пусть авторы msie 33 раза
не правы - Вы (как авторы) _обязаны_ учитывать его кривизну (если считать
что она есть) учитывая ширину его применения. Не согласны?

AT>  2) Можно считать, что клиентов с "правильным" Accept-Charset практически нет,
AT>   а которые есть - сумеют выбрать нужную кодировку из менюшки "ваша кодировка".
AT>   В этом случае мы выключаем обработку этого заголовка вышеописанной
AT> директивой CharsetDisableAcceptCharset On и живем как люди - вариантность по 
AT> этому параметру исчезает и мы честно не сообщаем о ней остальному миру
AT>   (ее нет) - в ответах нету Vary: accept-charset.
Так. Что-то я перестал понимать. Положим мы проставили в настройках
CharsetByPort windows-1251 8080
и
CharsetSelectionOrder Portnumber...

Не поделитесь - откуда возьмётся "вариантность" при запросе url:8080?
Только не забудьте то что _Вы_ же написали несколькими строками выше
"2) Можно считать, что клиентов с "правильным" Accept-Charset практически нет"

Ещё раз - я _не_ прошу менять поведение при запросе url. Я говорю о
ситуациях url:port и urp/prefix.


AT> В документации написано, но я на всякий случай повторю. Когда мы пишем
AT> CharsetSelectionOrder aa bb cc
AT> мы (сервер) на самом деле подразумеваем
AT> CharsetSelectionOrder AcceptCharset aa bb cc
AT> - это сделано из тех соображений, что способ описанный в стандарте - он
AT> обязателен к выполнению, а остальное - Portnumber/Useragent - от лукавого.
А вот тут я не согласен. Достаточно вспомнить что есть RFC что бы оправдать
превалирование "здравого смысла" над "буквоедством" :). _Ручная_ настройка
должна быть более приоритетной.

AT> Vary:
AT> Content-Charset:
AT> Content-Language:
AT> То MS IE 5.x такой ответ таки кэширует. Это так ?
Почти. К сожалению я не совсем точно описал тогда ситуацию - при наличии
Content-Language и нажатии Refresh msie _иногда_ не проводит перезапрос от
индекса. А иногда - проводит. Понять до конца его логику я так и не смог :(,
но вот при убирании Vary он всегда отрабатывает правильно :)
Что же до Content-charset - я просто переносил свои старые патчи. Сейчас
специально посмотрел по текстам msie - похоже они теперь этого не
обрабатывают. Во всяком случае явно проверок на такое поле в 5ке нету.
Sorry, за потраченное время.
AT> хочется. А на работу я уже 3 недели не ходил, работаю дома :)
Я туда уже больше 3 лет не хожу, так что ситуация знакомая :)

AT>  alr> Первично (несколько лет назад) из
AT>  alr> текстов поминавшейся уже альтернативной разработки.
AT> Из какой такой альтернативной разработки ? HTTP-NG ? В настоящее время есть
Нет. Я имел ввиду альтернативный проект руссификации апача. Где-то у меня их
старые урлы были - поискать?

AT> p.s. Однако длинно получилось. Давайте как-то двигаться в этом обсуждении,
AT> последние писем 10 мы говорим все об одном :)
Ага :). Давайте зафиксируем следующее:
1. Поведение предложенное и реализованное Вами точно соотвествует "букве" RFC
2. С моей точки зрения (но я её Вам не навязываю :) допустимо несколько
   отличное толкование этого места.

Это уже резко сократит последущие обсуждения :).
А если бы Вы ещё согласились с:
3. Предлагаемое мной "отклонение от RFC" вполне укладывается в рамки
   "расширений" и не приводит к нарушению работы кэшей

то мне не пришлось бы патчить и все последущие версии :)


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