Closed Bug 82948 Opened 23 years ago Closed 22 years ago

HTTP headers visible in the window

Categories

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

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 140107
Milestone:
Future

People

(Reporter: thorgal, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [pipelining])

Attachments

(6 files)

screenshot showing the problem
49.71 KB, image/png
Details
Screenshot showing the problem in Bugzilla voting
48.64 KB, image/png
Details
A screenshot from an IIS server.
68.97 KB, image/png
Details
An http log from a bad mcafee load
677.21 KB, text/plain
Details
Screenshot belonging to logfile
63.03 KB, image/png
Details
trace of network traffic
3.64 KB, text/plain
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; rv:0.9+) Gecko/20010526
BuildID:    2001052621



Reproducible: Always
Steps to Reproduce:
1.Visit http://fantomas.webnet.pl/~thorgal/www/
2.Look at the top of the page.

Actual Results:  HTTP headers clearly visible. I'll attach a screenshot
demonstrating the problem in a moment.

Expected Results:  No HTTP headers should be visible.

The site from the URL is not always up. Try in a few hours if it times out.

    
    

    
  
Been seeing similar things the past 4-5 days. I see this in particular when
going back to bug-query form in bugzilla. Often the whole page renders twice,
tags can be partly showing, selects from dropdowns scattered around on page etc.
This was earlyer a symphtom of the same bug.
Resembles bug 68483.

    
    

    
  
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
This wfm on linux and win2k in a build pulled on 6/11
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Sorry, it still is not fixed.

I think that my "Reproducible: Always" was a bit premature, but now I've found a
way to make it so.

1. Visit http://fantomas.webnet.pl/~thorgal/
2. Scroll down to the bottom of the page.
3. Click "www/"
4. I can see the http headers.

However, I've just verified on IRC that people using exactly the same version of
moz cannot see it on my site. I'm beginning to think that perhaps the timing is
important here, as fantomas.webnet.pl i the same machine I run moz on.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
However I don't see headers on Miloslaw's site, I have encountered that 'effect'
 too, mostly browsing localhost pages. So maybe that's the way to follow

    
    

    
  
I do not see the headers either on the reporter's site 

    
    

    
  
Ok, but could you try setting up apache locally and browse on "localhost"? I
think this is where most people encounter this bug.

    
    

    
  
I see them occasionally on bugzilla, maybe 1% of the time.  Build 2001061120.
I am also running mail with a POP and an IMAP account, if that could influence
things.

    
  
Keywords: qawanted

    
    

    
  
David,

Please make the bugzilla problem a new bug report. 

Miloslaw,

Please try Mozilla 0.9.1 or some later build.

    
    

    
  
Created bug 85525

    
    

    
  
Miloslaw: what build are you using to reproduce this? Please try with the latest 
trunk builds.

    
    

    
  
Well, with 2001061308 I couldn't replicate it. What's weirder, it looks like it
no longer happens with 0.9.1, either, though it did before.

As I said before, it's probably timing-dependent.

    
    

    
  
Marking wfm per reporter
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
VERIFIED:
To some, this would be long awaited feature (bug 27119).
I've seen this mysteriously happen in IE and Comm on a very rare basis, so it
could be external causes.

Please reopen if it occurs again.
Status: RESOLVED → VERIFIED
Keywords: qawanted

    
    

    
  
Please consider reopening this bug.

In fact, the way of the page being messed up looks the same as in bug 85525. 
Bug 85525 should be marked as a dupe of this bug.

Pay attention to the screenshot (attachment 36276 [details]).  Notice that there's an
extra character (looks like a "zero") after the line "Apache/1.3.19 Server ...
Port 80".

Now look at the screenshot (attachment 38179 [details]) in bug 85525.  Some characters are
blended in the page, not just the HTTP header itself.

Finally, look at my screenshot (attachment 40074 [details]) in bug 85525.  The same thing
happens again.  There're more characters than just an HTTP header entering into
the page.

Any comments?

    
    

    
  
I'm going to reopen, and I'm taking any guesses as to the cause.

I never see this, so I'm not much help :(

Are other people here using slow connections or ISP's with latency or anything
special?
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

    
    

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

    
    

    
  
Benjamin,
   The connection I use is relatively speedy both in terms of bandwith and
latency.  I will admit that I have not seen this happen in a few weeks, and when
I did see it it was on pages like bugzilla pages where the server was
constrained by cpu and disk speed and very busy.  It is possible that it is a
server problem and not a mozilla problem.
   As far as the seemingly random stuff appearing in the middle of the page,
most of it can be attributed to chunking, and the long strings of hex digits
have to mean something to someone intimate with HTTP. I had assumed that we were
sending the raw socket buffer to the parser somehow, but I cannot see how that
would even be possible.

    
    

    
  
benc can you try reproducing this?  Reporter can you confirm this still happens
with a nightly build?

    
    

    
  
As I said on 2001-06-14 03:26, I no longer see this bug here. Just checked with
2001070206 and no HTTP headers have shown up.

    
    

    
  
+verifyme:

I'm going to check the duplicate reports, and then verify it.
Keywords: verifyme

    
    

    
  
ben.  I know there is a dup around.  reassign to you.
Assignee: neeti → benc
Status: REOPENED → NEW

    
    

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

    
    

    
  
Pressing "Reload" button always displays page correct on my computer, when
header is displayed

    
    

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

    
    

    
  
I find this has been happening quite frequently recently on bugzilla pages.

Adding keywords
Keywords: nsCatFood, 
          
            regression

    
    

    
  
It seems to be 100% reproducible.

1) Make a change to a bug.

2)Click go back to bug xxxxx.

Every time I do this I see garbage in the bug report.


    
    

    
  
I think you have to do the last step before the 'bug processed' page has
completely loaded. Seems to be a timing issue.


    
    

    
  
Maybe you can find additional information in Bug 43729

    
    

    
  
Test.



    
    

    
  
My testcase now wfm with Linux 2001090408.

May be fixed.


    
    

    
  
Damn, just saw it again after updating a bug. Seems to be happening less
frequently though.


    
    

    
  
Now you have to allow the 'bug confirmation page' to completely load before
clicking 'back to bug XXXX'.

My feeling is this should be marked a dupe of bug 43729.


    
    

    
  
Another observation:

load a bug list
click on a bug and make a change
go back to bug list - no headers seen
click on a bug - header appears on page

So it looks as if it happens on the first bug loaded after updating a bug, but
not on bug lists.


    
    

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

    
    

    
  
My test case seems to wfm now with Linux 2001091221.


    
    

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

    
    

    
  
Have not seen this at all since 2001-09-12. Can this be marked wfm now ?


    
    

    
  
Marking WORKSFORME based on comments.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME

    
    

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

    
    

    
  
Reopening because of bug 101802 and adding its contacts to CC on dveditz suggestion.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
Added attachment to show this bug occurs in bugzilla voting.
To reproduce:
1. Open a bug in bugzilla (like this one :)
2. Click "Vote for this bug"
3. Confirm your vote.

You will see the attached page, with HTTP headers on top *and* mangled codes in
the middle of the page.

    
    

    
  
The same thing happens to me a lot when using the site at http://www.nic.mx/
(the Mexican country code domain registration site).  Various secure (https)
pages in the site, pertaining to registering and modifying domains and contacts,
come up sporadically with raw HTTP headers visible, though they usually work if
you reload them.

    
    

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

    
    

    
  
You folks are not crazy. We regularly see this bug occuring in our Webapps. A
little background: 
The apps are heavily JSP and Framed based
Tomcat 3.2.2 public release
Apache 1.3.20 public release
Mozilla bld: 2001101117 or Netscape 6.2 public release

I can regularly duplicate the error. It does not matter if I hit localhost/myapp
or one of our build/release servers. It does not matter if it is a fast or slow
connection. 

For example the loading of external JavaScripts is regularly interupted by the
HTTP heaader making its way into the actual rendered pages. If you view the
source however it will have no evidence of the header text. So it is the actual
rendering engine that seems to be at fault. (i could be wrong) example script
innterupt can be seen in JavaScript console:

Error: missing ; before statement
Source File: http://localhost/oaa/js/image_scripts.js
Line: 17, Column: 9
HTTP/1.1 200 OK
--------|

Example page interupt taken from our Portal application page this is the main
frame in a 3 frame webapp. The header and navigation frames are unaffected:
######## very top of page in browse window#########
HTTP/1.1 200 OK Date: Fri, 09 Nov 2001 22:23:22 GMT Server: Apache/1.3.20
(Win32) mod_jk pragma: no-cache Cache-Control: no-store Expires: Thu, 01 Jan
1970 00:00:00 GMT Servlet-Engine: Tomcat Web Server/3.2.3 (JSP 1.1; Servlet 2.2;
Java 1.3.1_01; Windows 2000 5.0 x86; java.vendor=Sun Microsystems Inc.)
Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Transfer-Encoding: chunked
Content-Type: text/html;charset=ISO-8859-1 e42
#########rather screwed up page partailly renders at this point########

Again there is no sign of this in the view-source of the page.


    
    

    
  
Beware the Mozilla view source command.  The source that it shows you is not
necassarily what it displayed.  It usually goes back to the server to fetch
another copy to display.

How regularly are you seeing this? Would it be possible for you to have a packet
sniffer watch the traffic between Moz and apache/tomcat? This probably is a
Mozilla bug, but it'd be nice to be sure.

Could you turn HTTP logging on in mozilla? to do this I think that all you need
to do is set the environment variables

NSPR_LOG_FILE=[some logfile location, for example C:\stuff\moztest\logfile.txt]
NSPR_LOG_MODULE=nsHTTP:4

The logfile does not capture everything that could be desired, but may give
clues, especially if it can be compared with ther log of a successful loading of
the same page.

Barring any of that is there any way that we could get access to some of your
flaky pages?

    
    

    
  
Just to add to the confusion and also to suggest that maybe just maybe it is not
a browser problem.... I have just seen this occur in MS IE 6.0. 

I am opening a bug with Apache HTTP to report this problem. As I believe it may
be an Apache HTTP or Tomcat 3.2.2 issue. But I am not positive.  I seems that
everyone reporting this problem is using Apache and/or Tomcat. 

Apache Bug #?? - Search summary use: "HTTP headers showing in browsed pages"
I am also gonna try getting the NS log as  David Einstein suggested.

    
    

    
  
Just to add to the confusion and also to suggest that maybe just maybe it is not
a browser problem.... I have just seen this occur in MS IE 6.0. 

I am opening a bug with Apache HTTP to report this problem. As I believe it may
be an Apache HTTP or Tomcat 3.2.2 issue. But I am not positive.  I seems that
everyone reporting this problem is using Apache and/or Tomcat. 

Apache Bug #?? - Search summary use: "HTTP headers showing in browsed pages"
I am also gonna try getting the NS log as  David Einstein suggested.

    
    

    
  
Ok wierd Stuff going on here.... any way Apache Bug report# for Comment 49/50
Thank you very much for your problem report.
It has the internal identification `general/8971'.
The individual assigned to look at your
report is: apache. 

>Category:       general
>Responsible:    apache
>Synopsis:       HTTP headers showing in browsed pages
>Arrival-Date:   Thu Dec 06 16:40:00 PST 2001

    
    

    
  
Well I have been devling into the problem a bit further. Unfortunatley the
problem has got to be with the browser. Using Apache HTTP 1.3.22 ( HTTP 1.1 ),
setting the http.conf setting; BrowserMatch "Mozilla/5" downgrade-1.0 forces the
HTTP server to downgrade to HTTP 1.0 for the specific browser. In doing so all
the problems mentioned in this bug go away. So for whatever reason Mozilla
cannot properly deal with HTTP 1.1 headers. The problem manifests itself most
often, in our case, using JSP pages in frames with Tomcat 3.2.3 and Apache HTTP
1.3.22. Sorry I don't know how to fix it.

    
    

    
  
I am still not convinced that it is definitely a Mozilla problem.  I agree that
it is an http 1.1 problem, and my pet theory is that it is related to chunking,
but the evidence is still shaky.  It could as easily be a problem with apache
doing bad chunking as Mozilla being confused by chunkiung. A packet sniff of a
bad page load, or a debug dump thereof, or better both, would be very helpful in
tracking down the exact location of the error. 

    
    

    
  


  
OK, this is the first time that I have seen this from a non apache 1.3 server.
This is from build 2001122103. It's sort of old, but I doubt that much has been
done over the last week or so.

    
    

    
  


  
This is the mozilla http debug log from the session that terminated with the
load of the page that is shown in the next attachment. (I closed Moz right
after the screenshot was taken.) I do not have a packet sniffer set up on my
network now, but if necessary I can set one up.

    
    

    
  
This problem has occurred for me with the following browsers:
Netscape 6.2.1 (Win2K)
IE5 (Mac)
Netscape 4 (Mac)
IE5.5 (Win2K) - reported by user but not reproducible by me

I have not had a problem with Mozilla 0.9.7

The headers on the page I have trouble with are: <start>




HTTP/1.1 200 OK
Date: Mon, 07 Jan 2002 21:43:42 GMT
Server: Apache-AdvancedExtranetServer/1.3.22 (Mandrake Linux/2mdk) PHP/4.0.6 
DAV/1.0.2
Last-Modified: Thu, 06 Dec 2001 16:53:22 GMT
ETag: "d797c-105a-3c0fa282"
Accept-Ranges: bytes
Content-Length: 4186
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

<end>

Are the extra lines before the headers part of the problem?

    
    

    
  
I believe this may be a variation on this theme.

I'm using Mozilla 0.9.7 (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7)
Gecko/20011221)connecting though a proxy (Squid/2.4.STABLE2) and can reproduce
the following behaviour as many times as I like.

At the bottom of the Verisign.com home page is a link to "Secure your web site,
click here" which consists of the following URL
http://ad.doubleclick.net/jump/N595.verisign/B919985.2;sz=102x80;ord=[timestamp]?

This Doubleclick URL then tries to redirect back to the Verisign site, but
instead of giving the page I see the HTTP header, preceeded by some garbage
chars as follows :

http://www.verisign.com/cgi-bin/go.cgi?a=b108628610110000

~(ÿ§Xâ+

    
    

    
  
not 100% reproducable but on
http://www.fusionauthority.com/alert/index.cfm?alertid=99 clicking on the main
page link at the top of the page shows http headers, sometimes in the top frame,
sometimes in the side frame..... looks like there's a double page-completion
status header.. build 2002012903

HTTP/1.0 200 OK Date: Thu, 31 Jan 2002 21:46:34 GMT Server: WebSitePro/2.5.8
Accept-ranges: bytes Content-type: text/html Page-Completion-Status: Normal
Page-Completion-Status: Normal

    
    

    
  
I am getting reports from the field that this problem is occuring with several
other App/Web server combinations and more occurances in IE. I will details if I
get any that are worthwhile. 

The work around if you are using Apache is to add the following line to the
http.conf:

    BrowserMatch "Mozilla/5" force-response-1.0

forcing Apache to comunicate with Mozzilla 5 browsers using only HTTP 1.0
protocol. This does not however fix the root of the problem. So what is wrong
with HTTP 1.1 protocol that is causing these problems?

    
    

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

    
    

    
  
-> darin

this is showing up at  http://www.application-servers.com  per duped bug.  I can
reproduce it consistantly with the 03/11/02 builds on winNT and mac osX.  Not
showing up in 4.x or IE (http 1.1 selected).   
Assignee: benc → darin
Status: REOPENED → NEW
OS: Linux → All
QA Contact: benc → tever

    
    

    
  


  
attaching a trace but the problem goes away when I use my trace tool.

    
  
Keywords: nsCatFood, 
          
            verifyme

    
    

    
  
-> moz 1.1
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.1

    
    

    
  
got this email:

> Darin,
> 
> I have not used Bugzilla before so I'm not sure how to add comments to a
> bug. We are seeing this problem (HTTP headers in the HTML file) as well. I
> would like to add my comments/experiences to this bug in the hope that it
> might lead to a solution.
> 
> We have only seen this problem with Netscape 6.x. Never with Netscape 4.x or
> any version of IE. We are running on the Windows platform. It only happens
> with transfer encoding of chunked. When we first encountered this I traced
> it to the following HTTP/TCP exchange (using Sniffer). The final chunk (the
> 0 length one) would be broken up as follows by our server:
> 
> 0<crlf>  (in one TCP packet)
> <crlf> (for the HTTP footer termination - in the following TCP packet)
> 
> What I saw happen was that Netscape would issue another HTTP Get on the same
> port in between these two TCP packets. In other words, it didn't wait until
> the HTTP protocol was complete (the final <crlf> for footer termination)
> before sending the next Get. When it received the standalone <crlf> it
> seemed to interpret that as the end of the HTTP header for the Get and treat
> the rest of the HTTP transaction as data. Since the next TCP packet would
> actually contain the HTTP header information, this was handled as data and
> displayed (or in our case, part of a Javascript file so we got weird
> behavior from the script). This was the theory of what was happening, in any
> case. I believe the above should be valid HTTP/TCP, but it was consistent in
> causing problems for Netscape. In order to work around this, I made sure
> that our server never broke the TCP packet on the <crlf><crlf> boundary.
> That seemed to resolve the problemfor a while. However, it has now
> reappeared. Sniffer traces show everything looks ok (i.e. no breaking on the
> crlf boundaries). We are generating a fair number of chunks in our files,
> many of small sizes (1-10 bytes per chunk). From further debug it looks like
> Netscape gets confused when it sees <crlf> entities in the data stream. We
> were able to work around the current example of the problem by adding
> characters into our data stream to break up some of the <crlf> pairs. I
> think this all points to a problem in the Netscape/Mozilla? handling of
> chunk encoding.
> 
> I can provide sniffer traces/examples of Netscape cache files if that will
> help.
> 
> Let me know if there is some other way I should get the above information
> added to the bug report ...
> 
> Thanks,
> 
> Mark Parenti

    
    

    
  
I have found a site that exposes this problem consistently, at least for me:
<http://www.police.se/>. The headers are displayed in the top and bottom frame.
It doesn't matter whether HTTP pipelining is turned on.

Last seen in RC2-20020503-01 on Linux and in stock 0.9.9 on Win98.

    
    

    
  
Confirming the results of the last comment. Linux 2002050109.


    
    

    
  
Using HTTP/1.0 makes the problem go away on the website for the swedish police.
On other sites like : http://se.doro.com/start.asp it's enough to just disable
http pipelining.

Could it be a problem in HTTP/1.1 that pipeling is just more likely to expose ?

    
    

    
  
BTW I use Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+) Gecko/20020507.

I also believe both bug #140853 and bug #140107 to be DUP's of this bug

    
  
Whiteboard: [pipelining]

    
    

    
  
ok, with http://www.police.se/ there's a server bug.  headers will show in the
upper and lower frame whenever keep-alives are used.  the problem is that the
server for some reason is injecting an additional 6 bytes (\r\n\r\n\r\n) in
between two HTTP responses.  mozilla tries to tolerate some garbage at the head
of a packet, but in this case the garbage is delivered as a separate packet.  we
therefore end up treating the response as a HTTP/0.9 response, and as a result
you see the headers appearing on the screen.  so, this can only be fixed by
evangelizing www.police.se.  one thing to note is that the site is using the
tomcat servlet engine... i still have to look to see if that might be the
commonality between all of the sites where this problem has been observed.

    
  
Target Milestone: mozilla1.1alpha → ---

    
    

    
  
I have also seen this on Mozilla 0.9.7 with my Seminole webserver
(http://www.conman.org/software/seminole). Does it exhibit the bug as well? 

I have never seen this on IE using my webserver, just Mozilla. It is hard to
reproduce however and seems to depend on timing. I have since upgraded from the
90MHz PPC Mac that I used to see the problem on and have not seen it again. 

    
    

    
  
mass futuring of untargeted bugs
Target Milestone: --- → Future

    
    

    
  
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510

With my own local webserver, this only happen occassionally when 
pref->debug->Networking->Enable Disk Cache is true and I have inserted a HTTP
header => Content-Length.
What happen if the Content-Length have the wrong number of bytes?

It only happen for the first time accessing the html page after starting
Mozilla. Clicking on reload and it never happen again.

Thanks.


    
    

    
  
A site which (in my experience) suffers heavily from this problem is:
http://www.albert.nl/ah (click the "proefwinkelen" image to see what I mean)

    
    

    
  

*** This bug has been marked as a duplicate of 140107 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → DUPLICATE

    
    

    
  
v

    
    

    
  
verified
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: