Closed Bug 44536 Opened 24 years ago Closed 23 years ago

HTTP POST fails after http authentication

Categories

(Core :: Networking: HTTP, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: M.Hankus, Assigned: darin.moz)

References

Details

(Keywords: dataloss, testcase)

Attachments

(1 file)

Mozilla (2000070308) does not POST data. Changing method to GET resolves
problem, but i think it is not right way to do it.
reassigning
Assignee: rods → pollmann
Reporter, please attach a URL or test case that shows this problem, or this bug 
will have to be closed out.  Thanks!
If there was a general problem with the POST method, I think there would be a
loud outcry from the many people using Mozilla to work in Bugzilla ;)
I cannot duplicate this problem, and am marking it "worksforme", unless the
reporter can provide a specific URL or steps to reproduce...?
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME

Hello !! I took a closer look at all this. So here is some additional info. POST
generally works fine. Problems occure when script specified as ACTION of the form
requires authentication (in which case Mozilla posts data twice -checked logs of
the server). I will try to configure server to demonstrate this situation, but
give me some time.
Mirek, any chance this is bug 27006?  To see, look at the source of the page 
returned by the server after the POST.  If it contains a <META> with a CHARSET 
specified, then it's probably bug 27006.  This would explain both the double 
post, and the apparent failure of posting to work at all.

If this is a duplicate of bug 27006, you can just add comments to that bug 
report.  Thanks!
There was a META tag, but i removed it and problem occurs. Check out this URL
http://www.ce3.pl/~mhankus/form.html There is a simple form. enter any data in a
text field and press submit. You'll be prompted for username and password. Enter
user pass and password pwd   You will see output of cgi script. Line begining
with STDIN: displays all the data which appeard on the stadnard input. When form
is submited with Mozilla there is no data (netscape works fine).  One more
thing. Open this form with fresh Mozilla (i mean just started - not the one
which worked for some time).

There is one more strange behaviour. Opening URL (above), submitting from, and
then pressing reload button makes Mozilla spawn additional browsers until
systems runs out of resources. 
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: Mozilla does not POST data → POST fails after http authentication
I see this too.  Thanks for the test case!
CC'ing Gagan - this is probably a networking related problem.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Seems like a networking problem, passing over to the gurus.  This is the first 
request we make when posting the form.

POST /~mhankus/auth/a.cgi HTTP/1.1M
Referer: http://www.ce3.pl/~mhankus/form.htmlM
Host: www.ce3.plM
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m17) Gecko/20000709M
Accept: */*M
Accept-Language: enM
Accept-Encoding: gzip,deflate,compress,identityM
Keep-Alive: 300M
Connection: keep-aliveM
Content-type: application/x-www-form-urlencodedM
Content-Length: 8M
M
var=test

This results in a server challenge.  Then, we post this as the second request:

GET /~mhankus/auth/a.cgi HTTP/1.1
Authorization: Basic cGFzczpwd2Q=
Host: www.ce3.pl
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m17) Gecko/20000709
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive

The authorization header is correct, but the request method has changed from 
POST to GET and we have lost the post data.  Nav does this correctly, and the 
second request is identical to the first with the addition of the Authorization 
header.
Assignee: pollmann → gagan
Status: ASSIGNED → NEW
Component: Form Submission → Networking
Summary: POST fails after http authentication → HTTP POST fails after http authentication
Please ignore the terminal M after each line in the first request, it was a bad 
cut and paste job on my part - those are carriage returns.  ;)
beta3
Assignee: gagan → ruslan
Keywords: nsbeta3
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3+]
Not holding PR3 for this; marking nsbeta3-. Please nominate for rtm if we really
need to fix this before shipping Seamonkey.
Whiteboard: [nsbeta3+] → [nsbeta3-]
pulling in ruslan's necko bugs ->darin
Assignee: ruslan → gagan
Status: ASSIGNED → NEW
QA Contact: ckritzer → tever
Target Milestone: --- → M19
http bugs to "Networking::HTTP"
Assignee: gagan → darin
Component: Networking → Networking: HTTP
cc'ing self. Sorry for the spam. This bug just bit me in the butt on a project.
I had to redesign my authentication scheme to get around it... :(
Blocks: 61681
removing stale nsbeta3 keyword.
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
*** Bug 68666 has been marked as a duplicate of this bug. ***
*** Bug 70057 has been marked as a duplicate of this bug. ***
The last two dups had between them 5 duplicates.  This seems like a somewhat
serious usability issue in some cases.  Is there any chance this could get fixed
sooner than "Future"?
keyword from bug 70057
Keywords: dataloss
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
Keywords: nsbeta1
Read bug 41241 for a similar problem to do with window targets that I fixed.

It's possible that the form.submit() impl is failing to find or provide the 
correct window target so that the first opened POST channel is disgarded and 
then resubmitted as a normal GET operation.
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla0.9 → mozilla0.9.1
*** Bug 69047 has been marked as a duplicate of this bug. ***
my changes for bug 76866 will fix this bug as well.
Depends on: 76866
the http branch didn't completely fix this problem.  we also need to rewind
the post data stream before resending.  attaching a patch that does this.
*** Bug 75783 has been marked as a duplicate of this bug. ***
r=bbaetz
rs=mscott
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
*** Bug 81188 has been marked as a duplicate of this bug. ***
*** Bug 83519 has been marked as a duplicate of this bug. ***
*** Bug 83094 has been marked as a duplicate of this bug. ***
verified:
winNT 2001061304
mac os9 2001061308
Linux rh6 2001061308
Status: RESOLVED → VERIFIED
+testcase, thanks for setting that up!
Keywords: testcase
*** Bug 82475 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: