I wrote an Apache filter with mod_python. It's an outputfilter, so it works on the page that's being returned by Apache to the client. Whatever the filter does on the page, even simply returning the page unchanged, raises an error in Chrome that you can see in the debugger as a GET request with "(failed)" status:
In Firefox and IE it works correctly.
It seems that the problem is related to the fact that the value declared in the Content-Length header is different from the actual length of the content returned to the client. My VirtualHost configuration enables data compression with the line:
AddOutputFilterByType DEFLATE text/html text/plain text/xml ...
The solution to the problem is to disable data compression for the files on which the filter is active. In my case it's only for index.html, so it's a matter of adding a SetEnv instruction in the index.html configuration:
PythonPath "sys.path+['/srv/testhandler/cgi-bin']"
PythonOutputFilter testhandler::test_filter TESTFILTER
<Files "index.html">
SetEnv no-gzip dont-vary
SetOutputFilter TESTFILTER
</Files>
In Firefox and IE it works correctly.
It seems that the problem is related to the fact that the value declared in the Content-Length header is different from the actual length of the content returned to the client. My VirtualHost configuration enables data compression with the line:
AddOutputFilterByType DEFLATE text/html text/plain text/xml ...
The solution to the problem is to disable data compression for the files on which the filter is active. In my case it's only for index.html, so it's a matter of adding a SetEnv instruction in the index.html configuration:
PythonPath "sys.path+['/srv/testhandler/cgi-bin']"
PythonOutputFilter testhandler::test_filter TESTFILTER
<Files "index.html">
SetEnv no-gzip dont-vary
SetOutputFilter TESTFILTER
</Files>
Still I don't understand why in this case the Content-Length header value is not handled correctly by Apache; maybe it's because the order in which filters are applied is not correct, even if printing the page content from my filter to a log file shows that the filter receives a page not compressed, so apparently it is applied before the DEFLATE filter.
Comments
Post a Comment