Closed Bug 197426 Opened 21 years ago Closed 14 years ago

see http headers in browser window but not in source code when performing https form post submits

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bandrzej, Unassigned)

References

Details

(Whiteboard: [pipelining])

Attachments

(9 files, 2 obsolete files)

HTML output of the page view with the https header show bug.
8.78 KB, text/html
Details
Screenshot of the browser window with the https header show bug.
126.32 KB, image/jpeg
Details
http headers visible in otherwise well rendered page
51.60 KB, image/gif
Details
source code of above page - no problems apparent
17.38 KB, image/gif
Details
NSPR_LOG_FILE snip
181.38 KB, text/plain
Details
Screenshot with the problem
91.44 KB, image/png
Details
log file (error at contact.html)
179.13 KB, text/plain
Details
HTTP log of same transaction without bug
157.11 KB, text/plain
Details
screenshot of browser possibly attributable to this bug
55.08 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

When performing a https post submit of the same form twice in a row, you see the
http headers in the browser window.  However, when you view the page source,
they are not in there.  This problem only occured after I upgraded from Modzilla
1.2 to 1.3.  Tried to reproduce in http with no results.

Reproducible: Sometimes

Steps to Reproduce:
1. Form that post data back to itself in https.
2. Post the data once.  The page is fine.
3. Post the data again, with or without changes.

Actual Results:  
Shows the http headers within the page. When viewing the source code, the source
code is fine and doesn't show the http headers in it.  Page still operates as
normal with links and form post submits.

Expected Results:  
Showed the page without the http headers mixed into the browser view.
This screenshot shows the exact screen that I see after a second post submit
under https.  The Update User Information form submits back to itself.
Through the source code, you do not see anything within there containing the
http headers.
Attachment #117228 - Attachment description: Source code of the page with screenshot. → HTML output of the page view with the https header show bug.
Attachment #117226 - Attachment description: Screenshot of the browser window → Screenshot of the browser window with the https header show bug.
This screenshot shows the exact screen that I see after a second post submit
under https.  The Update User Information form submits back to itself.
Attachment #117226 - Attachment is obsolete: true
Also, the page is rendered twice...particually before the header, then fully
after the header, but with some broken colors and table layouts.
Version: Trunk → 1.0 Branch
Comment on attachment 117226 [details]
Screenshot of the browser window with the https header show bug.

><HTML><BODY><IMG src="http://bugzilla.mozilla.org/attachment.cgi?id=117230&amp;action=view" alt="The image “http://bugzilla.mozilla.org/attachment.cgi?id=117230&amp;action=view” cannot be displayed, because it contains errors."/></BODY></HTML>
Attachment #117226 - Attachment filename: screenshot-bug.jpg → no.jpg
Attachment #117226 - Attachment mime type: image/jpeg → image/gif
I´ve seen the same with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
Gecko/20030310 but never with 1.3b

I wasn´t able to reproduce it, it just occurs from time to time. But it never
had anything to do with https:// but was in a LAN with Apache 1.2 on Suse 8.0 as
webserver. I first thought, that it had something to do with the PHP-script I
was writing (using header() function) but I´ve never seen it with IE or Opera.
And the script works most of the time perfectly with Mozilla except sometimes I
see the HTTP-Header information like on the screenshot of Brian.
I don´t have a screenshot, but I´ve seen the same like Brian in comment #4

In the first half of the page I see the source of the file, then the http-header
and after that the page as it was expected to be shown.
Reporter: Have you enabled Http Pipelining ?
Assignee: asa → darin
Component: Browser-General → Networking: HTTP
QA Contact: asa → httpqa
Version: 1.0 Branch → Other Branch
In my case http pipelining was disabled
Yes, http pipelining was disabled.
Brian:  can you please collect a HTTP log for us?  here's what you'd need to do:

1- exit mozilla completely
2- open up a DOS prompt, and type:

  C:\> set NSPR_LOG_MODULES=nsHttp:5
  C:\> set NSPR_LOG_FILE=C:\log.txt
  C:\> \Program Files\mozilla.org\Mozilla\Mozilla.exe

3- reproduce the problem
4- exit mozilla
5- finally, upload C:\log.txt to this bug report, or feel free to email it to me
directly if you wish to keep its contents confidential.

thanks in advance!!
Severity: normal → major
I also see this bug with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Confirm that it is in 1.3 but never seen in 1.3b.
I got it when accessing http://www.linuxjournal.com/article.php?sid=6473 but
after a refresh it went away.

I see the HTTP header at the top of the page, and the page is otherwise
perfectly rendered.  Http pipelining off.  No proxy server in use.  Optimoz
0.3.5 loaded for mouse gestures.  Automatic image resizing turned on. 
Quickstart enabled.
http headers visible in otherwise well rendered page
source code of above page - no problems apparent
will, brian: can either of you please capture the HTTP log using the steps
described in comment #11?  thx!!
Attached file debug logfile from comment 11 (obsolete) — 
I removed a ton of space where you see the single line with no content. There
was nothing but what appeared to be spaces or NPCs, which made the file 2.4MB
in size, which means I couldn't attach it.
Darin: I work with Brian. He is out of the office for the beginning of this
week, so I have taken over for him. I followed your steps and uploaded the
logfile. If there is anything else, I will be monitoring the bug often.
thanks for the log file, but something is apparently wrong with it.  it should
be much larger!  it appears that you didn't attempt to load any URLs... is that
correct?  if so, please be sure to capture the log file while reproducing the
problem.  thx!!
I have emailed the logfile in its entirety to Darin. It is very large, and full
of very strange characters, particularly NULLs. As such, I was unable to attach
it to this bug.
Attachment #117600 - Attachment is obsolete: true
This bug has reliable behaviour on the web application our company is making. 
I'm using Debian Sid's mozilla 1.3-4.  I cannot give code but the behavior is
the following:

Our web application has 2 modes: user and administrator mode, both using 3-4
frames.  In user mode there's no problem.  In administrator mode the frame with
the problem writes the number 0 and then the HTTP headers followed immediately
by three hex digits numbers.  At the end of the page there are 2 numbers 0
separated by space.  And now the funniest part: after Ctrl-R all is OK.  After
the second Ctrl-R it shows the headers again.  After the third Ctrl-R there are
no headers and problems again.  And so on.   I attached a log generated by
NSPR_LOG_FILE but I see nothing interesting there.  I hope it helps.
Attached file NSPR_LOG_FILE snip — 
The problem is with URL http://www.tvworld.bg:88/showcom.php

    
    

    
  
i'm seeing this sporadically on mac os x (moz 1.3) for requests to
http://whitepages.tufts.edu/

    
    

    
  


  
note that pipelining is enabled in HTTP log files i've posted.

i ran into this bug while developing an internal project that sends headers
between multiple servers. the bug will only occur if the script does not exit
after redirecting to a page in HTTPS domain (see line 1168 in this file, line
1516 in previous file). the script used here is using PHP's header() -- e.g.
header('Location: ....'); -- but failed to call exit(); after sending said
header.

there's a comment about this in PHP's documentation
(http://www.php.net/manual/en/function.header.php), so i consider the bug to be
in my script. hope that helps.

    
  
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [pipelining]
Target Milestone: --- → mozilla1.5alpha

    
    

    
  
I have reported a different bug 204085
which is related to POST inside https: connection., but not
necessarily related to this bug.

However, maybe we get hit by the same underlying bug
although the symptoms are different.

I put a summary of bugzilla search using
the keyword POST and put a short comment in the bugzilla entry of
204085.


Some of you working on this problem might
find it useful or might be glad to know
that there are bugs that ring a bell.

    
  
Target Milestone: mozilla1.5alpha → Future

    
    

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

    
    

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

    
    

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

    
    

    
  


  
I am experiencing a problem similar to that described in this bug, where the
HTTP headers are displayed, except that in this case the rest of the page is
NOT rendered, it just displays the HTML source. I want to find out if this is a
symptom of this bug, or a new/different problem. 

Screenshot shows Mozilla nightly (2003-09-24) on Linux exhibiting the problem,
it also occurs for me using Mozilla 1.4 Phoenix nightly (2003-09-24) on Linux,
as well as Phoenix 0.6.1 on Linux and Win98.

I have seen this problem on a lot of websites, this is the first one where I
can easily reproduce it. Go to: http://www.cappuccinopc.com/comparisons.asp and
click on a product on the left, then click Comparisons on the top right, repeat
until you get a page with the HTTP headers followed by the page source. Is this
the same problem or a new bug?

    
    

    
  
I investigated the bug described in comment #30 (using Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827).

I loaded http://www.cappuccinopc.com/1baypc.asp and I have seen the bug the way
it can be seen in the attachment
http://bugzilla.mozilla.org/attachment.cgi?id=132159&action=view

So I played a little bit with the options in Preferences - Advanced - HTTP
Networking and encountered the following:

HTTP 1.0  HTTP 1.1  Keep Alive  Pipelining   Bug can be seen?
   x                                              no
   x                    x                         no
             x                                    no
             x          x                         yes
             x          x            x            yes

So I´ve seen the bug only with HTTP 1.1 and Keep Alive enabled. Perhaps this
helps a little bit with further investigations.

Bruno

    
    

    
  
Is anyone still seeing this bug? I've never encountered it since my last try 2 years ago and the testcase from #c31 works even with http1.1, keep-alive and pipelining enabled.

    
    

    
  
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Target Milestone: Future → ---
Version: Other Branch → Trunk

    
  
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: