[apache-rus] russian apache

[Alex Tutubalin <lexa@lexa.ru>]

Привет,

 AT>> 1) не бывает случая, когда charset не определился бы (в крайнем случае
 AT>> возьмется CharsetDefault)
 ycn> Я имел ввиду (хотя по тексту этого не видно) "жёсткое" определение
 ycn> (например по номеру порта)
А это не важно, accept-charset "сильнее" всех прочих методов определения 
кодировки.

 AT>> 2) Если в сервере не выключен режим распознавания Accept-Charset,
 AT>> то не ставить Vary  нельзя. Во всяком случае, если запрос был

 ycn> Насколько я понимаю не вполне. Вот текст rfc:
 ycn> An HTTP/1.1 server MUST include an appropriate Vary header field with any
 ycn> cachable response that is subject to server-driven negotiation. Doing so
Но мы то хотим добиться cacheable response, правильно ? Значит MUST.

 ycn>   Смысл предлагавшегося мной сводится к следующему:
 ycn>   а) Если документ "вариабелен" по charset (т.е. приход на 80й порт,
 ycn> и/или    без _явного_ задания языка трансляции - поле Vary ставится (в
 ycn> точном    соотвествии с rfc).  б) если чарсет задан _явно_ (например
 ycn> номером порта), т.е. сколько раз и  с какими настройками его не забирай -
 ycn> ничего не изменится, поле Vary  ставить _не_ нужно, т.к. такой документ
 ycn> можно (я бы сказал нужно :)  кэшировать.
У меня Vary ставится в точном соответствии с его смыслом - указывается 
вариабельность в том или ином измерении. Т.е.
1) ставится Vary: accept-charset если распознавание accept-charset не выключено 
2) при приходе "на 80-й порт" (а точнее, если при определении кодировки 
принимался во внимание User-Agent:) - ставится vary: user-agent

 ycn> Как Вы, несомненно, знаете существует(вал?) некий проект русификации
 ycn> апача альтернативный Вашему (Ваш - лучше :). Так вот они там именно тем и
 ycn> занимались, что сначала "прогоняли документ" просто считая новый размер,
 ycn> а уж потом выдавали его наружу.
Это можно делать только для статических документов, решение не общее.

 ycn> Кстати - а если Вы такого не делаете, то как же Вы поступаете с длиной
 ycn> при перекодировании в транслитерацию  (koi7)? Там же тоже часть символов
 ycn> заменяется на 2 символа.
Если длина документа не была подсчитана "прогонкой" (а это, кажется, уже нигде 
не делается, кроме strip-meta-http), то Content-Length не выдается.
Подсчет длины во всех случаях - это слишком большой оверхед, а на меня за 
оверхед и так ругаются владельцы загруженных серверов.

 ycn> Когда клиент просит файл mydoc.html мы ему даём автоматический редирект
 ycn> на mydoc.koi8-r.html. При этом что именно вставлять в середину
 ycn> зависит, естественно, от charset. Это очень похоже на работу по
 ycn> директориям, но позволяет использовать и другие механизмы.
Подобный механизм реализован в MultiWeb (там, правда, добавляется directory 
prefix в духе /LANG=ru/CS=koi8-r/old/url). Это требует переработки всего апача 
изнутри т.к. при использовании нереальных имен файлов слетит разнообразный 
access control, stat(file) и так далее. Это все можно, конечно, но только 
зачем?
Сейчас есть решение с автоматическим редиректом на host/port/directory, на мой 
взгляд оно решает проблему.

Сухой остаток. Нужно добавить Content-language/Content-Charset и посмотреть что 
к чему ?


С уважением,Alex Tutubalin

--- GoldED 2.42.G1114+