On Feb 28, 2007, at 5:37 PM, Paul Winkler wrote:
On Wed, Feb 28, 2007 at 02:06:39PM -0700, Jeff Shell wrote:
On 2/28/07, Philipp von Weitershausen <[EMAIL PROTECTED]>
That's sorta what zope.publisher does. Actually, it figures that
browser sends an Accept-Charset header, the stuff that its
sending to us
would be encoded in one of those encodings, so it tries the ones in
Accept-Charset until it's lucky. It falls back to UTF-8.
This seems to work. But yeah, it's relying on implementation
the browser and it's weird.
Ugh. I don't know how I missed that header. I was always looking
content-type on the post, hoping that it had the information.
I'm rather late to this particular party, and I'm far from an expert
on either unicode or HTTP, but I have to ask: Is it just me, or is
HTTP's support for specifying encodings completely inadequate?
As far as I can tell, there are only two relevant headers. The
request may specify Accept-Charset, whose meaning is given as "what
character sets are acceptable for the *response*" (emphasis mine).
The response may specify Content-Type, which again is irrelevant to
the request. If there's anything that allows the client to specify
the encoding in use *for the request data*, I don't see it.
That seems like quite an oversight to make as late as HTTP 1.1 (1999).
What am I missing?
It's been years since I dug into this, but I'm better than 90% sure
that the browser is expected to make its requests in the encoding of
the response (i.e., the one set by Content-Type). It's been too long
for me to tell you if that's in a spec or if it is simply the de
facto rule, though I suspect the former.
Zope3-users mailing list