Closed Bug 197426 Opened 22 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: