Closed Bug 37778 Opened 25 years ago Closed 25 years ago

browser doesn't handle simple response of HTTP protocol

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
CLOSED FIXED

People

(Reporter: gvu, Assigned: ruslan)

References

Details

I created a simple form and used Mozilla(build#15) to post my data into the CGI server. The CGI server reponsed back to the browser in simple response of HTTP protocol, which only sent back the body entity, and Mozilla somehow did not recogize and parse the response.
reassigning
Assignee: rods → pollmann
build#15==milestone 15? please respond with a url of a sample cgi script source [plus live link would be nice] that demonstrates the problem. Also, what browser behaves correctly, netscape 4?
I don't have a live link but I already fixed my bug by making CGI send back in the full-response format. The browsers which behave correctly for the simple- response are IE4, IE5 and NS4.
Reporter: Even though you have fixed the problem, if it's really a problem the Mozilla developers should know about it. Please post here the code you were originally using that works in other browsers but does not work in Mozilla. Then we'll try to fix it and you'll be able to use it in future code, not to mention everyone else developing similar solutions won't have to figure out the same problem.
I don't have a code because it is C code on server side. If you want to reproduce the problem, you have to make the server send data to the browser in SIMPLE-response which means it doesn't send the the status line in the response.
This sounds familiar - and is not specific to form submission. I believe the reporter means something like this is "full response": -------- begin server response -------- HTTP/1.1 200 OK Content-type: text/html <HTML> <BODY> Test </BODY> </HTML> -------- end server response -------- and something like this is "simple response": -------- begin server response -------- <HTML> <BODY> Test </BODY> </HTML> -------- end server response -------- Giac, is this correct?
Right. You are right and this bug doesn't relate to form submission.
This is a general networking problem, forwarding on to networking people. Thanks!
Assignee: pollmann → warren
Component: Form Submission → Networking
Changing QAContact to tever@netscape.com due to bug's re-assignment to Networking...
QA Contact: ckritzer → tever
=> ruslan
Assignee: warren → ruslan
I didn't even know such responses were allowed in the first place, but Ok. Did 0.9 spec allow such response?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → M17
spec for 1.0 has such response and 1.1 doesn't, but IE4,IE5 and NS6 do handle that response.
Pls. provide test url ....
Status: NEW → ASSIGNED
I don't have a live url because I am working on it internally in my company.
Is there a link for me to test the fix?
I don't have a link, but I can test it with my code if I can have a new build.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
That's great. I can get the new build on tomorrow and test it then.
When will your fix be in the build? I just got the new build this morning. I tested it and it still doesn't work yet.
Do you have a live link that I can test your fix? thanks, Giac.
I used test server from netwerk/testserver and it worked just fine for me.
Does the last build contain your fix?
yes it does
well, my test code doesn't work. I will try to give you the link so that you can test it.
Please do.
The test url is: http://216.100.236.112/test/indextest.html. When you hit the submit button you will receive the respose back in the Simple- mode. If you try it with NS4,IE4 and IE5, you will see the error dialog and the bottom frame goes blank. If you try it with Mozilla, you will see nothing happen.
Please let me know wherether you can access to that page or not. Thanks, Giac.
I can access it, but when I hit submit NS4 displays some javascript error, is it allright?
right. That's what you are supposed to see on NS4. But on NS6, you will not see that error becuase the browser doesn't pick up the respone sent back.
I meant Mozilla instead of NS6.
Ruslan, Are you working on the bug now?..if you have any question about my CGI server and the testing code, you can feel free to ask. Giac.
Yes. Please create a link which I can use without POST (so I can telnet into it quickly and see what's coming out) and if it doesn't work - reopen a bug. I tested my fix with simple response via test server and it worked for me.
This bug only happen on the POST request because there is the routine which handles the POST request and send back the SIMPLE response. GET request works just fine. If you want to see what coming out, you can use the tool like EtherPeek to look at the packets going between my server and your computer. I just downloaded mozilla source code for Window. Can you tell me how to compile the project? Thank, Giac.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I can access the url you've specified and I can see the dialog box. The response which is coming back is not a simple response, but HTTP/1.0 response. Are you sure it's not a setup error?
You can try it again. It should be a simple response now.
Still works for me
It doesn't work for me and I use the build from last Friday. I will get the new build to test it and let you know.
Ok. I'm using the link from the bug report. There's nothing changed between friday and today. Let me know.
Ok. I'm seeing a different behavior with NS4 and Mozilla. NS4 would display a dialog box complaining about CGI function not defined. Mozilla would present an authentication dialog. The response is NOT a simple response; in the debugger I can clearly see HTTP/1.0 coming back in the status line
:)))..yes..it works now...the new build this morning has the fix in it... Thanks a lot, Giac.
closing then
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Closed
Status: RESOLVED → CLOSED
*** Bug 38613 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.