On May 13, 9:11 pm, Graham Dumpleton <[email protected]> wrote: > Your analysis is correct. The Apache server process which proxies data > to the mod_wsgi daemon process closes that half of the socket > connection after it has been able to send all the request content. > This informs the mod_wsgi daemon process that there is no more request > content. This method is used because you cant rely on request content > length as Apache input filters can invalidate that and there may > actually be more or less data to process than content length defines. > Technically WSGI compliant applications can't handle that, but step > outside of WSGI and you can handle it with mod_wsgi. > > My separate questions were to determine if there was a delay > sending that data what cause may be, but was irrelevant any way as the > logs clearing showed the close happening promptly, which means that > web application did promptly read and store all the request content. > > As a result, the delay can only be occurring within the processing > done within the web application of that request data once it has been > read.
Ah, ok, thanks for the explanation. So this sounds like business-as- usual; I had assumed the shutdown meant end-of-response. Thanks for your help. Mark. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
