catap's blog ~ записки ёmacs'ера

Сегодня благодаря рассылке nginx-ru я внимательно прочитал rfc 2616.

Как оказалось, можно. Вот пара цитат, чтобы не забыть почему:

   OCTET          = <any 8-bit sequence of data>
   CHAR           = <any US-ASCII character (octets 0 — 127)>
   CTL            = <any US-ASCII control character
                    (octets 0 — 31) and DEL (127)>
   CR             = <US-ASCII CR, carriage return (13)>
   LF             = <US-ASCII LF, linefeed (10)>
   SP             = <US-ASCII SP, space (32)>
   HT             = <US-ASCII HT, horizontal-tab (9)>

   CRLF           = CR LF

   LWS            = [CRLF] 1*( SP | HT )

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

Максим Дунин подбросил ссылку:

 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битные символы вообще. Т.е. формально их можно использовать, но для клиентов — это будет делать, наверное, только самоубийца.