HTTP headers get displayed in the browser




17 years ago
17 years ago


(Reporter: lmb, Assigned: darin.moz)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [pipelining], URL)


(1 attachment)



17 years ago
Build ID 2002051009 on SuSE Linux 7.3.

When visiting (for example) in a fresh tab, HTTP headers
are displayed as part of the page body in the main frame. A reload cures this. 


Display includes:
OK Date: Tue, 14 May 2002 21:31:06 GMT Server: Apache/1.3.24 (Unix) PHP/3.0.18
Keep-Alive: timeout=10, max=497 Connection: Keep-Alive Transfer-Encoding:
chunked Content-Type: text/html b1d     

This only happens with HTTP pipelining enabled.

If I turn HTTP pipelining off, it does not occur; if I turn it back on, it
happens even if the tab is not "virgin", so I assume some HTTP pipelining
variables aren't correctly initialized.

Comment 1

17 years ago
yup, i'm seeing the same thing with the 1.0.0-20020514 linux build.

hopefully this is something we can solve on our end.  reducing severity to major
since this only happens when pipelining is enabled.  leaving untargeted for now.
Severity: critical → major
Ever confirmed: true
Whiteboard: [pipelining]

Comment 2

17 years ago
It also happens with other websites with frames actually; so if it isn't easily
solved, I would suggest hiding the HTTP pipelining option in 1.0-final.

Comment 3

17 years ago
same as bug 140853 and bug 140107?

Comment 4

17 years ago
*** Bug 144940 has been marked as a duplicate of this bug. ***

Comment 5

17 years ago
mass futuring of untargeted bugs
Target Milestone: --- → Future

Comment 6

17 years ago
Getting this on multiple frames when visiting the following page:

I'm using Moz 1.0rc3 under Linux x86

Comment 7

17 years ago
PS : my first bugzilla "Mid-air collision detected!" :)

Comment 8

17 years ago
See the same on my Moz 1.0RC3 (Windows 2000) :)

It appears on the new CGI-IRC 0.5 (demo :
Also on

The headers disappear when you use a proxy :)

Comment 9

17 years ago
This does not happen only with pipelining. If you go to and click on
any of the links you will get headers in the display (1.0 RC3). Reload makes
them disappear.

This is happening on Windows XP with pipelining disabled. Changing back to
critical and making OS = ALL.
Severity: major → critical
OS: Linux → All
This can't be critical..
Severity: critical → major

Comment 11

17 years ago
Hey, I just changed it to how it was before Darin Fischer reduced it to "major" 
on the basis that it only happened when pipelining was enabled. I wasn't making 
a value judgement ;-)

It is a highly visible bug though that is sure to make Mozilla and NN look very 
broken to new users.


17 years ago
Keywords: mozilla1.0.1, nsbeta1

Comment 12

17 years ago
with the 2002061721 linux build: loads correctly with pipelining enabled!  likely a dupe of
bug 140107. pages also seem to load correctly now.

re: comment #9, i'm able to repro the problem with pipelining disabled.  when i
looked at a packet trace, it appeared that the server was sending some extra
HTML before the HTTP response headers.  i'll upload the resulting HTML document
to this bug report.  seems more like an evangelism bug to me... problem is not
reproducible with NS4.x so maybe they are doing some wacky UA sniffing.

*** This bug has been marked as a duplicate of 140107 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 14

17 years ago
using 2002061712 on win 2k and xp pro i still see http headers on
(rougly 9 out of 10 attempts, sometimes moz seems to fix the problem)

just sending thus URL cause some problematic ones seem to be resolved per comment 12

Comment 15

17 years ago
patrick: the 2002061712 build would not include the fix for bug 140107.  please
try today's build instead.  thx!

Comment 16

17 years ago
all of the links supplied in this report are working for me with the 06/18
builds except for the evangelism issue in comment #9

verified duplicate

Comment 17

17 years ago
per comment 15 : Darin, you're right. Sorry for jumping the gun. Issue is
resolved using 20021808
You need to log in before you can comment on or make changes to this bug.