durusmail: quixote-users: Overlaying a static directory
Overlaying a static directory
2005-04-11
2005-04-12
2005-04-12
2005-04-12
2005-04-13
2005-04-13
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
David Binger (3 parts)
2005-04-14
2005-04-14
2005-04-13
2005-04-14
2005-04-14
2005-04-13
SCGI util.
2005-04-12
2005-04-13
2005-04-13
2005-04-13
2005-04-13
Overlaying a static directory
R J Ladyman
2005-04-13
I had a similar problem with the same setup (Apache2 / SCGI / Linux) and
solved it by setting  max_children to 1 in the SCGI config file (with advice
from this list).


> 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 

--

Robert Ladyman
Tel: +44 (0) 7732 771 649
Skype: rjlfile-away
http://www.file-away.co.uk

Sent to you via the Magach Wireless Network
http://www.file-away.co.uk/rlan.htm


reply