2010/3/26 Joonas Lehtolahti <[email protected]>: > 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"?
The best I could do is to replace the AddOutputFilterByType in the main server with: FilterDeclare deflate-filter CONTENT_SET FilterProvider deflate-filter DEFLATE Content-Type /(text\x2Fplain|text\x2Fhtml)/ FilterChain deflate-filter Then at the vhost config you clean the chain in the directory you are using to serve the special file: <VirtualHost *:80> ServeName default WSGIScriptAlias /special /home/www/default/special/special.wsgi WSGIScriptAlias / /home/www/default/hello.wsgi <Directory /home/www/default> Order Allow,Deny Allow from All </Directory> <Directory /home/www/default/special> Order Allow,Deny Allow from All FilterChain ! </Directory> Now call http://localhost and the text/plain content will be served compressed and when you call http://localhost/special/xyz.txt it will be uncompressed. Notice that the filter provider configuration above will not negotiate content with not capable clients without a gzip/deflate in the Accept-Encoding Header. </VirtualHost> Regards, Clodoaldo > > 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. > > -- 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.
