68483 - server headers render as clear text in browser

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[R.K.Aa.]

linux 2001-021006

Been seeing this in this build and previous at various places:
HTTP headers are appearing in clear text in a pace, partly ruining content.
No appearant pattern to when it triggers. Even images "decode" in cleartext.

Attaching screenshot from two different URL's

Comment 1

[R.K.Aa.]

Attachment: server headers showing

Comment 2

[R.K.Aa.]

pace=page.
Modifying summary, upp'ing severity.
This does not happen each time, and a forced reload cures it.
Pretty bad looks when it happens though, and it made me unable to log properly
out of my netbank, which is not good.

Comment 3

[R.K.Aa.]

I suspect this has to do with the network/cache bug of late.
On one occation i went to an ordinary page, and x and xfs acted up, taking 99%
CPU. What slowly rendered in browser between total freezes had a binary look but
no recognizable header. When i did a ps -ef during this, it turned out PSM had
suddenly spawned. Had to kill the browser.
I had not been to secure sites in the session.

Comment 4

[R.K.Aa.]

What spawned that latest error was middle-clicking this link to open in new
window. Froze three times in a row, had to kill. After deleting all cache it
loaded OK. Unable to reproduce now. http://www.vg.no/pub/vgart.hbs?artid=8751649

Comment 5

[Henrik Gemal]

I'm also seeing images appear as plain text in the middle of webpages on win2k 
latest builds.

Comment 6

[R.K.Aa.]

i haven't seen this one since dought's network redesign was backed out.

Comment 7

[Darin Fisher]

There were some problems with the Socket and Cache components on dougt's branch. 
The problems have been fixed, and the branch should be re-landing soon.

I'm going to assume that this is not a bug on the trunk.  Please reopen if you
find another example of this bug.  Marking INVALID.

Comment 8

[R.K.Aa.]

It's back. Reopening.

I'm not 100% sure of the pattern here, but it is certainly easyer to reproduce
when clicking a link on a page before origining page has fully loaded.

Try this, but read through it first - on a quick connection you may have to
click very fast:

-Go to http://www.dnmi.no
-Before the page has loaded pics: Click link in blue text called "Varsler"
(found on left hand side somewhat down the column)

Result: First you freeze for a while, then garble displays.

I've come across the bug several times today after re-checkin of dougt's changes
to netwerk.

What's worse: When the garbled page has displayed, mozila becomes very slow and
unresposive. It's as if all that garble-code leaks through to chrome.
Closing the offending window doesn't help. Have to close the whole app (or kill)
and restart, to get it up to par again. CC dougt.

Comment 9

[R.K.Aa.]

Attachment: not only headers but images too, rendered as rubbish. 2001022121

Comment 10

[R.K.Aa.]

spamming.. but it struck me that this bug may be something in the new networking
code now having changed the behaviour of an *old* oddity:

Earlyer, when i click a link in a page with frames *before* it was loaded,
mozilla would *seemingly* start loading the new url, but in reality it was the
old page that keept pouring in. When loading was done, mozilla settled,
displaying a fully loaded version of the original page, while the link i clicked
only displays in URL-field. I then had to click reload-button to actually load
that page. Nothing stopped old page from loading when new link was clicked.
This has appearantly "kinda" changed now: It *is* a new "page" showing in
browser, the old page is cleared before something starts to render.

However: Since all or parts of content gets garbled beyond recognition, it is
hard to tell whether the garbled parts were content actually "destined" for the
previous page or not. Something is messing up bad, at least.

Comment 11

[R.K.Aa.]

*** Bug 70101 has been marked as a duplicate of this bug. ***

Comment 12

[R.K.Aa.]

It indeed turns out that the content from previous page goes on loading into a
new one. Try loading some large bug-report in bugzilla - and just as it starts
rendering, change the number in URL field so for instance 55055 reads 55056.
Hit enter right away.

Result: Garbage and parts of bug 55055 will render in the page AND but 55056
will render below it, also partly garbled.

In dup 70101 Mats Palmgren observes garbage occuring when going back/forth
before page is loaded.

Seems the sockets aren't only being reused: Eventual traffic on them is not told
to stop when user hits Stop-button, nor when clicking links etc. This is bound
to cause grief in particular for users on slow connections.

Comment 13

[R.K.Aa.]

Networking

Comment 14

[Doug Turner (:dougt)]

Darin, have you see this problem?

Comment 15

[Darin Fisher]

I haven't been able to reproduce this problem (though I haven't tried very
hard either).

Comment 16

[R.K.Aa.]

it seems this is the issue in bug 70147 also?

Comment 17

[Doug Turner (:dougt)]

70147 is a different bug.  I am not sure if they are connect as of yet.

We really need to be able to reproduce this reliably.  R.K.Aa, what are your
cache settings?  can you reproduce this when you have cache completely
disabled?  Is there any pattern that you see between the sites that create this
problem.

qa help needed

neeti, I have a similar bug that darin asked me to own.  I am reassign this one
to me.

Comment 18

[neeti]

*** Bug 70065 has been marked as a duplicate of this bug. ***

Comment 19

[Matthias Versen [:Matti]]

I saw this 3x in 1 week.
(See screenshot in the duped bug).

My cache settings are all default.
I saw this 1x in bugzilla. I used the back button before the new page finished 
loaded. 

Comment 20

[R.K.Aa.]

Test1:
------
Deleted cache.
Used Cache setting: Compare... "Once per session"
Started loading http://www.dnmi.no
Clicked link "varsler" (left hand side) almost before images had started
rendering on page

Result:
Near freeze - xfs struggling - what finally renders after over 10 minutes is
mainly "binary garbage"
(P3/500). Screenshot 1.

Test2:
------
Changed setting to never compare with cache.
walked the same walk: same result.

Page contain images and use frames.


Test3:
------
Killed moz again. Restarted. Still without using cache:

Started loading bug 55055.
Changed bug# in URL-field to 55056 and hit enter before 55055 had loaded.
That started to render OK so i immediately edited URLbar to load 55057, hit
enter, then
changed to 55058 and hit enter:

Result: Garble, and *two bugs* (55055 and 55058) load on one page.

Similarity to the other site: Page has an image near top.

Comment 21

[R.K.Aa.]

Attachment: Test1: http://www.dnmi.no

Comment 22

[hirata masakazu]

*** Bug 70807 has been marked as a duplicate of this bug. ***

Comment 23

[Doug Turner (:dougt)]

*** Bug 70188 has been marked as a duplicate of this bug. ***

Comment 24

[Doug Turner (:dougt)]

http keep-alive is broken.  Please verify this by going into the network 
settings preferences (Preferences -> Debug -> Advanced -> Networking) and 
uncheck the box that says "Enable Keep Alive".


Working on a patch with fixes it.

Comment 25

[R.K.Aa.]

Confirming: Unchecking "keep alive" stops this bug from happening.

Comment 26

[Doug Turner (:dougt)]

Attachment: Proposed Patch v1

Comment 27

[Doug Turner (:dougt)]

The last patch:

1. Forces cancel actions on the socket transport to dispatch an event so that
they will be handled promptly.

2. Protects the critical section in IsAlive()

3. Sets the state of the process() state machine to failed if a request has been
canceled with a failure code.

Comment 28

[Darin Fisher]

r=darin

Comment 29

[neeti]

Doug,

Cool! On applying this patch stops the leaks of nsSocketTransport on Cancel, we 
were seeing.

Neeti

Comment 30

[Doug Turner (:dougt)]

sr=waterson

Comment 31

[Doug Turner (:dougt)]

Fixed checked in.  Good bye nasty bug.

Comment 32

[R.K.Aa.]

Trunk 2001030521 linux:
Turned keep-alive back on - ran same tests as above: Bug gone :)

Comment 33

[Darin Fisher]

*** Bug 71180 has been marked as a duplicate of this bug. ***

Comment 34

[Tom Everingham]

marking verified per reporters comments