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

[Maxim Dounin]

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.

> > В 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 уже нельзя.

Maxim Dounin