[mod_python] strange behaviour with compressed response

m.banaouas banaouas.medialog at wanadoo.fr
Wed Jan 3 04:33:27 EST 2007


In my real case, the response contain "dynamic" data built with database 
extracted rows.
So it's may be not the best thing to do (storing it first in a file).

 >       SetOutputFilter DEFLATE
Now, it works finally! even without this directive.

In fact the right question would be:
"what is the difference between req.write(bla) and return bla ?"

Firefox browser is certainly http-tolerant and can manage some 
"imperfect" http dialogs.
Of course, the problem I meet could be caused by bad implementation in 
MyHttpClient side.
But the same comp in the sames conditions fails when response is 
"written" and works fine when the response is "returned", bizare non ?
I would like to well understand the origin of this difference of 
behaviour, to avoid to meet it again in prod stage.
So I will "dive" deeply in apache documentation ...

special thanks for Graham Dumpleton and all his rich comments ...

Graham Dumpleton a écrit :
 > m.banaouas wrote ..
 >> hi,
 >> what is the difference between serving a file directly or by calling a
 >> script function?
 >> case 1: http://localhost/myfile.xml
 >> case 2: http://localhost/mydir/boo/getfile
 >> Must I do special call to apache api when compression is activated?
 >> With Firefox, every thing works fine in two cases.
 >> With a http client component I'm using in my developpements, both case
 >> 1
 >> and case 2 works fine if I don't ask for compressed data. If I do
 >> (Accept-Encoding: gzip), case 1 works fine but case 2 fails.
 > Your Apache configuration only enables the DEFLATE output filter for 
 > files in your htdocs directory, it doesn't enable it for anything 
under mydir
 > so unless DEFLATE is being enable somehow elsewhere in the Apache 
 > the output of your published functions would never be compressed.
 > See other notes further done mixed in with your code and configuration.
 >> I noticed that returning apache.OK adds unexpected extra "0" on the 
 > Which would be what one expects as functions published using
 > mod_python.publisher are not the same as basic mod_python handlers. 
When using
 > mod_python.publisher the result of the published function is 
converted to a
 > string and written back as response content. In a basic mod_python 
handler the
 > response is a status indicating success of otherwise of the handler. 
Look at
 > the documentation again to see the difference.
 >> thanks.
 >> DocumentRoot "C:/Apache/htdocs"
 >> <Directory />
 >>     Options FollowSymLinks
 >>     AllowOverride None
 >>     Order deny,allow
 >>     Deny from all
 >>     Satisfy all
 >>     SetOutputFilter DEFLATE
 >> </Directory>
 >> Alias /mydir "C:/MYDIR"
 >> <Directory C:/MYDIR>
 >>     Allow from All
 >>     SetHandler mod_python
 >>     PythonHandler mod_python.publisher
 > Because this is a separate physical directory with distinct Directory
 > directive, you would also need here:
 >       SetOutputFilter DEFLATE
 > to have response from published functions be compressed.
 > Do take heed of the Apache documentation I pointed you to originally in
 > regard to DEFLATE module and a possible need to ensure you don't enable
 > it for some clients because of broken compressed data implementations
 > in those clients. Also, you shouldn't enable DEFLATE for all file 
types as files
 > such as images are usually already compressed and compressing them
 > again is a pointless exercise.
 > Another alternative with mod_python 3.3 is to actually make the judgement
 > within the published function as to whether for a specific response 
the output
 > should be compressed or not. To do this, before writing back any content
 > from the function, call:
 >     req.add_output_filter('DEFLATE')
 > This is the same as having using 'SetOutputFilter' in the Apache 

More information about the Mod_python mailing list