Closed Bug 75637 Opened 23 years ago Closed 23 years ago

Response from CGI never ends.

Categories

(Core :: Networking: HTTP, defect, P4)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED INVALID
Milestone:
mozilla0.9.5

People

(Reporter: desale, Assigned: gagan)

References

(
URL
)

Details

(Keywords: qawanted) 

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
Blocks: 74451
Target Milestone: --- → mozilla0.9.1
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.
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

neeti: can you find out what that error means?
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..
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.


We get this error only when Keep Alive is on.
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.
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.
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.



\n\n should be \r\n ... try this correction and see if it then works.
neeti, when you get a chance, can you verify if this is still a problem?  :-)
> 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.



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.

Turning off "Keep Alive" from preferences under "debug"-"Networking".
Fixes both problems discussed in this current bug & problem discussed in bug# 
77978.
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.
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.



Need help testing this cgi script on a webserver other than bubblegum.
Keywords: nsbeta1, qawanted
->taking over
Assignee: neeti → gagan
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
mass move, v2.
qa to me.
QA Contact: tever → benc
Priority: -- → P4
off to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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
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
Target Milestone: mozilla0.9.4 → mozilla0.9.5
confirming rick's findings and marking this invalid. Thanks rick.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Component: Networking → Networking: HTTP
QA Contact: benc → tever
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.