Problems with location HTTP headers, when using method POST

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
RESOLVED WORKSFORME
16 years ago
16 years ago

People

(Reporter: Georg Maaß, Assigned: Vinay Badami)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
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.

Comment 2

16 years ago
reporter: can you provide an URL to the website that is having problems?  ie.
can you provide steps to reproduce the problem?  thx!
(Reporter)

Comment 3

16 years ago
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.
(Reporter)

Comment 4

16 years ago
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.

Comment 5

16 years ago
-> badami for investigation
Assignee: darin → badami
(Assignee)

Comment 6

16 years ago
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.
(Reporter)

Comment 7

16 years ago
Created attachment 71178 [details]
protocolls from ie5 and mozilla made with ethereal (.tar.gz)
(Reporter)

Comment 8

16 years ago
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.
(Assignee)

Comment 9

16 years ago
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.

(Reporter)

Comment 10

16 years ago
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

Comment 11

16 years ago
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).
(Assignee)

Comment 12

16 years ago
After untarring/unzipping, Ehtereal with NT cribs about a block being > 64K.
(Reporter)

Comment 13

16 years ago
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)

Comment 14

16 years ago
Created attachment 71847 [details]
ethereal text file with comunication of IE5 on W2K
(Reporter)

Comment 15

16 years ago
Created attachment 71848 [details]
ethereal text file of communication of mozilla 0.9.7 on W2k

Comment 16

16 years ago
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.
(Reporter)

Comment 17

16 years ago
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.
(Reporter)

Comment 18

16 years ago
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...
(Assignee)

Comment 19

16 years ago
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.
(Reporter)

Comment 20

16 years ago
>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.
(Assignee)

Comment 21

16 years ago
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+.
(Reporter)

Comment 22

16 years ago
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.
(Reporter)

Comment 23

16 years ago
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).
(Reporter)

Comment 24

16 years ago
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?
(Reporter)

Comment 26

16 years ago
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
(Reporter)

Comment 27

16 years ago
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.
(Reporter)

Comment 28

16 years ago
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.
(Assignee)

Comment 29

16 years ago
This seems to be working fine with 099 and onwards. 
Will not patch 097.
Marking as WFM.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.