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 is
>> false.
>
> 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
    | http://www.emdash.co.uk/
    | http://www.reprocessed.org/