Closed Bug 125471 Opened 23 years ago Closed 23 years ago

Problems with location HTTP headers, when using method POST

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: georg, Assigned: badami)

Details

Attachments

(3 files)

protocolls from ie5 and mozilla made with ethereal (.tar.gz)
8.39 KB, application/x-gzip
Details
ethereal text file with comunication of IE5 on W2K
18.68 KB, text/plain
Details
ethereal text file of communication of mozilla 0.9.7 on W2k
13.74 KB, text/plain
Details
Mozilla has problems with location HTTP headers, when method POST was used to send the original request. It does not display the new page and probably does not request for the new page. I do not have a sniffer here to see whether the sever (IIS) sends correct headers. But IE does not have any problems. NN4 also succeeds. But Mozilla remains in loading for ever. It also doesn't timeout like known from documents, that contain no data. It does not hang nor crash.
You can use Mozilla to log the headers. In your shell, set NSPR_LOG_MODULES to "nsHttp:5" and NSPR_LOG_FILE to some filename. Then start mozilla and load the page in question (is there a URL involved that we could try??). Then quit and attach the log file to this bug.
reporter: can you provide an URL to the website that is having problems? ie. can you provide steps to reproduce the problem? thx!
I'll try your suggestions on my working place on monday, because the pages are inside of our locale network at the moment. They should work well before published to our customers.
Something else goes wrong. It is not a 302 status with Location redirection, it is a 500 status as result of the form transmission. The form uses enctype multipart/form-data. So the summary needs to be changed, as soon, as we know, what goes wrong during form transmission. A real bug is, that Mozilla does not display the response belonging to the 500 status message. HTTP/1.1 500 Server Error Server: Microsoft-IIS/5.0 Date: Mon, 18 Feb 2002 09:40:13 GMT Connection: close Content-Type: text/html Content-Length: 79 <html><head><title>Error</title></head><body>Falscher Parameter. </body></html> Instead of displaying this, Mozilla does not refresh the window content and remains in animating the busy icon in the upper right corner. This is a bug. I now try to detect the diofferences between the stuff set to the server by IE an the stuff sent by Mozilla, which caused this 500 when using Mozilla instead of the 302, when using IE.
-> badami for investigation
Assignee: darin → badami
Reporter Can u please provide the following: 1. A network trace of the whole interaction using IE. 2. A network trace of the whole interaction using Mozilla.
I do not understand the bytes between the form fields. The problem that causes IIS to send a 500 feedback instead of the desired redirection must be in some of that bytes, I don't understand, because I do not see any differences in the form fields transmitted. I hope this helps you to find the bug.
Reporter Thanks. But i'am unable to open this file using ethereal. Dunno what is cauing this . Can we try the following : 1. Mail me the ethereal file. 2. Is it possible that u save this as a text file or a ethereal sun snoop file ? If so attach that to the bug and also mail me the file. Also, can u explain what extra bytes u r seeing thru the dumps which are different between Moz and IE ? Thanks for all the help.
did you extract the zipped tar archive? It contains two textfiles, which were exported from ethereal. I didn't try to re import them into ethereal. The content of the tar archive ist ie5.txt and moz.txt.
Attachment #71178 - Attachment description: protocolls from ie5 and mozilla made with ethereal → protocolls from ie5 and mozilla made with ethereal (.tar.gz)
Attachment #71178 - Attachment mime type: application/octet-stream → application/x-gzip
fwiw: i'm almost able to open the files in ethereal... part way into loading, ethereal fails saying that the files are corrupt. (using ethereal v0.8.18 under rh7.2).
After untarring/unzipping, Ehtereal with NT cribs about a block being > 64K.
I try to send you tomorrow, form my working place the files without zipping them to a archiv. I had no problem loading them with etherreal on W2K
Reporter, I looked into the traces of mozilla and IE. I find the following difference in values in the post data a) submit.x b) submit.y How significant are these values? In the mozilla the content length is 3883 and in IE it is 3809. But in mozilla the boundry is larger by 2 chars in length. The content disposition header occurs 37 times, which sums to addition of (37*2) bytes in mozilla, hence mozilla and IE are posting same content length data. The repsonse from server says "FALSE PARAMETER" in case of mozilla, hence I would like to know what does submit.x and submit.y stand for. Since only those parameters have different values. Or are they just holding the x, y position of submit button. This is the inference I have got from the trace logs you have given. To proceed further I would appreciate if you could upload a test case, else look into the server logs and give some more information on them.
sumbit.x and submit.y are the positions of the mousee pointer when clicking on the submit button. The values are not used. Did you find anyhwere a space caracter or any other illegal character inside the request? On some hypüerlinks I detected the same response (400 BAD REQUEST) = FALSCHER PARAMETER, on NN4, when there was a space character inside the URI. So I shall look, wheather I can find such a space or any other illegal character inside the form action, which is handled different by Mozilla an the other browsers.
I 've looked in the form for white space or other illegal characters in the form action, but there is nothing suspicious. I think, we should rename the bug, because the first assumption about the characteristics of the problem was wrong. It has nothing to do with location headers. There are 2 problems: 1. problem what causes the server to respond with a 400 BAD REQUEST header, when the forms are submitted by Mozilla? 2. Why does Mozilla remain in loading mode (still waiting for the response) also after receiving the response instead of displaying the error message (FALSCHER PARAMETER). With Mozilla 0.9.9 the first bug seams to be fixed. No more 400 BAD REQUEST response. Now I get the correct result page. Hm...
Ur comments are not very clear. 2. Why does Mozilla remain in loading mode (still waiting for the response) also after receiving the response instead of displaying the error message (FALSCHER PARAMETER). With Mozilla 0.9.9 the first bug seams to be fixed. No more 400 BAD REQUEST response. Now I get the correct result page. Hm... U say that u r no longer getting a BAD REQUEST and u r getting the correct result page. If that be so, then what does the comment 2 mean ? Is it with a version prior 099 ? From all that we have traced, we seem to be sending the correct stuff to the server. Please let us know if there is still a problem to be traced ? If not, can we close this bug down ? If the bug still exists is it possible to get us a test case on the internet ? Since there is no concrete data either way, leaving this bug as unconfirmed.
>U say that u r no longer getting a BAD REQUEST and u r getting the correct > result page. If that be so, then what does the comment 2 mean ? Is it > with a version prior 099 ? Yes 0.9.7 > Please let us know if there is still a problem to be traced ? If not, can > we close this bug down ? If the bug still exists is it possible to get > us a test case on the internet ? I 'll try to duplicate the database for test purposes and then create a test account. I'll inform you, when I finished that. This will take a few days. Then you can take the 0.9.7 release to test. May be that you find something about phenomen 2, whicht might be not fixed or might be fixed too.
Does it mean that phenomenon 2 still happens with 099 or 099+ ? If it does not I think we should just close this down. We are happy if all is well with 099 and/or 099+.
I my current applications it does not occure with 0.99 but this might be a result of not occuring of problem 1) with 0.99. So my thought was to build a duplicate of the original application as testcas for 0.07 to get an idea how to build a more suitable testcase especially for 0.99 to test problem 2 independent from problem 1. At home I now try to simulate the response of the server an then look what happens. I'll send you then an url of the testcase if I succeed to force problem 2) with 0.97 in a simple testcase. Then We can look, whether this happens too with 0.99.
All attempts to build a simple testcase that simulates problem 1) by anserwing with a 400 BAD REQUEST Header and some simple dummy error message failed. 0.97 allways displayed the message and did not behave as in our problem application. I 've now copied the database to a test database and waiting now for my boss to tell me how to create a DSN to make the asp scripts to login to the test database. When the DSN is made, then you can experiment with a copy of the original application. I hope, this will help to find more details about the problem to see, whether problem to is impossible without problem 1) or whether it is independent from problem 1) and may need a separate fix. Problem 1) is fixed in 0.99, but I don't know, whether the 2) problem might also ocure independent from problem 1).
Now this works with it's own test database. So you can do your experiments without disturbing the life database. http://www.regioport.com/georg/newentry.asp With Mozilla 0.9.7 the problems occure, when sending page 4 of 4. With Mozilla 0.9.9 we get only other problems (like mostly POSTing twice, but this is reported in an other bug and has nothing to do with this bug)
So... let me get this straight. With 0.9.9 this bug is gone?
I don't know, because the pbug has two problems, and I could not create a testscenarion, which results in the second problem independent freom the first. So I don't know, whether the second problem is fixed too, or not. You must use 0.97 to detect the reasons for the second problem and then build a testcenario which produces it independent from problem 1, if your research show that it can occure indepent. Then you can test, whether 0.99 has fixed both or just the first. I'ts a shity situation
https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 This page has the same symptoms with 0.9.7. No problem with NN4.7. When I used this page last time about 3 quarters ago with Mozilla, it also worked with Mozilla. I'll try it later with 0.9.9 to see, whether ist ha this problem too.
No tested with 0.9.9: https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 No problem with 0.9.9. The big problems seam to focus on 0.9.7.
This seems to be working fine with 099 and onwards. Will not patch 097. Marking as WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: