Response from CGI never ends.

VERIFIED INVALID

Status

()

Core
Networking: HTTP
P4
normal
VERIFIED INVALID
17 years ago
15 years ago

People

(Reporter: Prashant Desale, Assigned: Gagan)

Tracking

({qawanted})

Trunk
mozilla0.9.5
x86
All
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
If you submit Form to CGI. It returns with response document.
Laying out this response document never finishes. Mouse pointer seems busy all 
the time & document loading never finishes. Status bar shows "Transferring Data" 
forever.
This stops further executions, and confuses user completely.

BUILDS: 
2001-04-10-04 [Win95]
2001-04-10-04 [Mac]
2001-04-10-14 {Linux]

STEPS TO REPRODUCE:
1] Please visit URL above.
2] Select any option from select.
3] Click "Submit"
Now form will be submitted to foo1.cgi, and it will respond with response 
document.

EXPECTED RESULTS:
Response document will show following.
Text Box Value is: TextValue
Select Value is: SelectValue2 [ASSUMING YOU SELECT OPTION2]

And mouse pointer will not be busy anymore. Status bar will not show 
"Transferring data" forver.


ACTUAL RESULTS:
Response document shows following.
Text Box Value is: TextValue
Select Value is: SelectValue2 [ASSUMING YOU SELECT OPTION2]

And mouse pointer is busy forever. Status bar  shows "Transferring data" forver.
This should be networking, most likely.
Assignee: rods → neeti
Component: Form Submission → Networking
QA Contact: vladimire → tever

Updated

17 years ago
Blocks: 74451
Target Milestone: --- → mozilla0.9.1

Comment 2

17 years ago
I find that this finally finishes loading but it takes about a couple of 
minutes. If I turn off Keep Alive in Preferences > Debug > Networking then this 
page finishes loading fast.

Darin: bug 70531 had the same problem but it was resolved by the checkin for bug 
72348.

Comment 3

17 years ago
We are getting an error reading socket.

817[14aa490]: nsSocketTransport: Entering Process() [host=bubblegum:80 
this=4b59f30], aSelectFlags=1, CurrentState=5.
817[14aa490]: nsSocketTransport: Transport [host=bubblegum:80 this=4b59f30] is 
in WaitReadWrite state [readtype=1 writetype=0 status=80470007].
817[14aa490]: nsSocketTransport: doReadWrite [this=4b59f30, aSelectFlags=1, 
mReadRequest=3fbe5c0, mWriteRequest=0
817[14aa490]: nsSocketReadRequest: [this=3fbe5c0] inside OnRead.
817[14aa490]: nsSocketReadRequest: [this=3fbe5c0] calling listener [offset=298, 
count=8192]
817[14aa490]: nsSocketIS: PR_Read(count=3798) returned -1
817[14aa490]: nsSocketIS: PR_Read() failed [error=ffffe8b7, os_error=2746]
817[14aa490]: nsSocketReadRequest: [this=3fbe5c0 rv=80004005] error reading 
socket.
817[14aa490]: nsSocketTransport: Transport [host=bubblegum:80 this=4b59f30] is 
in Error state.
817[14aa490]: nsSocketTransport: Transport [host=bubblegum:80 this=4b59f30] is 
in Done state.
817[14aa490]: nsSocketTransport: CompleteAsyncRead [this=4b59f30]
817[14aa490]: nsSocketTransport::CloseConnection [this=4b59f30] Calling PR_Close
817[14aa490]: nsSocketTransport: Leaving Process() [host=bubblegum:80 
this=4b59f30], mStatus = 80004005, CurrentState=3, mSelectFlags=4

0[952bf0]: nsSocketTransport: Deleting [bubblegum:80 4b59f30], TotalCreated=1, 
TotalDeleted=1

Comment 4

17 years ago
neeti: can you find out what that error means?

Comment 5

17 years ago
In nsSocketReadRequest::OnRead(..) When we call 

rv = mListener->OnDataAvailable(this,
                                    mContext,
                                    mInputStream,
                                    offset,
                                    amount);

we are getting an error in nsStreamListenerProxy::OnDataAvailable(..)
at rv = mPipeOut->WriteFrom(..).

Investigating..

Comment 6

17 years ago
Darin: We are getting an error in nsPipe::nsPipeOutputStream::WriteSegments(..) 
in xpcom\io\nsPipe2.cpp.

This error is not a NS_BASE_STREAM_WOULD_BLOCK or NS_BASE_STREAM_CLOSE.

Comment 7

17 years ago
We get this error only when Keep Alive is on.
(Reporter)

Comment 8

17 years ago
Neeti,
As per our talk I just investigated this one & I think I found the exact line of 
code in CGI which causing this to happen.

Now if you try testcase at 
http://bubblegum/desale/valtest2.html

it works fine. Original testcase at http://bubblegum/desale/valtest.html & this 
second one are exactly same.

Valtest.html submits form to foo1.cgi
Valtest2.html submits form to foo2.cgi

foo1.cgi & foo2.cgi are exactly same but only one difference.
& difference is that line "print "Content-type: text/html", "\n\n";"
is commented in foo2.cgi, so that line of code is not being used.

Without that line, everything works fine. With that line, it fails.

Check out.

Let me know if I can provide more info on this.
(Reporter)

Comment 9

17 years ago
Pasting Both CGI's. ONe working & other non-working.

1] CGI That works fine:
********************************************************************************
#!/usr/local/bin/perl
require "cgi-lib.pl";
#print "Content-type: text/html", "\n\n";
MAIN:
{

&ReadParse(*input);
$resultsdir = "results";
$textval = $input{'temptext'};
$selval = $input{'tempsel'};

print "<HTML>\n";
print "<HEAD>\n";
print "<TITLE>CGI Test</TITLE>\n";
print "</HEAD>\n";
print "<BODY>\n";
print "<H2>Text Box Value is:    $textval</H2><br>\n";
print "<H2>Select Value is:    $selval</H2><br>\n";
print "</BODY>\n";
print "</HTML>\n";
}
exit(0);
********************************************************************************


2] CGI that doesn't work properly. [Response from server never ends.]
********************************************************************************
#!/usr/local/bin/perl
require "cgi-lib.pl";
print "Content-type: text/html", "\n\n";
MAIN:
{

&ReadParse(*input);
$resultsdir = "results";
$textval = $input{'temptext'};
$selval = $input{'tempsel'};

print "<HTML>\n";
print "<HEAD>\n";
print "<TITLE>CGI Test</TITLE>\n";
print "</HEAD>\n";
print "<BODY>\n";
print "<H2>Text Box Value is:    $textval</H2><br>\n";
print "<H2>Select Value is:    $selval</H2><br>\n";
print "</BODY>\n";
print "</HTML>\n";
}
exit(0);
********************************************************************************


So you can see that the line "print "Content-type: text/html", "\n\n";" is 
causing this failure.
(Reporter)

Comment 10

17 years ago
There is one more new thing, 
if we use everything according to http header specifications & use code which 
includes 
print "HTTP/1.1 200 OK";
print "Content-type: text/html\n\n";

So we added line [print "HTTP/1.1 200 OK";] before 
[print "Content-type: text/html\n\n";] then everything works fine.
I talked to Gagan, & according to him specs say that it is required to have 
[print "HTTP/1.1 200 OK";] before  [print "Content-type: text/html\n\n";] but 
not using that should not cause failure either. There could be lots of CGI's out 
there which ignore first line & directly specify content-type.

So one more working cig is as following.

#!/usr/local/bin/perl
require "cgi-lib.pl";
print "HTTP/1.1 200 OK";
print "Content-type: text/html\n\n";
MAIN:
{

&ReadParse(*input);
$resultsdir = "results";
$textval = $input{'temptext'};
$selval = $input{'tempsel'};

print "<HTML>\n";
print "<HEAD>\n";
print "<TITLE>CGI Test</TITLE>\n";
print "</HEAD>\n";
print "<BODY>\n";
print "<H2>Text Box Value is:    $textval</H2><br>\n";
print "<H2>Select Value is:    $selval</H2><br>\n";
print "</BODY>\n";
print "</HTML>\n";
}
exit(0);


But all this is causing much increased response time too. Which could be another 
bug & I'll file another bug for that.


Comment 11

17 years ago
\n\n should be \r\n ... try this correction and see if it then works.

Comment 12

17 years ago
neeti, when you get a chance, can you verify if this is still a problem?  :-)

Comment 13

17 years ago
> There is one more new thing, if we use everything according to http header
> specifications & use code which includes 
> print "HTTP/1.1 200 OK";
> print "Content-type: text/html\n\n";
>
> So we added line [print "HTTP/1.1 200 OK";] before 
> [print "Content-type: text/html\n\n";] then everything works fine.

Your web server should supply the status line (HTTP/1.1 200 OK) for you. It
appears that it also supplies a text/html Content-type if you don't specify it.
I don't use perl for my CGIs, so I don't know what perl outputs when you use the
comma. Could it be spitting out a tab that Mozilla isn't handling correctly?

> \n\n should be \r\n ... try this correction and see if it then works.

Actually, it should be "\r\n\r\n", one CRLF pair to end the header, and one to
separate it from the body.


(Reporter)

Comment 14

17 years ago
We tried "\r\n" & "\r\n\r\n" both but that doesn't help.

Using only one"\n" instead of two "\n\n" fixes the problem. Using this way fixes 
problem discussed in this current bug, but it still causes problem discussed in 
bug# 77978.
(Reporter)

Comment 15

17 years ago
Turning off "Keep Alive" from preferences under "debug"-"Networking".
Fixes both problems discussed in this current bug & problem discussed in bug# 
77978.

Comment 16

17 years ago
both scripts work fine on my linux 2001-04-26 build running from an apache web
server.  my web server didn't have cgi-lib.pl installed, so i did have to 
comment the related lines out... but, i don't see how this could be causing
the problem.  perhaps there is something going on with bubblegum?

reporter: can you please try this script from another web server.
(Reporter)

Comment 17

17 years ago
Darin, could you please send me addresses for these testcases on your apache web 
server ? You tried this on Linux. I don't know if it happens on Linux. I just 
want to try those from my machine. 
I have other web-server but perl is not installed on that one.

cgi-lib.pl is not playing any role in this, so commenting that wouldn't cause 
any difference.


Comment 18

17 years ago
Need help testing this cgi script on a webserver other than bubblegum.
Keywords: nsbeta1, qawanted
(Assignee)

Comment 19

17 years ago
->taking over
Assignee: neeti → gagan

Comment 20

17 years ago
from mtg w/gagan: move target milestone to 0.9.2.  If after investigation, he
finds it's not a cgi coding issue, will move back to 0.9.1 time permitting.
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 21

17 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc
(Assignee)

Updated

17 years ago
Priority: -- → P4
(Assignee)

Comment 22

17 years ago
off to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 23

17 years ago
Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 24

17 years ago
I'm confused...

From the bug comments this is *clearly* a broken CGI script.  The reason that
the CGI works if *no* headers are sent is because necko 'assumes' that it is a
HTTP/0.9 response...  so it continues fine...

When the 'Content-Type' header is sent, the CGI is violating the HTTP 1.0/1.1
spec which *requires* a HTTP Status-Line to be sent *before* anything else.

Again, the page loads when the CGI includes the proper HTTP Status-Line along
with the 'Content-Type' header...

Is the *real* bug that we are tracking, the fact that when the header is sent
without a HTTP Status-Line rather than treating the bogus header as part of the
'body' on a HTTP/0.9 response we seem to hang?

If this is the case, can we update the summary to better reflect what's actually
going on :-)

-- rick
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Comment 25

16 years ago
confirming rick's findings and marking this invalid. Thanks rick.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID

Updated

15 years ago
Component: Networking → Networking: HTTP
QA Contact: benc → tever

Comment 26

15 years ago
Verified invalid.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.