HTTP headers *are* ASCII; RFC2616 defined them to be ISO-8859-1, but
HTTPbis currently takes the stance that they're ASCII, as in practice
Latin-1 isn't used and may introduce interop problems.
<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-4.2
>
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.
What does it mean to "support non-ASCII headers"? As per above, the
only sane thing to do is treat them as opaque data, because you can't
be certain of their encoding unless you have knowledge of the header.
On 21/09/2009, at 12:50 AM, Armin Ronacher wrote:
Also (something I haven't yet filed as a bug because I guess there
will
be more changes involved) the HTTP server in Python 3.1 does not
support
non-ASCII headers.
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
