Closed Bug 98262 Opened 23 years ago Closed 23 years ago

pages show up blank - avoid sending blank Accept-Charset header

Categories

(Core :: Networking: HTTP, defect, P5)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: vladimire, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [PDT+],<html><body></body></html> bug)

Attachments

(1 file)

v1.0 patch - prevent setting blank headers
606 bytes, patch
jud
: review+
mscott
: superreview+
Details | Diff | Splinter Review 
bloomingdales.com shows up blank in build 2001-09-04-10-trunk on Windows 98.
Tested with 6.1 RTM and it works fine, so it is a recent regression.
Keywords: regression
this is the second "page does not display" bug today, reported with the same
build. (The other is bug 98238)
A linux CVS build from yesterday displays both URLs just fine.
wfm 2001090413 linux
now also reported in bug 98280
There are a couple of pages coming up blank in recent nightly builds. These URLs
are from the dupes. Problem appears on Win98 and WinME at least. I am using
2001090703.

http://www.bloomingdales.com
http://dogbert.abebooks.com/abe/TextToHtml?t=Maps+and+Prints+Corner&h=x&f=maps/main.htm
http://www.viamichelin.com/viamichelin/gbr/dyn/controller/HomePage
Component: Layout → Networking: HTTP
Summary: bloomingdales.com shows up blank → pages showing up blank
*** Bug 98370 has been marked as a duplicate of this bug. ***
*** Bug 98238 has been marked as a duplicate of this bug. ***
Bug 98280 works fine on WinME so it appears to be a Win2000 problem
Severity: normal → major
No, it is not just a Windows 2000 bug.  See my bug report on bug 98370.  I'm
still getting this at
http://dogbert.abebooks.com/abe/TextToHtml?t=Maps+and+Prints+Corner&h=x&f=maps/main.htm


on Windows ME 2001090503.  I originally reported bug 98370 for Windows 98 SE. I
also see this on 2001090508 for Mac OS9.2 [at the page I've just cited]. 
Sorry, I was being imprecise.

I meant that bug 98280 is a Win2000 problem. Therefore that bug is not a
duplicate of this one although the symptoms appear similar.
*** Bug 97629 has been marked as a duplicate of this bug. ***
Here's another URL coming up blank under 2001090703, WinME.

http://www.baggygreen.com.au
dupe of bug 98951 ?
*** Bug 98512 has been marked as a duplicate of this bug. ***
http://www.rei.com also comes up blank with 2001091405 on Mac OS X 10.0.4
petersen, can you check this out and develop a reduced test case.
Keywords: qawanted
Yes, I'm able to get a blank page with the following url: http://www.rei.com.
The page source simply shows <html><body></body></html>. I will check to see
when this problem started to happen. Tested under Mac OS X 10.0.4 with the
2001-09-12-05 build.

 
win32 build from 8/28 displays the rei.com page, bloomingdales, and the others
fine, but come up blank in the 8/29 build and every other one since then.

I am somewhat suspicious of cookies.  Turn on cookie warnings in prefs.  On the
8/28 build, I got asked to set 4-5 cookies at rei.com (I refused each one, and
did not check the "remember this" box).  The page displayed OK without cookies.
 On the 8/29 build, I was only asked once, refused the cookie, and the page came
up blank.  Maybe this is coincidence, but the same kind of thing happens on
weather.com (bug 98340) and bloomingdales.com. 
This is starting to smell like a blocker.. bug 99811 (Mac) sounds very much like
this bug.
My browser is set to accept all cookies from originating server. I still get the
blank page on both rei.com and bloomingdales.com.

I've also tried IE 5.1.1 on Mac OS X, lynx, and lynx with the user-agent string
set to mimic Mozilla. All three accessed rei.com without problems, so this is
probably a Mozilla bug rather than a browser-sniffing problem on the server end.

*** This bug has been marked as a duplicate of 99811 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reopening.
This bug is older, has more information and is on the windows platform.

Here is some info from bug 99811, courtesy of Erich Bratton:

Sites that render as blank for me:
http://slashdot.org
http://www.ibiblio.org/javafaq/
http://www.salon.com/tech/inbox/index.html
http://scripting.com/
http://bionic.manilasites.com/
http://news.cnet.com/
http://www.ebay.com/

However, a few sites always seem to render just fine:
http://www.theregister.co.uk/
http://coupons.dealnews.com/
http://www.yahoo.com/
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 99811 has been marked as a duplicate of this bug. ***
*** Bug 98340 has been marked as a duplicate of this bug. ***
*** Bug 99959 has been marked as a duplicate of this bug. ***
*** Bug 99957 has been marked as a duplicate of this bug. ***
Bug 99811 may be a different problem. rei.com and bloomingdales.com fail for me
every time, not just most of the time, as described in bug 99811. Also, I have
no trouble accessing the sites listed in bug 99811.
Setting to All/All because of dupes, setting keywords and severity to reflect 
the general visibility of this bug.
Severity: major → critical
Keywords: mozilla0.9.5, nsdogfood
OS: Windows 98 → All
Hardware: PC → All
Summary: pages showing up blank → pages show up blank
*** Bug 100081 has been marked as a duplicate of this bug. ***
Odd.  Now the page I reported as blank in  bug 98370 is displaying fine in
2001091203 Win 98SE where it wasn't on the same machine (and most of my others)
a few days ago, and I'm having no trouble with the Canada Trust page reported
above.  
This is not my expertise, but the HTTP requests and responses for
http://www.bordersstores.com/index.jsp generated by 0.9.4 and from N6.1 RTM look
different.  The response for 0.9.4 comes back with no HTML content, while the
N6.1 comes back with the proper content.  

I believe the "Accept-Charset:" header is the only difference in the request. 
The 'charset="null"' string is the difference in the response header.



===== 0.9.4 Request =====

-------- 14:14:35 (1-1) --------
GET /index.jsp HTTP/1.1
Host: www.bordersstores.com
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20010914
Netscape6/6.2
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,
image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
Accept-Language: en-us
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: 
Keep-Alive: 300
Proxy-Connection: keep-alive



===== N6.1 RTM Request =====

-------- 14:18:42 (21-1) --------
GET /index.jsp HTTP/1.1
Host: www.bordersstores.com
User-Agent: Mozilla/4.78 [en] (Win98; U)
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,
image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
Accept-Language: en-us
Accept-Encoding: gzip,deflate,compress,identity
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive


===== 0.9.4 Response =====

-------- 14:16:37 (19-2) --------
HTTP/1.1 200 OK
Server: Netscape-Enterprise/3.5.1
Date: Mon, 17 Sep 2001 20:50:31 GMT
Content-Type: text/html;charset="null"
Connection: close



===== N6.1 RTM Response =====
-------- 14:18:43 (21-2) --------
HTTP/1.1 200 OK
Server: Netscape-Enterprise/3.5.1
Date: Mon, 17 Sep 2001 20:52:37 GMT
Content-Type: text/html;charset="iso-8859-1"
Connection: close


I'm getting a blank page on bloomingdales with a 9/10, m0.9.4, Win2K debug 
build. There is no content model and hence no frame model.

Harish agreed to look at this and thinks it might be a dup of bug 99666.
Assignee: karnaze → harishd
Status: REOPENED → NEW
Note that the N6.1 RTM request that I include above is indeed a request from
N6.1 RTM, and not from N4.78 as the UA string in the request purports.  I was
testing with a modified UA string, but the results are the same regardless.
if this is only a problem with windows and mac, it could be due to the fact that
the Accept-Charset: request header is blank w/ new profiles.  see bug 97606.
I just set my default character coding to iso-8859-1, and bloomingdales.com and
rei.com both load fine now.
I just set my default character coding to iso-8859-1, and bloomingdales.com and
rei.com both load fine now.
OnDataAvailable() did not get fired!. I guess this is  a netlib problem. 

FYI: This could be a dup of bug 99666.
Assignee: harishd → neeti
QA Contact: petersen → tever
giving to gagan.
Assignee: neeti → gagan
Keywords: topembed
Whiteboard: <html><body></body></html> bug
I set my character encoding to iso-8859-1 as per previous comment from
mozilla.org@pidgin.org and https://easyweb.tdcanadatrust.com works fine again.
Gagan - This looks like a stop ship. Should it have the nsbranch+ keyword. How
close are we to a fix?
Whiteboard: <html><body></body></html> bug → PDT <html><body></body></html> bug
Gagan - Pls come to the PDT tomorrow @ noon to discuss the progress on this bug.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5
Hmmm... this must have slipped thur my queries... darin should look into this.
Assignee: gagan → darin
*** Bug 98340 has been marked as a duplicate of this bug. ***
*** Bug 100919 has been marked as a duplicate of this bug. ***
Gagan - Me thinks Darin already has another very critical bug to look at, right
now. Bug 98203. Can someone else pick this one up?
Keywords: nsbranch+
*** Bug 100954 has been marked as a duplicate of this bug. ***
losts of dupes here ... this is making me nervous.
setting a default charset in prefs seems to fix this bug each time
See bug 100134.  If these sites use WebSphere that could be the problem.
could this be a dupe of bug 97606?
not a dup as such.. But bug 97606 could be added as blocking this one. The fix
for bug 97606 is about to be checked in now, it seems.

Knowing how a missing dafult charset can affect browsing, it might be an idea to
consider whether moz should be forced to set one if none is detected. Or is such
a situation so buggy it simply "can't happen again" ?

no.. you have a good argument that moz should not send a blank Accept-Charset
header.  IE6, for example, doesn't send an Accept-Charset header (by default),
so servers shouldn't have any trouble with a missing Accept-Charset header.
*** Bug 101105 has been marked as a duplicate of this bug. ***
Whiteboard: PDT <html><body></body></html> bug → [PDT], <html><body></body></html> bug
now that 97606 has been fixed, i think this bug becomes far less severe, and
could even be marked fixed.  however, i'd like to keep this bug open to cover
adding code to prevent the Accept-Charset header from being sent out with a
blank value.  this would at least eliminate the possibility of these regressions
popping up again in the future.

removing nsbranch+ and topembed keywords... removing PDT from status whiteboard.
Severity: critical → trivial
Status: NEW → ASSIGNED
Keywords: nsbranch+, topembed
Priority: P1 → P5
Whiteboard: [PDT], <html><body></body></html> bug → <html><body></body></html> bug
Summary: pages show up blank → pages show up blank - avoid sending blank Accept-Charset header
Comment on attachment 50681 [details] [diff] [review]
v1.0 patch - prevent setting blank headers

r=valeski
Attachment #50681 - Flags: review+
Keywords: nsbranch, topembed
Keywords: nsbranch, topembed
Keywords: nsbranch+
Whiteboard: <html><body></body></html> bug → [PDT],<html><body></body></html> bug
Given the trivial nature of your fix, I think we should take it on the branch
since it seems to fully prevent the problems reported here.  I'm giving this
PDT+ provisional on completion of the super review and testing.
Whiteboard: [PDT],<html><body></body></html> bug → [PDT+],<html><body></body></html> bug
Comment on attachment 50681 [details] [diff] [review]
v1.0 patch - prevent setting blank headers

r=gagan
*** Bug 101728 has been marked as a duplicate of this bug. ***
Darin - Pls check this one in today.
Comment on attachment 50681 [details] [diff] [review]
v1.0 patch - prevent setting blank headers

sr=mscott
Attachment #50681 - Flags: superreview+
Whiteboard: [PDT+],<html><body></body></html> bug → [PDT+],<html><body></body></html> bug, ready-to-land
fixed-on-trunk
Whiteboard: [PDT+],<html><body></body></html> bug, ready-to-land → [PDT+],<html><body></body></html> bug, fixed-on-trunk
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
*** Bug 102752 has been marked as a duplicate of this bug. ***
verified on branch:  Accept-Charset: ISO-8859-1,... sent out on all platforms

Win 98, Linux rh6, mac os9 - 0.9.4 20011011 bits
Keywords: vtrunk
Whiteboard: [PDT+],<html><body></body></html> bug, fixed-on-trunk → [PDT+],<html><body></body></html> bug
*** Bug 85468 has been marked as a duplicate of this bug. ***
This bug doesnt seem to be fixed - it just seems that smaller pages have started
working, while larger ones still exhibit the same or similar behavior... when
the behavior is different, the HTML page gets truncated. Otherwise, it is blank
with the browser's default blank html document (<html><body></body></html>). In
either case, the socket to the server is disconnected apparently by the browser.
This is the case with Win98SE and 0.9.6 and OS/2 0.9.6 builds.

As I have some httpd servers to test what is happening, I can tell you the
following incorrect things happen... 

In loading pages over 30K(?), the file gets truncated somewhere
along the way and Mozilla only shows a few K of it if any of it
at all...

The webserver (trace option) shows the following which seems
to be a unique occurrence with Mozilla... 

HTWriter_write: Error on socket output stream!!!
...

continues to try to handle request as normal, all other
trace lines are normal till right when it should still be
sending data and it writes this in the tracelog...

Keep-Alive.. Keep_Alive is -1 and KARequest is 1.
Keep-Alive.. Exit HTTPD 1.1 loop.
...
Disconnected Socket 1035.

The Keep_Alive response is incorrect, and the socket
was already previously disconnected... none of this
is a timeout issue, as these tests were done locally
for a file that gets queued and sent by the server in
an otherwise immeasurably small amount of time (under
a tenth of a second anyway). 

It then uninitializes the HT functions and ends the thread.

This doesnt happen with any other browser I have tried...
NS/2 2.02
NS/2 4.04
NS/2 4.61
Opera 5.12 for Warp
IE 4
IE 5
AOL (IE 4)

Here's a test document from a web based news server that 
exhibits this problem - even on today's OS/2 build
(2001120111)

http://64.50.165.139/testdl.html



Rob Mauro
WebMaster@FoodPlaces.com
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I disagree, this bug is fixed.  See bug 100134 for an explanation.
The problem was that sites that use IBM's servlet engine WebSphere parsed
the header incorrectly, and would barf if this particular header was empty
AND there was no Content-Type header.
What you're seeing is another problem.  I have seen it also, when submitting
large pages to the validator at www.htmlhelp.com.
Robert, I have to disagree with you.  This has not regressed, all the pages that
used to fail under this bug still work.  What you are seeing is a new problem. 
You have given a very good and detailed analysis, please post it into a new
bugreport.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: