David Binger wrote:
> On Apr 11, 2005, at 9:34 PM, mso@oz.net wrote:
>
>>> Are you using Apache2 with mod_scgi?
>>
>> Yes. On Linux, if that matters.
>
> I don't think the Apache2 mod_scgi is reliable. Whenever I
> have tried it I have had similarly unexpected behavior.
> I bet this will work fine if you can change back to Apache1 or
> if you can get the cgi2scgi working.
>
>>
>>> Also, have you noticed the cgi2scgi program in mod_scgi? That seems
>>> like
>>> an attractive alternative, and it allows for handling several requests
>>> at a time.
>
>>
>> That immediately gives a "Premature end of script headers" in the
>> Apache
>> log with no further explanation, and no messages in the Quixote access
>> log
>
> Is the cgi2scgi executable executable? Did you compile it with
> the -DPORT=9999 flag if your scgi server is listening on port 9999?
> Is the scgi server running and listening on the port you expect?
> Is anything in the scgi server's log?
>
>> or error log. I also tried FastCGI, and that works once but then hangs
>> for further requests. But either of these also causes problems with my
>> URLs coz I'd need to use mod_rewrite to hide the /cgi-bin/app.cgi2scgi
>> or
>> ..fcg prefix, and then the redirects in my application put the
>> /cgi-bin...
>
> ScriptAlias "/" "/cgi-bin/app.cgi2scgi"
> can run everything to your applicaiton.
> I think it is possible to do this without mod_rewrite.
>
>> prefix back in because it's part of the script_name. Sigh. Would
>> anyone
>> feel like modifying scgi.c to dump the headers and part of the body to
>> a
>> file before passing them them to Apache? It looks like my only other
>> alternative is to go back to the old way with Basic Authentication.
OK, I did a bunch of more tests. The same problem happens with Apache
1.3.33 and mod_scgi 1. Pressing Reload or Shift-Reload on any page in a
StaticDirectory produces: (1) Internal Server Error, (2) the page without
images, (3) the page correctly. It keeps on cycling in approximately that
order.
If you reload a dynamic page, the dynamic HTML always comes up but any
dependent content (images, stylesheet) have a 50/50 chance of
disappearing. Sometimes the images and stylesheet disappear
alternatingly. (The dependent content are separate StaticFile instances
in this case.)
Whenever (1) or (2) happens, Apache2 logs:
[Tue Apr 12 17:02:12 2005] [error] [client 127.0.0.1] (304)Unknown error
304: scgi: Unknown error 304: error reading response headers
Apache1 logs almost the same thing:
[Tue Apr 12 17:01:53 2005] [error] [client 127.0.0.1] scgi: error reading
response headers
I modified the Publisher to log some information about the response.
=================================================
===> Response [28225] started 2005-04-12 17:11:08.783854
===> From 127.0.0.1
===> Request /sh-beta/static/index.html
===> Status 200 OK
{'last-modified': 'Wed, 13 Apr 2005 00:00:33 GMT'}
===> Body is 1456 bytes
===> Response [28225] finished 2005-04-12 17:11:08.784107
+++++++++++++++++++++++++++++++++++++++++++++++++
=================================================
===> Response [28225] started 2005-04-12 17:11:04.430176
===> From 127.0.0.1
===> Request /sh-beta/static/apache_pb.gif
===> Status 200 OK
{'last-modified': 'Tue, 02 Nov 2004 18:29:18 GMT'}
===> Content-type is image/gif
===> Response [28225] finished 2005-04-12 17:11:04.430502
+++++++++++++++++++++++++++++++++++++++++++++++++
I renamed .process_request to .process_request_shadowed and added the
attached .process_request, which calls it, logs some stats, and returns
the response.
The response output is always correct: HTML, image, stylesheet. I even
had it showing the beginning/end of the HTML, but took that out because it
was never wrong. So the problem is happening after that point. When the
error happens, Quixote returns status 200, but Apache rejects it and
generates a 500. No 304 is involved as far as I can tell. When Quixote
actually returns 304, it gets to the browser OK.
Just for fun I ran the Quixote demo instead of my SCGI application.
As-is, Reload worked fine (all dynamic content). Then I added a
StaticDirectory node to the demo. Those URLs exhibit the same error, both
with my big directory and with the default Apache directory.
I was able to get cgi2scgi to work with David's alias trick, although the
last argument is the filesystem path, not the URL path. But pressing
Reload here causes the other problem, the one FastCGI has: it takes
several seconds to render the object and sometimes it times out. This
happens only with Reload, not if you press Enter in the browser's address
box. (Testing on Firefox/Linux, server on same computer.)
When the delay happens, the Publisher takes its time before logging the
statistics I added. Usually the HTML item comes right away but the images
and stylesheet are delayed. Sometimes it times out and an image and/or
stylesheet entry doesn't appear at all. Sometimes the stylesheet entry
appears but the browser revokes the stylesheet anyway. But when an entry
does appear in the log, it always has the correct information.
I ran the SCGI server under strace to see why it's delaying. The delay
happens at a socket accept() call. I don't know a lot of C but it looks
like it has handled several requests by that time, maybe all of them. So
I don't know if the problem is in the SCGI server, mod_scgi[1-2], packets
coming too early or late, or what.
How does the SCGI server handle concurrency? mod_scgi uses multiple
processes, but there's only one server process. Does each request wait
till the previous one is done? Does that mean Apache's multiproces model
doesn't really solve anything because there's still a server bottleneck?
Could that be why I'm having problems with dependent images? But why
should StaticFiles be more affected?
There's another problem with all SCGI versions (1, 2, and cgi2scgi). If
the script_name specified to the SCGI server at launch does not match the
URL prefix actually requested, Apache says "premature end of script
headers" and the Quixote error log doesn't say a peep. That's with the
SCGI server running as a system service (launched from /etc/init.d). If
you run the SCGI server at the console, a traceback appears on the screen.
It's an unhelpful AssertionError, specifically this line in
Publisher.try_publish:
assert path[:1] == '/'
One would prefer a PublishError with a message saying "check script_name",
if that's possible. But since I've had this problem before I knew to
check script_name, and that cleared it up. I guess this problem happens
before Quixote's logs are set up or something, because this error dumps to
the screen whereas all other Quixote errors and print statements go to the
Quixote error log as expected.
I've got some "C" expertise recruited so I'll see if I can add logging to
mod_scgi.c and cgi2scgi.c . I may also make a cgi2scgi.py, or does one
already exist? It looks like the problems could also be in
quixote.server.scgi_server.QuixoteHandler or scgi.scti_server.SCGIHandler,
so I'm examining those too.
-- Mike Orr