X-Accel-Redirect русские имена файлов

[Kirill A. Korinskiy]

At Wed, 6 May 2009 03:42:59 +0400,
Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> Hello!
> 
> On Wed, May 06, 2009 at 02:06:19AM +0400, Kirill A. Korinskiy wrote:
> 
> > At Wed, 6 May 2009 01:17:32 +0400,
> > Maxim Dounin <mdounin at mdounin.ru> wrote:
> > > 
> > > Hello!
> > > 
> > > On Tue, May 05, 2009 at 07:54:58PM +0400, Kirill A. Korinskiy wrote:
> > > 
> > > > At Tue, 5 May 2009 18:33:13 +0400,
> > > > Igor Sysoev <is at rambler-co.ru> wrote:
> > > > 
> > > 
> > > Не совсем так.  RFC2616 в этом месте внутренне противоречив - т.к. 
> > > с одной стороны ссылается на RFC822 (который не позволяет ничего 
> > > кроме ASCII), а с другой стороны приводит грамматику,
> > > допускающую использование 8-битных символов в содержимом 
> > > заголовков (очевидно никак не определяя, куда именно следует 
> > > засунуть 8-й бит).
> > > 
> > 
> > Насколько я понял rfc2616 оставляет 8бит по грамматике для X
> > заголовков, и при этом часть заголовков отправляет в rfc822 (который,
> > кстати устарел, и надо читать его замену, похоже).
> 
> Кому именно и что оставляет RFC2616 я затрудняюсь ответить.  IMHO - 
> никому и ничего.  Использование 8-го бита одним местом запрещено, 
> другим - разрешено, и как с этим жить - непонятно.  Т.е. понятно 
> что использовать 8-битные символы вне контролируемого окружения 
> может только самоубийца.
> 
> Что до RFC822 - то устарел он ещё в 2001 году, но читать его всё 
> равно полезно (как минимум - именно он STANDARD).  В настоящий 
> момент актуален RFC5322 (на который и ссылается httpbis), но он 
> всего лишь DRAFT STANDARD.

В общем ясно что ничего не ясно и как жить тоже.

Формально upstream это способ смотреть в контролируемую сеть. В
реальности там может быть что угодно. Так что может сделать лучше
ручку для управления urldecode'ить ли ответы от upstream?

> > > В httpbis это место обросло новой грамматикой и человекочитаемым 
> > > абзацем про то что именно следует делать с 8-битными заголовками
> > > (http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-06#section-4.2):
> > > 
> > >      message-header = field-name ":" OWS [ field-value ] OWS
> > >      field-name     = token
> > >      field-value    = *( field-content / OWS )
> > >      field-content  = *( WSP / VCHAR / obs-text )
> > > 
> > >    Historically, HTTP has allowed field-content with text in the ISO-
> > >    8859-1 [ISO-8859-1] character encoding (allowing other character sets
> > >    through use of [RFC2047] encoding).  In practice, most HTTP header
> > >    field-values use only a subset of the US-ASCII charset [USASCII].
> > >    Newly defined header fields SHOULD constrain their field-values to
> > >    US-ASCII characters.  Recipients SHOULD treat other (obs-text) octets
> > >    in field-content as opaque data.
> > > 
> > 
> > ясно. Т.е. таки вводят ограничение и убирают противоречивость, я
> > правильно понял?
> 
> Я бы сказал - пытаются задокументировать проблему и не 
> рекомендовать дальнейшее использование 8-битных символов.  Совсем 
> вычистить это место в рамках HTTP/1.1 уже нельзя.

В общем ждем http/1.2 :)

-- 
wbr, Kirill