Closed Bug 151443 Opened 22 years ago Closed 20 years ago

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

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: swbrown, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

screenshot of the captured packets
149.75 KB, image/png
Details
http logs for 20020214 and 20020216
58.41 KB, text/plain
Details 
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 activecampus.ucsd.edu 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:

<html><body>
<?php

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">
</form>

</body></html>
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 www.directv.com and
help.broadband.att.com, to name two recent examples.  IE6 and Opera both get
past the forms in question without difficulty, as does Netscape 4.
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 activecampus.ucsd.edu.  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:  http://developer.intel.com/design/network/products/security/aax7120y.htm   
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
happens on windows as well
OS: Linux → All
Priority: -- → P3
regression between 0.9.8 and 0.9.9
Keywords: regression
regression between 2002021412 and 2002021621
bug 120682 looks like a good candidate for causing this behavior.
darin,

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
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.
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....

Reporter:

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?
hmm.. so is this still a bug with the latest trunk or branch builds?
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 activecampus.ucsd.edu. 
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: 
http://developer.intel.com/design/network/products/security/aax7120y.htm"

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.



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.
did anyone noted the relation between the last three digits of the bug number
and the bug itself? ;-)

john,
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)

darin,
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! 
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.

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.
confirmed regression from bug 120682 by backing out the patch from old CVS.
Depends on: 120682
This bug seems to have gone away a while ago; I can now access the sites that
used to give me problems.
the ucsd URL still has the same problem.
Keywords: testcase
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
I have had serious problems with an https site with both 1.3 and
1.4(2003031004).   The site is https://www.gosbs.com/nas .  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.
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 ?
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.



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
locally?!

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: 
https://banking.raiffeisen.at/html/login_demo_eng.jsp
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!
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.

reassigning
Assignee: alexsavulov → form-submission
QA Contact: vladimire → ashishbhatt
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.
* 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.
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
Any comments for my last two comments? Shall I open new reports for them?
the signon.expireMasterPassword problem is definitely not this bug, so you
should file a new bug
New bug: 219990
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: