httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Content-Encoding and Filters
Date Mon, 06 Aug 2007 20:10:40 GMT
PRs 23287 and 42993, and recent discussion here, show up some
issues with handling Content-Encoding.  Specifically regarding
mod_deflate, but also relevant to any other filters that
affect or are affected by Content-Encoding.

The root of the problem is that the handling of Content-Encoding
is scattered over too many places:

(1) mod_proxy gets the response header from the backend
(2) mod_mime sets r->content_encoding instead (PR 42993)
(3) CGI and mod_asis set it with other script headers in

Case (1) is fine.

Case (2) requires us to accept content-encoding from more than
one potential place.  But just merging them is wrong: if both
are set, they're in competition, and mod_mime's settings are
quite likely to be inherited from a default.  So I think the
correct fix here is to look at r->content_encoding if and only
if there is no Content-Encoding header.  This should really
be fixed in util_filter, rather than fixing mod_deflate and
then potentially duplicating it in other filters.

Case (3) means we *also* need to look in err_headers_out,
which complicates the issue further.  Which raises the
question: can we merge the tables immediately before passing
data down the filter chain?  As far as the handler is concerned,
it can't divert into an errordocument, because it's already
started sending the response.  So there's no longer a
need for two tables, right?

Outline proposal: we look to simplify the issue for mod_deflate
and other output filters by merging headers at the point
where the first data are passed into the output chain.

Looking to 2.4, any strong reason we shouldn't dispense with
r->content_encoding and let mod_mime & friends set the header?

Nick Kew

Application Development with Apache - the Apache Modules Book

View raw message