Closed Bug 215479 Opened 22 years ago Closed 21 years ago

<form method=post> does not pass $_SERVER['PHP_AUTH_USER'] variable

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
FreeBSD
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: matt, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5a) Gecko/20030801 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5a) Gecko/20030801 Mozilla Firebird/0.6.1 While using <form method=post> on a page, after clicking the "submit" button, the $_SERVER['PHP_AUTH_USER'] and $_SERVER['REMOTE_USER'] variables do not get passed onto the next page. In PHP, a var_dump() proves that the variables are not being passed. The variables are passed using IE and Konqueror (I believe that in 0.6.0 they did work.) Reproducible: Always Steps to Reproduce: 1. Create a PHP File with a form ... <form method=post> (register globals off) 2. Click submit on the form 3. The variables $_SERVER['PHP_AUTH_USER'] and $_SERVER['REMOTE_USER'] will not be passed by firebird. Actual Results: The variables are not accessible on the next page. Expected Results: They should appear in the var_dump()
I confirm than i have the same problem on Windows 2000.
it's pretty ugly removing the dust from IE for this bug. I confirm, it happens on my xp. lately i'll try this on my slackware. regards
Does this also occur on Mozilla instead of Firebird? If so this should go to the correct Browser component.
QA Contact: asa → mpconnor
yes of course. it happens on them both
Might it be worth nabbing a copy of Mozilla and testing it? If someone has a mozilla build I can give them an example URL...
i'm sorry, i didn't understand what you told, what is 'nabbing'?
Sorry ... I meant to say... would it be worth it to download and compile a build of mozilla and test it? (I only have Firebird) ... or ... if someone has a copy of mozilla already built on their machine, I can give them a test URL to see if this bug affects mozilla too (although I would assume it would)...
ok thanks, I just wrote that it happens on them both. in any circustamces and any OS
thanks for the quick responses :) moving to correct component and confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: mpconnor → asa
.
Component: General → Form Submission
Product: Firebird → Browser
Version: unspecified → Trunk
it's a honor for me helping for this great purpose
What HTTP headers do these PHP variables correspond to?
Assignee: blake → form-submission
QA Contact: asa → ashishbhatt
should be these: header("WWW-Authenticate: Basic realm=\"My Realm\"");
This seems to be a well known issue. Is there any fix? I just received the following from a site I was trying to register on : **************** "We detected an order that was received from a Gecko enabled browser. Gecko enabled browsers have a Mozilla bug in them that drops all form variables as they pass thru a secure server running formmail, a common form to email script used by most order forms. Please resubmit your order using a standard MSIE web browser or we can phone you to reenter the information and complete the order process." ****************
It is true that I bumped into this bug through https...it may work for http too, unsure.
Do we have a testcase?
Have there been anymore updates on the status of this bug?
Matt: There probably won't be any progress on this bug unless someone can create a testcase.
Not a problem. Do I just set one up on one of my servers and post the information and a step by step to cause the problem? Is that how that works? -Matt
OK, here is a test case for both HTTP and HTTPS: http://www.atopia.net/test/mozbug215479/step1.php https://secure.webaries.com/atopia/test/mozbug215479/step1.php http authentication is test/test There is one difference since the original bug. The $_SERVER['PHP_AUTH_USER'] variable seems to be being passed in both situations (http and https), but the $_SERVER['REMOTE_USER'] variable is still not being passed in either case (http or https). However, if you access any page and continue to refresh it, or visit the source code (just change the .php to .source) and then go back to the .php file, the variable $_SERVER['REMOTE_USER'] is still set. It only dissapears once the form is posted. Hope this helps, Matt
that looks like a PHP bug, not a Mozilla bug. The variables you speak of are PHP variables, on the HTTP side Mozilla only sends one header, so if you get the information at all (as you do) then it means it is getting through.
Agreed. I tested my test case in IE and it did not work. I know though that last September I tested it in IE and it did work, which is why I filed the PR. Possibly I'm not setting up the test case the same way, but I'm pretty sure I am. Problem seems resolved as far as mozilla is concerned, I will forward this onto PHP...
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
(In reply to comment #23) > Agreed. I tested my test case in IE and it did not work. I know though that > last September I tested it in IE and it did work, which is why I filed the PR. > Possibly I'm not setting up the test case the same way, but I'm pretty sure I > am. Problem seems resolved as far as mozilla is concerned, I will forward > this onto PHP... I believe this may still be an issue on the FireFox side. I have been working on a Java program that can listen and accept connections via HTTPs. I have been testing it by using MSIE or FireFox with a local URL https://localhost. My Java app then returns what was sent from the browser. I have tested both GET and POST operations. In the POST method with MSIE I see all the passed variables in the header as expected but in FireFox I don't get any variables in the header. Per HTTP 1.1 the variable data should be included in the header ?!?! *** Here is an example POST result to my Java app from MSIE: POST /testme.asp HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* Referer: https://localhost:7000 Accept-Language: en-us Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: localhost:7000 Content-Length: 86 Connection: Keep-Alive Cache-Control: no-cache TESTINPUT=777777777777777777777777777777777777777777777777777&ANOTHER=What+is+g oing+on *** Here is an example POST result to my Java app from FireFox (notice the lack of variable data at the end): POST /testme.asp HTTP/1.1 Host: localhost:7000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.8 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8 ,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://localhost:7000/testme.asp *** Where is the POST data ! *** I upgraded to the latest FireFox 0.9x and still get the same result with FireFox.
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.