POST over https (ssl) fails (wedges/spins) on a server that works for other browsers




HTML: Form Submission
16 years ago
14 years ago


(Reporter: Steven Brown, Unassigned)


({regression, testcase})

regression, testcase

Firefox Tracking Flags

(Not tracked)




(2 attachments)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
BuildID:    0000000000

POSTing form data over https on causes Mozilla to refuse
to display the result.  It just spins like it's trying to load the page but
can't finish.  POSTing form data works in http mode, and it works in https mode
on all other browsers I've tried (IE, Netscape 4.7x, Konqueror, Lynx+SSL, Opera,
etc.).  Only Mozilla has trouble.  For an example, try the URL given via http://
and via https://.

Reproducible: Always
Steps to Reproduce:
1.  Go to the URL (https) with Mozilla.
2.  Enter something and click to submit the form.

Actual Results:  Mozilla appears to be stuck trying to load the page.  The 'M'
icon is doing its animation like the page is loading but it's not getting anywhere.

Expected Results:  It should have shown the same page all other SSL-capable
browsers I've tried show, and the same page Mozilla shows in http mode.

The real application at this site has a login form with username+password, so we
know that Mozilla does successfully post the form data and process the result
(as it sets cookies), but it just spins without ever displaying the resulting
page in all cases.

The example given at the URL is a simple POSTable form to show the trouble
Mozilla has on that server when doing it via https.  The source is:


if(isset($text)) {
  print("You said: " . htmlentities($text) . "<p>\n");

<form method="POST" action="mozilla-bug.php">
Type something:
<input type="text" name="text">
<input type="submit" name="submit">


Comment 1

16 years ago
It's not a peculiarity of the UCSD site in the original report; I've seen it
happen trying to log into the account management pages on and, to name two recent examples.  IE6 and Opera both get
past the forms in question without difficulty, as does Netscape 4.

Comment 2

16 years ago
I checked with our admin and we have a SSL accelerator box doing the SSL for an   otherwise pretty standard FreeBSD/apache/PHP setup at  Maybe Mozilla has some sort of buggy interaction in its SSL code that gets triggered by it, seeing as that simple POST example works fine with Mozilla on my home sytem that uses normal apache SSL.  For reference, I'm told the box is an Intel AAX7120Y:   

Comment 3

16 years ago
Ever confirmed: true

Comment 4

16 years ago
happens on windows as well
OS: Linux → All
Priority: -- → P3

Comment 5

16 years ago
regression between 0.9.8 and 0.9.9
Keywords: regression

Comment 6

16 years ago
regression between 2002021412 and 2002021621
bug 120682 looks like a good candidate for causing this behavior.

Comment 7

16 years ago

this one is pretty strange. it occured somewhere between 0.9.8 and 0.9.9 and i
don't think this is form submission. i compared the captured packets and there
is some huge time gap betwen two packets sent by the client after the first app
data record packet (30 secs). there is also an alert package that is sent by the
client after the server sends a FIN,ACK (will attach screenshot, see packet 14)
Target Milestone: --- → mozilla1.0.1

Comment 8

16 years ago
Created attachment 87884 [details]
screenshot of the captured packets 

here is the list of captured packets. there was a change after 098 that caused
the packets sequels to be different. i couldn't find out how to dump the HTTP
trafic to see what is there, since the content of the packets with app data are
enrypted ai cannot say what is inside. however that 30 secs gap seems to be a
mozilla problem.

Comment 9

16 years ago
oh, i didn't noticed Andrews comment when i posted my last two ones (sorry!):

so is between 2002021412 and 2002021621. great! bug 120682 caused this. ok! but
why? what does John's patch that much different than before? and why only on
this server?(the patch has been around for a while but no one complained until
now) Investigating....


I noticed you run an Apache 1.3.22 / PHP 4.2.0. from my logs i couldn't figure
out if you use mod_ssl or something else. could you let us know please?

Comment 10

16 years ago
hmm.. so is this still a bug with the latest trunk or branch builds?

Comment 11

16 years ago
oh here is sbrowns comment i didn't noticed before (#2) sorry 'bout that:

"I checked with our admin and we have a SSL accelerator box doing the SSL for an
  otherwise pretty standard FreeBSD/apache/PHP setup at 
Maybe Mozilla has some sort of buggy interaction in its SSL code that gets
triggered by it, seeing as that simple POST example works fine with Mozilla on
my home sytem that uses normal apache SSL.  For reference, I'm told the box is
an Intel AAX7120Y:"

i bet it has something to do with the way the server works be cause otherwise is
working. i'm wondering what is the difference. hmmm, unless Darin wants ot check
this, i need to go first trough the SSL specs to understand what is going on.

Comment 12

16 years ago
I can confirm the bug creeping back in beteen 1.0 (Release) and 1.1alpha on
Windows 2000. Specifically when trying to log in to my bank via https using
acct. number and password Mozilla 1.0 works fine while 1.1alpha remains at the
login screen as described by others. I even tried the latest daily build
(6/20/2002) with the same (failed) results.

Comment 13

16 years ago
did anyone noted the relation between the last three digits of the bug number
and the bug itself? ;-)

Andrew pointed to your bigass formsub change in february this year (make formsub
not suck). can you think of something? is strange how only this particular
server makes us problems. (see comment #6)

where can i find the instructions how to dump the HTTP trafic in the console? i
need to do it during the SSL session. thx! 

Comment 14

16 years ago
add NSPR_LOG_MODULES=nsHttp:5 to your environment, and NSPR_LOG_FILE=c:\http.log
if you want to record into a log file.

Comment 15

16 years ago
Created attachment 88731 [details]
http logs for 20020214 and 20020216

this is a diff --side-by-side for NSPR http logs for a build before regression
(20020214) and after (20020216), pruned to ignore differences bewteen this=XXXX
and such.

There is only one real difference between the two logs until the later build
times out.  The log for the earlier build has an extra "nsHttpHandler::NewURI"
about a third of the way down.

Comment 16

16 years ago
confirmed regression from bug 120682 by backing out the patch from old CVS.
Depends on: 120682

Comment 17

16 years ago
This bug seems to have gone away a while ago; I can now access the sites that
used to give me problems.

Comment 18

16 years ago
the ucsd URL still has the same problem.
Keywords: testcase

Comment 19

16 years ago
lowering priority, retargeting. this is the only URL that i know so far that has
this problem. i don't know yet if is us or them. if there would be a serious
problem, this would not be the only problem known so far in this area.
Severity: critical → normal
Target Milestone: mozilla1.0.1 → Future

Comment 20

15 years ago
I have had serious problems with an https site with both 1.3 and
1.4(2003031004).   The site is .  Since the site is
secure, you can't test past the login page, but even there, the "login" button
requires multiple clicks to operate --- usually two.  Within the site, which is
a sequence of forms for voting, checkboxes seem to function normally, buttons to
"save and update" require clicking two, sometimes three, times, but give
expected results, and a "go to step 2" button requires two or more clicks but
then produces only a reload of the "step 1" page, not the actual step 2.  Opera
7 handles this sequence of forms with no problems. 

There are a phone number and an email address for "user support"  on the login page.

Comment 21

15 years ago
This bug still plagues us with Mozilla 1.3 (Linux) + 
Apache/1.3.27 (Unix) ApacheJServ/1.1.2 PHP/4.3.1 mod_owa 1.6.0 mod_perl/1.27
mod_fastcgi/2.4.0 mod_ssl/2.8.14 OpenSSL/0.9.6e

Calling the php script for form POST via https makes Mozilla spin for a long time
if the necessary credentials (user/password authorisation) have been saved
by Mozilla for another script of the same site needing authorisation,

but works o.k. if called from a freshly started Mozilla!!

This reminds me of the question: How can I make Mozilla forget credentials
without stop / restart ?

Comment 22

15 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

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.

Comment 23

15 years ago
This is still a major problem in 1.4 for me (going back to 1.2!):

The electronic banking solution I use behaves strange: It sometimes ignores
clicks, shows incomplete pages or empty windows etc. Most important, it doesn't
even allow me to sign on: The submit of the logon form always fails: The "logon"
button click seems to be ignored in 99% of all attempts, and if it works, the
new window popping up remains empty instead of starting the application. 
In 1.2, everything worked fine, 1.3 had the same problems.

Ethereal shows a mess of "Encrypted Alerts" and Resets of the https connection,
and my firewall complains about https packets which arrive from the banking
server but do not belong to any active connection. Obviously, the banking server
still considers the connection active while netscape has already closed it down

This is on Gentoo Linux with sys-kernel/gentoo-sources-2.4.20-r6 and
net-www/mozilla-1.4-r3 over a ppp connection.

The banking software also provides a demo login. It doesn't work, too, you may
use it as a test case:
select "RZB" in the pulldown

Please increase the severity at least to major (and also the priority), not
being able to use online banking with mozilla is a blocker for me!

Comment 24

15 years ago
comments 20 - 23 are not this bug.  if what you see does not match the
description for this bug, then it is a different bug.  look elsewhere or file a
new bug.

Assignee: alexsavulov → form-submission
QA Contact: vladimire → ashishbhatt

Comment 25

15 years ago
As a user, I can't tell if the cause of my problem is the same as for the
original problem or not, but the observable symptoms are (almost) identical:
Posts over https fail, because the expected result is never received correctly
due to some network strangeness. Also, at the network level, I see the https
alert packets also mentioned in the original problem.

Comment 26

15 years ago
* The network settings definitely influence the behaviour: With pipelining on, a
click on the login button is ignored in most cases. With pipelining off,
clicking the button usually opens a new window, but loading the application in
the new window fails.

* There are no network settings which work: Even with the most conservative
settings (HTTP/1.0, all options off), submitting the login and starting the
application fails. As I said, with moz 1.2 the site worked fine. And even with
the most conservative settings, I see unexpected SSL Alerts and TCP RST in the
network trace.

* There is definitely a difference between plain links (URLs) and form submits:
Clicking plain links works perfectly with pipelining off: No clicks ignored, no
incomplete content, everything ok. With pipelining on, each link must be clicked
twice (the first click is silently ignored, like clicking on the submit button
with pipelining on, the second click works fine).

So I believe we might have two separate problems here:
* One makes loading the application in a new window fail after a submit. It is
independent of the network settings.
* The other causes every submit, and every second link click, to fail
immediately. This one only happens with pipelining on.
In both cases, a network trace shows SSL alerts and TCP RST's.

Comment 27

15 years ago
Found the cause for my first problem, but can't explain it:
If my prefs.js contains "user_pref("signon.expireMasterPassword", true);" (it
did), the newly opened window remains blank. If this line is deleted or set to
false, the application starts and works fine in the new window.

Unfortunately, I don't know
* how this line came into my profile
* what this line means or controls
* and to which option in the prefs dialog it corresponds

Comment 28

15 years ago
Any comments for my last two comments? Shall I open new reports for them?

Comment 29

15 years ago
the signon.expireMasterPassword problem is definitely not this bug, so you
should file a new bug

Comment 30

15 years ago
New bug: 219990

Comment 31

14 years ago
Seeing as Intel now seems to disavow having ever created the AAX7120Y SSL
accelerator, we've junked the thing on our side, and the bug's been quiet for a
while, I don't think this is worth keeping in bugzilla any longer, so I'm
closing it.  Might be a useful clue for other SSL bugs in the future, but isn't
useful today.
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.