[apache-rus] Re: [apache-rus] Re: [apache-rus] 1.3.26pl30.14 и CharsetRecodeHeaders

[Alexander Sabourenkov <lxnt@xxxxxxxxxx>]

Привет.


> Сомнительно мне это. Ну ладно, заголовки перекодировать не будем.
> А Query-string - надо ? А URL до query-string ? А path-info ?
>
> А если их надо, то почему заголовки не надо ?

логично, см ниже.

> > 2. Флаг тоже не помешает, но должен влиять сразу на оба направления.
> >
> > что касается совместимости, то у меня большое подозрение, что апачей < .20 установлено
> > гораздо больше, чем 20-26.
>
>
> Есть подозрение, что 26-х становится все больше и больше и стремительно :)

Таки да, но люди апгрейдятся не только с 20+, что порождает мало косяков, подобных
моему лишь потому, что мало кому приходит в голову пихать кириллицу в plaintext в
cookies.

> > И, вообще говоря, должен быть флаг, отключающий вообще перекодировку headers, так как
> > согласно rfc2068 (ссылающегося в этом вопросе на rfc822) в headers не может быть
> > никаких символов, подлежащих перекодировке.
>
>
> Я не понимаю этой логики. Если там нет символов, подлежащих перекодировке,
> то перекодируй или не перекодируй - один хрен. Если там есть такие символы,
> то они могут взяться из двух мест
>  а) клиент почему-то сам решил туда их положить - тогда они будут
>    в кодировке клиента
>  б) мы сами его туда положили (Cookie). Соответственно, в этом месте
>   действительно нужно вернуть старое поведение (.20-), а если кому-то
>   нужно неперекодированное, то пусть использует base64.
>
> Что же до ссылки из rfc2616 (2068 уж давно устарело), то в смысле формата
> заголовков оно конечно ссылается на 822, но как на "generic format", 
> а дальнейшие спецификации весьма недувусмысленны:
>
> field-content  = <the OCTETs making up the field-value
>                  and consisting of either *TEXT or combinations
> 		of token, separators, and quoted-string>
>
> А OCTET специфицирован как _любая_ 8-битная последовательность.

Нда. Это я не посмотрел 2616. Увы мне.

> То-есть могут там быть символы, которые нужно перекодировать.
> Собственно, и в 822 про перекодировку ничего толком не говорится,
> а соблюдая 822 (т.е. имея только ASCII) в заголовках прекрасно
> передаются MIME-вские заголовки, которые естественно перекодируются.

Логично.

> > Так что лично меня устроил бы флаг, запрещающий перекодировку headers.
>
> CharsetDisable ?

Нет. Это отключит и перекодировку контента, которая нужна.

По 2616 мы имеем HTTP-Message

который бывает двух видов :

HTTP-message   = Request | Response

к серверу и от сервера

и разделяющийся на две части :

        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]

Копаться в разных видах message-header нам без интереса, так как они бывают совсем разные и
в общем случае не определить, какие из них "надо" перекодировать, а какие - нет.

Поэтому предлагаю сделать что-то вроде:

CharsetRecodeResponseHeaders On | Off
CharsetRecodeRequestHeaders  On | Off
CharsetRecodeResponseBody    On | Off
CharsetRecodeRequestBody     On | Off

которые все On by default, при этом апач ведет себя как pre-20.
либо CharsetRecodeResponseHeaders Off, тогда как 20-26.

При этом надо в документации прописать, что под 'headers' здесь понимается :

start-line
*(message-header CRLF)
CRLF

Такое вот предложение.

./lxnt

=============================================================================
=               Apache-Rus@xxxxxxxxxxxxx mailing list                       =
Mail "unsubscribe apache-rus" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://apache.lexa.ru/mail-archive             =