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

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
16 years ago
9 years ago

People

(Reporter: bandrzej, Unassigned)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pipelining])

Attachments

(9 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 117226 [details]
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.
(Reporter)

Comment 2

16 years ago
Created attachment 117228 [details]
HTML output of the page view with the https header show bug.

Through the source code, you do not see anything within there containing the
http headers.
(Reporter)

Updated

16 years ago
Attachment #117228 - Attachment description: Source code of the page with screenshot. → HTML output of the page view with the https header show bug.
(Reporter)

Updated

16 years ago
Attachment #117226 - Attachment description: Screenshot of the browser window → Screenshot of the browser window with the https header show bug.
(Reporter)

Comment 3

16 years ago
Created attachment 117230 [details]
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.
(Reporter)

Updated

16 years ago
Attachment #117226 - Attachment is obsolete: true
(Reporter)

Comment 4

16 years ago
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
(Reporter)

Comment 5

16 years ago
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>
(Reporter)

Updated

16 years ago
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
(Reporter)

Comment 10

16 years ago
Yes, http pipelining was disabled.

Comment 11

16 years ago
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

Comment 12

16 years ago
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.

Comment 13

16 years ago
Created attachment 117401 [details]
http headers visible in otherwise well rendered page

http headers visible in otherwise well rendered page

Comment 14

16 years ago
Created attachment 117402 [details]
source code of above page - no problems apparent

source code of above page - no problems apparent

Comment 15

16 years ago
will, brian: can either of you please capture the HTTP log using the steps
described in comment #11?  thx!!

Comment 16

16 years ago
Created attachment 117600 [details]
debug logfile from comment 11

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.

Comment 17

16 years ago
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.

Comment 18

16 years ago
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!!

Comment 19

16 years ago
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.

Updated

16 years ago
Attachment #117600 - Attachment is obsolete: true

Comment 20

16 years ago
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.

Comment 21

16 years ago
Created attachment 119296 [details]
NSPR_LOG_FILE snip

The problem is with URL http://www.tvworld.bg:88/showcom.php

Comment 22

16 years ago
Created attachment 119297 [details]
Screenshot with the problem

Comment 23

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

Comment 24

16 years ago
Created attachment 121961 [details]
log file (error at contact.html)

Comment 25

16 years ago
Created attachment 122001 [details]
HTTP log of same transaction without bug

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.

Updated

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

Comment 26

16 years ago
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.

Updated

16 years ago
Target Milestone: mozilla1.5alpha → Future

Comment 27

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

Comment 28

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

Comment 29

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

Comment 30

15 years ago
Created attachment 132159 [details]
screenshot of browser possibly attributable to 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.

Comment 33

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

Updated

9 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.