LiteSpeed Support Forums - A couple of bugs

LiteSpeed Support Forums (http://www.litespeedtech.com/support/forum/index.php)

- Bug Reports (http://www.litespeedtech.com/support/forum/forumdisplay.php?f=9)

- - A couple of bugs (http://www.litespeedtech.com/support/forum/showthread.php?t=68)

A couple of bugs

Hi there,

Replacing our legacy Apache applications with LSWS 1.5.5 has been mostly successful, however;

The "Proxy" external application mode does not seem to work, unless the buffering option is set to "Yes"
The "Proxy" mode does not exhibit Apache-style tolerance of responses from HTTP servers that do not have a valid header (in this case, no header at all). Also, the operation never seemed to time out in this case with an error page, leaving the client browser spinning endlessly.

The application server for the legacy system is currently still an Apache mod_perl process - ie, we have just replaced the Apache reverse proxy component.

Thank you for your bug report.

Quote:

The "Proxy" external application mode does not seem to work, unless the buffering option is set to "Yes"

What is the symptom when buffering option is set to "no"? No output? Still buffer output? Currupted output? Can you please send us some debug log?
[UPDATE] this bug has been identified and fixed.

Quote:

The "Proxy" mode does not exhibit Apache-style tolerance of responses from HTTP servers that do not have a valid header (in this case, no header at all). Also, the operation never seemed to time out in this case with an error page, leaving the client browser spinning endlessly.

When you said "no header at all", do you mean that there is only a leading empty line to indicate the end of response header? or only the response status line followed by the empty line? I think Apache should add necessory header to the response to make it comply with HTTP protocol. Would you mind capturing an example response with "lynx -mime_header" and post it here?

Thank you very much!

Quote:

No header at all! I used `tcpflow' to capture the output and discovered this (tcpflow really is the bomb for debugging problems like this :-)). Yes, Apache should be making sure it is complying with the HTTP protocol, given that it is (supposedly) an HTTP server, not just a remote buffer overflow exploit server. This made me doubt the former claim.

Normally, with CGI output, without "non-parsed headers", any script response without a header has a default header added, as do headers without the "HTTP/x.y nnn ..." code. So, if you take a working CGI script:

Code:

#!perl

use CGI;

print "Hello, world!\n";

And run it under mod_perl, Apache never sends a header, unless you add:

Code:

#!perl

use CGI;

my $cgi = new CGI;

print $cgi->header, "Hello, world!\n";

In this case, the CGI.pm module detects it is running under mod_perl and appropriate hacks^H^H^H behaviour happens (the same as $cgi->header(-nph => 1)). HTTP/0.9 worked like this IIRC, so maybe web browsers tolerate the RFC violation.

In this case, I fixed the code that was missing the explicit header printout.

Whether to ignore the missing header, is a design decision - however the lack of eventual timeout would be nice to have fixed.

Hey I've almost got enough virtual hosts on my LSWS to put forward the case to buy a licence soon! :wink:

Should be fixed, please try release 1.5.6 :-)
LSWS did not handle your first code example well because it does not follow CGI spec, release 1.5.6 can tolerant it now. :)

Thanks for the tip on tcpflow, looks like a good alterntive to tcpdump. 8)