>> imagine a simple CGI-script: >> >> >> #!/usr/bin/perl >> print "Content-Encoding: identity\n"; >> print "Content-Type: text/plain\n"; >> print "\n"; >> print "test"; >> >> >> AFAIK, "identity" indicates, that no transformation is being done on the >> content. >> >> IMHO, mod_deflate should implement the following logic: >> >> Content-Encoding-header already present? >> yes: do nothing, just forward content >> no: add Content-Encoding header and do compression > > It's a valid behaviour. So's the current one.
Hmm, but at the moment, mod_deflate just adds another Content-Encoding-header, even if one is already present. That client gets two of them. Is that intended? On the other hand, mod_deflate doesn't need to recompress something, that is already compression (when indicated by Content-Encoding header). I don't think, that this cases are currently handled properly. (I can at least confirm the double Content-Encoding header using the CGI-script above) > Putting it under the control of the admin is a reasonable > proposition. mod_filter does that: you can conditionally > insert mod_deflate. I'm trying to understand that mod_filter, but can i also insert a filter if and only if the Content-Encoding-header is not already present in the response?
signature.asc
Description: OpenPGP digital signature
