On 4 Oct 2005, at 14:57, David Binger wrote:

> On Oct 4, 2005, at 9:29 AM, Matt Patterson wrote:
>
>> On 4 Oct 2005, at 14:09, David Binger 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!

I did that, disproved the hypothesis and found the culprit.

It was, thank goodness, my fault.

I'd written some code that sits on top of HTTPRequest to give me some
of the extra bits I wanted easily accessible. Principally, I wanted
the raw message body from the incoming request. I was working on an
xml+http Rest-based web service, so needed to easily get to the XML
messages.

I have some code that, once the gets the request object using
get_request, then promptly gets the CONTENT_LENGTH header and does
request.stdin.read(CONTENT_LENGTH). With a mime-type of text/xml this
works fine: HTTPRequest has ignored the message body during
_process_inputs(). If you get a content type of application/x-www-
urlencoded or multipart/form-data then Quixote consumes the message
body and my stupid code sits there waiting to read bytes that will
never come.

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)?

Matt

--
   Matt Patterson | Design & Code
    | http://www.emdash.co.uk/
    | http://www.reprocessed.org/