In-Reply-To: <5371.990510@styx.cabel.net>; from Юрий Харон on Mon, May 10, 1999 at 08:55:40AM +0400
References: <5371.990510@styx.cabel.net>
Hi,
> 1. Несколько странная логика в подстановке поля Vary: accept-charset
На мой взгляд, логика совершенно нормальная - сервер честно сообщает
клиенту, что заголовок Accept-Charset влияет на содержимое, отдаваемое
клиенту. Что отвечает духу и букве соотв. RFC.
> a) Делать как сейчас просто нельзя - 5й эксплорер наличие такого Vary при
> _отсуствии_ полей Content-charset и Content-language воспринимает как
> признак некэшируемости документа _независимо_ от наличия собственно поля
> charset. Почему - вопрос к мелкомягким :), но ситуация вполне решаема и
> без них.
Т.е. если выдавать вышеупомянутые Content-* заголовки, то MS IE будет
доволен ? Не вижу препятствий
> б) Однако несколько более осмысленным представляется вариант вида:
>
> if(charset_flag(r, RA_VARY_ACCEPT_CHARSET)
> && ( !(vary=ap_table_get(r->headers_out, "Vary"))
> || !strstr(vary, "accept-charset"))) {
> if(r->ra_codep && r->ra_codep->cp_name) {
> if(!ap_table_get(r->headers_out, "Content-language"))
> ap_table_merge(r->headers_out, "Content-language", "ru");
> if(!ap_table_get(r->headers_out, "Content-charset"))
> ap_table_merge(r->headers_out, "Content-charset",
> r->ra_codep->cp_name);
> } else
> ap_table_merge(r->headers_out, "Vary", "accept-charset");
>
> Сиречь - если charset уже определился (неважно по каким признакам, например
> по порту обращения или UserAgent), то подставляются Content-language и
> Content-charset (если их не было), а вот если _не_ определился, то
> подставляется Vary. Такой вариант проверен на 2х эксплорерах 2х нетскейпах и
> одном lynx'е :). Работает.
Мне это все кажется очень странным.
1) не бывает случая, когда charset не определился бы (в крайнем случае
возьмется CharsetDefault)
2) Если в сервере не выключен режим распознавания Accept-Charset,
то не ставить Vary нельзя. Во всяком случае, если запрос был HTTP/1.1,
а это именно случай MS IE 4+
Почему бы просто не ставить Content-language/Content-Charset ? Мне это не
сложно, хотя Content-charset дублирует Content-Type.
Ну и для порядка - Content-language вовсе не всегда ru. Может быть и cz :)
>
> 2. Несколько странная ситуация возникает при использовании strip-meta-http
> 'хэндлера'. Делать-то он всё делает, но дата получившегося документа
> сбрасывается в 0. Возможно у Вас были какие-то "высшие соображения" на эту
> тему, однако мне представляется более логичным оставлять дату исходного
Странно все это читать. Этот handler ведет себя точно так же, как
default_handler. Только что попробовал, вот заголовки, мне они кажутся
вполне логичными:
Date: Mon, 10 May 1999 21:20:09 GMT
Server: Apache/1.3.6 (Unix) rus/PL28.12
Content-Length: 493
Last-Modified: Sun, 07 Jun 1998 20:37:50 GMT
ETag: "3c5c-1ed-357afa1e-koi8-r"
Connection: close
Content-Type: text/html; charset=koi8-r
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Vary: accept-charset, user-agent
<HTML> <HEAD> </HEAD>
<!-- Meta http equivalent was here -->
> Ну и, заодно :), пара мелких вопросов. Очень ли не хочется делать
> возможность сохранения в SERVER_CHARSET имени по которому пришли? Дело в
> том, что тот механизм который есть сегодня практически не позволяет
> использовать ServerAlias в виртуальных серверах при применении
> предложенного Вами механизма с index.cgi
То имя, по которому пришли, содержится в HTTP_HOST. В CHARSET_HTTP_SERVER
живет htons(r->connection->local_addr.sin_port) именно из тех соображений,
что больше этой информации в переменных нет.
> А также не поделитесь почему Вы не стали делать _подстановку_ meta-http
> (вместо вырезания)? Казалось бы если добавить к этому "автоматическиое"
Потому что для этого не всегда есть место. Попробуйте вставить windows-1251
вместо koi8-r :). А если длина файла может меняться, то невозможно
выдать Content-Length и все это автоматически перестанет кэшироваться
многими клиентами
> расширение имени файла к виду basefilename.charset.extention то снимаются все
> проблемы с кэшированием. Понятно, что всё "не так просто" :), но интересно
> почему.
Я не совсем понял идею. Что значит "атоматическое расширение имени файла" ?
Это же надо делать на клиентской стороне, а я не понимаю как это возможно
Alex
p.s. Я делаю Cc: apache-rus@lists.lexa.ru, дальнейшее обсуждение хорошо
бы вести там, чтобы могли принять участие и другие желающие. Подписаться
на эту рассылку можно у majordomo@lists.lexa.ru
"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.