httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: Wrong etag sent with mod_deflate
Date Sun, 10 Dec 2006 15:42:14 GMT
On 12/10/06, Roy T. Fielding <fielding@gbiv.com> wrote:
> No, you assume a broken implementation of ap_meets_conditions.
> If the function is implemented correctly, it still treats each etag
> as opaque.  Given an etag of "X", the deflate variant will be "X-gzip".
> If the content generator generates "10//foo-gzip", then the deflate
> filtered variant will use "10//foo-gzip-gzip".  The result is correct
> and no butt-ugly hacks are needed.  The same can be done for any
> content-changing filter, and the result will work as specified as
> long as the ordering of filters is consistent (and even if it isn't,
> the result remains correct with a slight inefficiency).
>
> The hard part is to fix ap_meet_conditions and/or the metadata
> generating aspect of 2.x filters, which may not even be possible
> without an API rewrite.  I am not asking anyone to accept partial
> solutions -- it is simply a bug that needs to be fixed, and I see no
> reason to assume that we can't fix it right.  Just give me some time
> to get trunk working on OS X again and remember how to code in C.

Thank you.

Right now, my intuition leads me to believe that to fix it properly
would indeed require rewriting our entire filter API.  At that point,
the floodgates open and let's just do 3.0 from scratch.  =)

My spidey sense says that if we were to follow the bucket design from
serf, there'd be a way out of this.  But, I'm not seeing how to do
that within the constraints of httpd's current design.  -- justin

Mime
View raw message