68433 - Using POST instead of GET, Mozilla doesn't apply the meta http-equiv charset

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Olivier Cahagne]

Reproducible bug.
Mozilla: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8) Gecko/20010209

Basically, Mozilla forgets to apply the charset used in <meta
http-equiv="Content-Type"... only when submitting a form with POST method; the
exact same form submitted with GET method applies the correct charset.

For example, use http://www.epita.fr:8000/~cahagn_o/mozbug/post.html
Notice it uses ISO-8859-1 and submit it, the result is a valid UTF-8 page but
the content is shown as ISO-8859-1.

Submit the same form using http://www.epita.fr:8000/~cahagn_o/mozbug/get.html
and notice it renders correctly the arabic content.

In fact, even if the form was itself UTF-8, the result of a POST method won't be
UTF-8 but something else (I guess ISO-8859-1). So I guess the initial charset is
not important, it simply doesn't apply a charset after a POST method.
Check http://www.epita.fr:8000/~cahagn_o/mozbug/arpost.html which is arabic it
self, the result of the POST is still not UTF-8 (the source says it's UTF-8 but
Mozilla doesn't render it as UTF-8).

I checked but saw no sign of such a bug so I hope it's not a dup.

If this is not a bug, can you please tell me how to to fix this, the Webmail
client I wrote won't work properly because of this on Mozilla:
http://nocc.sourceforge.net/

Comment 1

[rods (gone)]

reassigning

Comment 2

[Olivier Cahagne]

Bug is solved when sending charset inside HTTP header, see for example 
http://www.epita.fr:8000/~cahagn_o/mozbug/post2.html that uses a slighly 
different PHP script to parse the form's result.
The script sends Content-type: text/html; charset=UTF-8. The result is then 
correct.
However, I believe there's a bug with Mozilla which can't do META over HTTP 
using POST whereas it works correctly using GET. Any comment ?

Comment 3

[Keyser Sose]

Confirmed
Platform: PC
OS: Linux 2.2.17
Mozilla Build: 2001030108

Nice testcase btw. Marking NEW.

Comment 4

[Olivier Cahagne]

Can anyone reconfirm ?
I'm really surprised, I can't reproduce the bug anymore on Win2k using:
Build 20010305
Build 20010303
Build 2001030205
Build 2001030110
Build 2001022705
and even Mozilla 0.8.
Every build here shows proper arabic fonts.
I'll try this evening on Linux.

Comment 5

[Marek Z. Jeziorek]

per triage: resolving as WORKSFORME

Comment 6

[Olivier Cahagne]

I was wrong, I still have the problem on another Win2k machine and on Linux
using any build (including latest build).

Comment 7

[Olivier Cahagne]

Confirmed
Platform: PC
OS: brand new Win98SE
Mozilla Build: 20010509

I'm submitting because I thought first that the IBM BiDi checkin would change
the behaviour but META over HTTP is still somewhat buggy with the newest build.
The second method (charset within HTTP header still works however).

Comment 8

[basic]

this sounds more like a networking:http or parser bug?

Comment 9

[Eric Hedström]

confirmed, see also the WWWJDIC Japanese Dictionary at
http://www.csse.monash.edu.au/cgi-bin/cgiwrap/jwb/wwwjdic?1C

(type in a word, click Begin Search). If you turn on Auto-detect Japanese, it works.

Comment 10

[Olivier Cahagne]

Using Mozilla build 20010630 on Win2k, everything works (i.e. every URL
mentioned above).
Bug seems to be solved.
Interesting fact is, with build 20010629, the bug was still present, so it's
been solved somewhere between yesterday and today.

Comment 11

[Eric Hedström]

hey cool, 2001070108 win32 build worksforme too.

Comment 12

[Olivier Cahagne]

WFM using Mozilla 20010702 on Win2k

Comment 13

[Vladimir Ermakov]

This works for me on windows 98 2001-07-02-04 but on Linux RedHat
2001-07-02-06-trunk instead of showing arabian characters it is showing question
marks. I checked the encoding and it is set UTF-8. Is this the same bug or a
different one?

Comment 14

[Vladimir Ermakov]

verifying due to lack of responce...