[apache-rus] Non member submission from....

[Alex Tutubalin <lexa@lexa.ru>]

Напоминаю, что apache-rus@ принимает письма только от подписчиков.
Ввиду живости обсуждения, это письмо я форваржу, но обычно я этого не делаю

=============================================================================
>From: "Ann Zhuravleva" <ann@piter.net>
To: "Alex Tutubalin" <apache-rus@lists.lexa.ru>
Subject: Re: [apache-rus] Vary (кажись, в самое время :)
Date: Sun, 23 May 1999 17:43:14 +0400
MIME-Version: 1.0
Content-Type: text/plain;
    charset="koi8-r"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3


-----Исходное сообщение-----
От: Alex Tutubalin <lexa@lexa.ru>
Кому: cyril@main.piter.net <cyril@main.piter.net>
Дата: 22 мая 1999 г. 18:47
Тема: [apache-rus] Vary (кажись, в самое время :)


>Привет,
>
> cpn> 1. Я не говорю, что везде Vary нужно отключать.
> cpn> Я предлагаю на 80 порту (назовем порт 80 базовым)
> cpn> принимать accept-charset и user-agent, и редиректить
> cpn> на другой порт. На 80-м убирать Vary не нужно.
> cpn> RFC не нарушается, ответ не кэшируется - все хорошо.
> cpn> По этому пункту Вы согласны?
>Ну так примерно и есть сейчас, значит согласен :)
>
> cpn> 2. Есть порты 8000, 8001, 8002 - на них происходит однозначная
> cpn> перекодировка - на 8000 кодируется только в koi8, 8001 - win1251 и
т.д.
> cpn> Эти порты назовем кодировками.
> cpn> Содержимое документа на этих портах не зависит от accept-charset
> cpn> и user-agent. Следовательно, ему Vary не требуется - согласно RFC.
> cpn> Какие возражения по этому пункту?
>Содержимое на этих портах в настоящее время зависит от Accept-Charset
всегда,
>а от User-Agent - в зависимости от настройки. А если сервер настроен так,
что
>не зависит, то и Vary не выдается.
>
> cpn> 3. *optional* - можно также разрешить редирект с кодировок
> cpn> на другие кодировки, но без Vary. Здесь абсолютно согласен,
> cpn> это нарушене имеющихся RFC и способствует залипанию страниц
> cpn> в кэшах.
>Имеется в виду - редирект без Vary ? Он все-равно не будет кэшироваться,
есть
>там Vary или нет.
>
>Я не понимаю вот чего. Текущими директивами вполне можно добиться
предлагаемого
>вами поведения, просто запретив распознавание Accept-Charset на нужных
портах.
>Да, придется каждую пару host:port явно описать, но нарушение стандартов не
>должно быть легким :). При этом сохраняется и нужное вам поведение
>(автораспознавание на port 80 и жесткое задание кодировки в URL для всех
прочих
>портов) и RFC соблюдается.
>
>Ваш патч, который мы сейчас обсуждаем :), хуже в смысле соблюдения RFC т.к.
он
>убивает Vary везде, в том числе и на 80-м порту.
>
ок. negotiated :)
будем считать, что я в силу своей кривизны про задание параметров на
host:port не заметил,
за что приношу извинения.
но, думаю, можно было бы сделать это более простым путем введя AcceptCharset
в
CharsetSelectionOrder (это уже здесь недавно предлагали). Таким образом,
поставив на
первое место параметр, который является составной частью URLа для
колдировки, а за ним
AcceptCharset, мы получаем элегантное решение.
Например, ..Order PortNumber DirPrefix AcceptCharset UserAgent, здесь,
возможно, нужно будет
подправить схему выдачи Vary таким образом, чтобы при выдаче кодировки по
PortNumber или
DirPrefix не выдавался Vary.

И рекомендовать большими красными буквами всем это использовать - и каналы
от кэширования
выигрывают, и владельцы самих сайтов.

Hint: оказывается, squid 1.2.22 Vary игнорирует. Только сейчас узнал. Squid
2.2, естественно, с
Vary не кэширует.

to frodo: и есть ли у Вас какое-нибудь предложение по поводу кэширования или
Ваши письма
относятся к _конструктивной_  критике?

=============================================================================