Closed
Bug 44536
Opened 24 years ago
Closed 23 years ago
HTTP POST fails after http authentication
Categories
(Core :: Networking: HTTP, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: M.Hankus, Assigned: darin.moz)
References
Details
(Keywords: dataloss, testcase)
Attachments
(1 file)
1.33 KB,
patch
|
Details | Diff | Splinter Review |
Mozilla (2000070308) does not POST data. Changing method to GET resolves problem, but i think it is not right way to do it.
Comment 2•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
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!
Reporter | ||
Comment 6•24 years ago
|
||
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.
Updated•24 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: Mozilla does not POST data → POST fails after http authentication
Comment 7•24 years ago
|
||
I see this too. Thanks for the test case!
Comment 8•24 years ago
|
||
CC'ing Gagan - this is probably a networking related problem.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 9•24 years ago
|
||
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
Comment 10•24 years ago
|
||
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. ;)
Comment 12•24 years ago
|
||
Not holding PR3 for this; marking nsbeta3-. Please nominate for rtm if we really need to fix this before shipping Seamonkey.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Comment 13•24 years ago
|
||
pulling in ruslan's necko bugs ->darin
Assignee: ruslan → gagan
Status: ASSIGNED → NEW
QA Contact: ckritzer → tever
Target Milestone: --- → M19
Comment 14•24 years ago
|
||
http bugs to "Networking::HTTP"
Assignee: gagan → darin
Component: Networking → Networking: HTTP
Comment 15•24 years ago
|
||
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... :(
Assignee | ||
Comment 16•24 years ago
|
||
removing stale nsbeta3 keyword.
Comment 17•24 years ago
|
||
*** Bug 68666 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
*** Bug 70057 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
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"?
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
Comment 21•24 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 22•24 years ago
|
||
*** Bug 69047 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 23•23 years ago
|
||
my changes for bug 76866 will fix this bug as well.
Depends on: 76866
Assignee | ||
Comment 24•23 years ago
|
||
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.
Assignee | ||
Comment 25•23 years ago
|
||
Assignee | ||
Comment 26•23 years ago
|
||
*** Bug 75783 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
r=bbaetz
Comment 28•23 years ago
|
||
rs=mscott
Assignee | ||
Comment 29•23 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 30•23 years ago
|
||
*** Bug 81188 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
*** Bug 83519 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
*** Bug 83094 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
verified: winNT 2001061304 mac os9 2001061308 Linux rh6 2001061308
Status: RESOLVED → VERIFIED
Comment 35•23 years ago
|
||
*** 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.
Description
•