Re: Does Firefox always submit with UTF-8 encoding header ?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Does Firefox always submit with UTF-8 encoding header ?

Aaron Reed
Hi Jozef,

I've debugged this a bit.  I don't know what is supposed to happen, but
this is what DOES happen on our processor :)

We take the value of the encoding attribute from the submission element
and use that to create the first processing instruction in the document
that we are submitting back.  If there is no encoding attribute, we use
UTF-8.  So for the submission that you are generating, we build:

version="1.0" encoding="UTF-8"

When we serialize the XML to a stream, we use the same logic...we grab
the @encoding value and if it doesn't have one, we use UTF-8.  So I
believe what we are passing you is encoded properly.  However, when we
build the content type, we only put in "application/xml".  So on the
servlet side, you call req.getCharacterEncoding(), it just parses the
content type looking for the charset= token and it doesn't find it, thus
the return of null.

As you noted, this is probably what is causing you problems on the
servlet side.  For example, it looks like if use getReader, it
"translates the character data according to the character encoding used
in the body" according to the J2EE v1.3 spec.  I have no idea what
default it picks if there isn't one.  I doubt that it goes into the XML
to find out :)  Looks like if you use getInputStream it'll read the body
of the request as binary, so that might not screw up the encoding that
we've already done.

So while what we are doing isn't technically wrong, I don't think (but I
could be wrong), I don't see why we can't mimic formsPlayer's behavior.
  I've opened bug: 
for this issue.

dev-tech-xforms mailing list
[hidden email]