On 4 Oct 2005, at 18:17, Matt Patterson wrote:
Is the scgi process stuck in HTTPRequest.process_inputs() during the delay? Is it that the read() call in the scgi process is blocked, waiting for the final bytes of the request, which never come (due to a bug somewhere)?I don't know. I'm going to dig out pdb and find out...If it were me, I'd just put prints with timestamps around the read () calls. If they blow by without much delay, you'll know right away that this theory isfalse.Cool. Thanks David!
[snip]
I've altered my code to check the content-type before it does anything daft now, but is there any chance of a method on HTTPRequest to retrieve the message body (maybe that only returns in when request.form hasn't been populated)?
I've pressed ahead a bit with this, and the patch below is to allow you to be able to subclass http_request.HTTPRequest and have that new class be used by the publisher.
It works by using a request_class keyword argument in Publisher.__init__ and providing a new Publisher.create_request (stdin, environ) method, which returns a request object (instance of request_class).
The patch also modifies all the server connection modules in server/.Basically, code which doesn't subclass the Publisher and just uses one of the server connection modules in server/ should run unaltered (my SCGI stuff does, haven't tested the other stuff).
Anything that subclasses Publisher will be fine if calls the Publisher __init__, and doesn't define its own create_request() method or _request_class instance var.
Being able to subclass and use my own Request pretty much allows me to solve all my problems, which is cool.
Matt -- Matt Patterson | Design & Code <matt at emdash co uk> | http://www.emdash.co.uk/ <matt at reprocessed org> | http://www.reprocessed.org/
q_request_mods.patch
Description: Binary data
_______________________________________________ Quixote-users mailing list [email protected] http://mail.mems-exchange.org/mailman/listinfo/quixote-users
