Closed
Bug 145413
Opened 23 years ago
Closed 22 years ago
charset is not correct if using gzip encoding
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: c_hin_wing, Assigned: tetsuroy)
References
Details
(Keywords: intl)
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020510 BuildID: Build ID : 2002051006 when I am browsing some web page that encoded by gzip the charset is not changed to correct charset in the web page requested but when I clear the setting of Accept-Encoding in preferences, the charset is correct Reproducible: Always Steps to Reproduce: 1. Confirm Accept-Encoding in preferences is accept gzip 2. browse a web site use other charset e.g. http://www.linuxfab.cx/index.php it is using Big-5 charset 3. check view->Character Coding is change to Big-5
Comment 1•23 years ago
|
||
->il8n
Assignee: attinasi → yokoyama
Component: Layout → Internationalization
QA Contact: petersen → ruixu
Comment 2•23 years ago
|
||
Reporter: Sorry, I'm not clear with the "Accept-Encoding in preferences is accept gzip"? Is this in Netscape/Moizlla? how do you set this?
Dear Yuying Long, I am sorry for my bad english. I am using Mozilla under windows 98SE. The bug I found is in version 1.0rc2. For "Accept-Encoding in preferences is accept gzip". I want to say using Menu's Edit -> Preferences ... -> Advanced -> HTTP Networking -> EditBox Accept-Encoding At default setting, I can see the gzip in the EditBox. When the gzip is set, the web server will send the content with gzip encoded. I can see the page source is change the charset to big5. But the browser will not do that. When I clear the EditBox, the charset is changed success. Now I use version 1.0. I am not sure the problem is exist or not. It is because some time the charset is correct, and sometime is not correct.
Assignee | ||
Comment 4•23 years ago
|
||
>Menu's Edit -> Preferences ... -> Advanced -> HTTP
>Networking -> EditBox Accept-Encoding
darin: I checked 2002-07-01 branch build and the Accept-Encoding is removed
from the Pref. Did we remove it completely or move to other place?
Can you also expound how 'gzip' is used?
Comment 5•23 years ago
|
||
we removed the preference from the UI since it is a very advanced preference that users should not have to alter. suppose a server sends a response like this: HTTP/1.1 200 OK Content-Type: text/html; charset=FOO Content-Encoding: gzip this tells mozilla that the content of the message is gzip encoded and that we must unzip it in order to reveal data that is text/html with a charset of FOO. however, servers will only send "Content-Encoding: gzip" if the client specifies a request header of "Accept-Encoding: gzip" i strongly suspect that the server is failing to send the charset attribute (which is optional) when sending the content gzip encoded. we'll need to see a packet trace of the headers to figure out which is the case. set these env vars to get a packet trace: set NSPR_LOG_MODULES=nsHttp:2 set NSPR_LOG_FILE=c:\headers.log this may just be an evangelism bug.
Comment 6•22 years ago
|
||
When I go to http://www.linuxfab.cx/index.php, I see it in Big5... is there a page that demonstrates this bug?
Comment 7•22 years ago
|
||
There are something not clear to me. The page was encoded in big5 and it was displayed in big5. What's your expectation? Are you expecting to see gb2312?
Comment 8•22 years ago
|
||
no response from reporter. marking WORKSFORME wing: if you're still seeing this problem, please respond to comments 7 and 8
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•