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/