On Fri, 26 Mar 2010 19:28:51 +0200, Deron Meranda <[email protected]> wrote:
> On Fri, Mar 26, 2010 at 12:18 PM, Joonas Lehtolahti <[email protected]> > wrote: >> Hey, I just tried an experiment about sending content from WSGI >> application that needs to wait for some time. >> >> Basically for starting the response the status is "200 OK" and headers >> [("Content-Type", "text/plain; encoding=utf-8")] >> >> For the actual data I returned the calling of this function that >> yields 7 kB of data every 10 seconds: > > ... > >> Now what I would have wanted the behavior be is that the first 7 kB >> block of "At 0 s" would be sent immediately to the client, then after >> 10 seconds the second block would be sent, and so on. What actually >> happens is any web browser waits for 100 seconds before there is *any >> response* from the server, then gets the whole document. >> >> I tried setting Content-Length explicitly in the headers, but that did >> not have any effect as the actual output to client was encoded with >> gzip and the real Content-Length header represented the compressed >> size. > > What is performing the compression? mod_gzip? or is it a WSGI > application (middleware)? > > You may also consider using mod_deflate rather than mod_gzip. > Deflate maps better as a transfer-encoding (gzip is really designed > for "files", not "streams"); and also you have more control over > things like buffer and window sizes. Seeing /etc/apache2/mods-enabled, it looks like it is mod_deflate doing the compression. >> Since PEP-0333 states that "WSGI servers, gateways, and >> middleware must not delay the transmission of any block; they must >> either fully transmit the block to the client, or guarantee that they >> will continue transmission even while the application is producing its >> next block." I trust that mod_wsgi itself conforms to this promise, so >> my suspect turns to the gzip procedure causing the output to be >> buffered instead of being sent to the client immediately when >> available. > > Try removing the compression, are there still any delays? Yes, without mod_deflate it seems to work as I want it to. deflate.conf has <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/ xml </IfModule> So it looks like it will always trigger itself if the user agent supports compression and the output data type is one of those text types, which is fine and preferable in most cases, but not for these special cases where it is expected that some data is available quickly but the rest of the data has to wait for a slow event to finish first. > First, simply try removing the compression filter and see if that > works. That is almost certainly your main issue. > > However, blocked-flushing of dynamic output like this is really the what > chunked transfer encoding and the HTTP 100 Continue responses are > for ... as a means of streaming and explicit blocking. > > I'm not sure how well mod_wsgi supports that though. Yep, it would be interesting to hear more about these possibilities. For now I believe I can configure mod_deflate to be generally used for text documents (I'll include application/xhtml+xml to the list too, it seems to be missing...) but to not use DEFLATE filter for these special files. I'm trying to find out how to prevent DEFLATE filter from triggering for these applications. So far with .htaccess and SetOutputFilter I did not have luck. RemoveOutputFilter takes file extensions as parameters... how would I tell it "files without extension"? But thanks for the reply, it's appreciated! -- 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.
