Closed Bug 608076 Opened 14 years ago Closed 13 years ago

HTTP Accept-Charset request header is not sent until a non-default charset is selected

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
SeaMonkey 2.0 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: jdMorgan56, Unassigned)

Details

(Whiteboard: [SmBugEvent]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.15) Gecko/20101027 SeaMonkey/2.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.15) Gecko/20101027 SeaMonkey/2.0.10

It appears that the HTTP request header "Accept-Charset" is not sent to servers until a non-default character-set is selected using the browser preferences GUI. This can cause problems on Web sites which use this header to select an appropriate character-set -- particularly international sites.
I do not know if this is locale-specific. That is, I'm in the U.S. and I am seeing this problem with what I presume is my default character-set of ISO-8859-1. The problem may only occur in this case.

Reproducible: Sometimes

Steps to Reproduce:
1. Perform a clean install.
2. Send an HTTP request while using a 'headers checker' such as the 'Live HTTP Headers' add-on. Alternatively, visit a Web page which generates a dump of all HTTP request headers to the screen.
3. Observe that the Accept-Charset request header is not sent (or is blank?)
4. In Edit->Preferences->Languages dialog, select "Western (ISO-8859-1)"
5. Repeat the HTTP-request test.
6. Observe that the Accept-Charset request header is still not sent (or is blank?)
7. In Edit->Preferences->Languages dialog, select "Western (Windows-1252)"
8. Click "Apply".
9. In Edit->Preferences->Languages dialog, select "Western (ISO-8859-1)"
10. Click "Apply".
11. Repeat the HTTP-request test.
12. Observe that the Accept-Charset header is now sent, with a value of "ISO-8859-1,utf-8;q=0.7,*;q=0.7".  Once a non-default character-set has been selected once, there is no longer a problem caused by selecting any character-set, because the controlling variable has now been initialized.
Actual Results:  
See "Steps to Reproduce"

Expected Results:  
See "Steps to Reproduce"

My selections of hardware platform, OS, and Mozilla build may be irrelevant, but accurately reflect my (single) test case.  The problem may be new to 1.9.1.15 or pre-existing, and the platform/OS scope of this problem is likely to be wider.

I believe that the variable that controls the HTTP Accept-Charset header should be initialized upon installation based on locale or if that is not possible, then it should at least be set to some default value.

Thanks!
I marked this report as "reproducible sometimes" because I believe this only occurs after a clean install.
Temporarily moving to Core:HTTP Networking to see if the people there have any insights into this.
Component: General → Networking: HTTP
Product: SeaMonkey → Core
QA Contact: general → networking.http
Version: unspecified → 1.9.1 Branch
We always send a Accept-Charset header, last I checked.

What's the value of "intl.charset.default" in your profile?
@Boris,

The config setting displayed by about:config is:

intl.charset.default  default  string  ISO-8859-1

Also, in case it may help:
intl.accept_charsets  default  string  iso-8859-1,*,utf-8
intl.charset.detector default  string  (blank, no setting present)
> intl.charset.default  default  string  ISO-8859-1

Then it should work....  Certainly does for me here (on trunk, but the relevant code looks the same on trunk and on 1.9.1).  And code inspection suggests it should work...
Just to make sure... does this happen in safe mode too?  (I assume it does.)
Just to be clear, the intl.charset.default value I posted above is the *current* value, after having changed the settings as described in steps 4 through 12 of my initial problem report above.  After I changed those settings, the browser started sending the Accept-Charset header as expected.  Therefore, I suspect it is a "intl.charset.default-not-initialized" and/or "no-default-intl.charset.default-fallback-value" -type problem.

This will likely only cause trouble with Web sites that sniff the Accept-Charset header in order to deliver multi-language/character-set content.

I don't know if the problem would occur in safe mode, as I've never had to use safe mode -- I run fairly light on add-ons and appearance-related fluff, and I do clean installs occasionally just to avoid "cumulative" problems -- and especially at major-version upgrades.

The problem should be reproducible by doing a clean install on any Win 7 system unless there is some obscure dependency.  But I'm at my limit of "educated guessing" here as "just a user."
Oh.  What was the initial value for you, if I might ask?  Note that we do set a default value, by the way....
I just tried a brand-new install of Firefox 3.6 on Windows 7, and can't reproduce this bug.
I don't think we have this on Firefox 3.5, but on 3.6, you could go to about:support and dump that for us.

Also, it's worth noting that a clean install doesn't clean your profile per se, you'd need to back that up and prune it independently. http://support.mozilla.com/en-US/kb/Backing%20up%20your%20information has docs on how to do that.
@Boris: I don't know what the initial value was.

@Axel: If your comment "dump that for us" was addressed to me, what do you need me to dump?

Please note that this bug report is specifically about SeaMonkey/2.0.10, and may or may not apply to Firefox/3.6.12

It appears that the about:support function is not available in SeaMonkey/2.0.10

I have worked with hardware and software design for 35 years, and have used the Netscape browser since it was the only one generally available (pre-MSIE), but I have only general knowledge to apply here since I don't know anything about the Netscape/Mozilla-Suite/SeaMonkey/Phoenix-Firebird-Firefox code.  All I can say with any certainty is what I posted initially: After a clean SeaMonkey install, I had to 'tickle' the language preferences twice before my browser would send an Accept-Language HTTP request header. I was having problems on a Web site that looks at this header, and found the problem by using one of those online "show me my HTTP request" pages.

Perhaps doing a totally-clean install after removing all profile-related files and directories might show this problem, but that is not what I did; I just used the Windows Add/Remove Programs GUI to run the SeaMonkey uninstaller (which as far as I know, *does not* offer any option to remove old profile settings like the Firefox uninstaller does), and then did a clean install of SeaMonkey/2.0.10

Hopefully, I didn't mess up by posting a possible SeaMonkey-only bug to BugZilla - I figured that the HTTP protocol-related stuff would be common to all Mozilla projects...
> @Boris: I don't know what the initial value was.

OK.  Can you try creating a new profile and seeing whether that shows the problem?  If it does, what's the pref value there?

The relevant code is identical in Firefox 3.6 and Seamonkey 2.0, as far as I can tell, for what it's worth....
Creating a new profile does not show the problem.  The intl.charset.default preference is created with a value of "ISO-8859-1", and the Accept-Charset header is sent with all HTTP requests as expected.

So, it still looks like a fresh installation-related issue.
OK, so we're talking fresh installation of Seamonkey 2.0 on a system that already has a profile from what other Seamonkey version?
I used Windows "Add/remove programs" to uninstall SeaMonkey/2.0.9 (or possibly 2.0.8), and then installed 2.0.10
And 2.0.8 or 9 wasn't showing the Accept-Charset problem?
No, not to my knowledge. As stated above, sometimes I do a clean install, and sometimes not; The only time I consistently choose to do a clean install is on major version upgrades -- Mozilla Suite to SeaMonkey 1.0, SeaMonkey 1.x to 2.x, etc. All I can say is that I have never encountered this problem before.

I believe that the most productive approach to take with the little information that I can provide would be to look at the code that sends the Accept-Charset header, and trace back to see under what conditions the header will not be sent at all. There may be an obvious dependency on the value in intl.charset.default which suppresses the sending of that header if that value is blank or in some way invalid -- at least that would be the correct-per-the-HTTP-spec and robust way to code it.
> and trace back to see under what conditions the header will not be sent at all.

Only if the result of getting "intl.charset.default" is the empty string.  This can happen if it's explicitly set to blank as a user pref or if it's set to something other than the correct localization file as a default pref.

If you didn't set it yourself, then sounds like the default pref value was wrong, which would be a Seamonkey issue, not a Core one.
Component: Networking: HTTP → General
Product: Core → SeaMonkey
QA Contact: networking.http → general
Version: 1.9.1 Branch → SeaMonkey 2.0 Branch
I took no action to "explicitly set it to blank or something other than the correct localization file," so your conclusion is likely correct.  Do I need to do something to pass this report to the SeaMonkey project team?
> Do I need to
> do something to pass this report to the SeaMonkey project team?
Nope Boris has already moved this bug back to SeaMonkey.

cc Neil and KaiRo since this might either be a pref or a L10n question
SeaMonkey has UI for this preference; in the Languages pane, it's the "Default Character Encoding" menulist. But it shouldn't be possible to clear it.
@neil,

Right, but please read the initial problem report above. The controlling variable *was* apparently cleared (i.e. not initialized) when doing a clean install. I had to change the preference *twice* using the UI to get the browser to send the HTTP Accept-Language header.
(In reply to comment #22)
> I had to change the preference *twice* using the UI to get the browser
> to send the HTTP Accept-Language header.
So you're saying that before you changed the preference, it was displaying Western (ISO-8859-1)? As far as I can tell the UI would be blank if your preference was invalid or unrecognised, so I'm even more confused as to how that could happen than I was before.

As a side note, neither uninstalling and reinstalling, nor upgrading using the built-in updater (which is recommended because the download is smaller) modifies any of the settings in your profile.
Actually, I'm not sure what language preference was showing in the UI -- I really came at this from a different angle: I found that the Accept-Language request header was missing and only then decided to use the UI to see if I could change anything.

Only after changing the UI setting the *second* time did I succeed in getting the browser to send the Accept-Language header. I believe that there is a clue there in that "second time" qualification.

I don't believe that I deleted my profile before doing this install, but it is possible. For this reason, if the original procedure does not show any sign of this problem, then perhaps a completely-clean install on a system with no pre-existing SeaMonkey prefs might be more productive.

In the interest of trying to help pin down this problem, I'm trying to be forthright about what I did and didn't do and what I'm sure of and what I'm guessing at here.  I don't know the SeaMonkey/Mozilla code, but I do know how tough it is to debug a large 'system' like this. So yes, my problem report and test procedure are incomplete, but like most users, I jumped into 'solving my problem' instead of trying to debug the possible code problem...

I wouldn't have bothered to report this, except for the fact that "I've been a fan" ever since the early Netscape days -- I've used versions of this suite since the very beginning.
jdMorgan56@yahoo.com, just to be clear, no one is accusing you of anything here.  We really appreciate the bug report; we're just trying to reconstruct as much of what the state used to be as we can from the info we have at this point.
Yes, but this appears to be a fairly obscure bug, and I know that the fact that I focused on "getting my own browser instance working" instead of diagnosing the underlying problem more thoroughly is highly frustrating to the team -- I've been in your shoes many, many times... :)

Thanks,
Jim
(In reply to comment #24)
> Only after changing the UI setting the *second* time did I succeed in getting
> the browser to send the Accept-Language header. I believe that there is a clue
> there in that "second time" qualification.
Sorry, but that just leaves me even more confused than ever.
OK. I'm going to close this bug for the time being. If you encounter this with SeaMonkey 2.1 due out later this month, please re-open.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [SmBugEvent]
You need to log in before you can comment on or make changes to this bug.