hi all
this is something I've been meaning to do for a while. as mod_include
demonstrates, output filters will sometimes be required to remove the ETag
header generated by content handlers, depending on how much they alter the
content. the current methodology is to set a "no-etag" note, which is
I just have a quick comment based on some work I did recently.
You should check for the ETag value in both headers_out locations.
It is actually a bit more likely that the ETag will be in r->err_headers_out
rather than r->headers_out, but it could be in either. Your patch should
look in both locati
Paul J. Reder wrote:
> I just have a quick comment based on some work I did recently.
> You should check for the ETag value in both headers_out locations.
> It is actually a bit more likely that the ETag will be in
> r->err_headers_out
> rather than r->headers_out, but it could be in either.
hm
> thanks for your input - new patch attached.
bah, that's not right either. I'll refactor it again and fix some of the
messed up logic over the weekend. sorry to waste the bandwidth.
--Geoff
Just a quick tangent on weak ETags
let's say I have a transform to convert (charset-any) into utf-8 format...
and based on a browser string, conditionally insert that filter.
It's a straightforward (predictable) transform so that it retains any strong
ETag, but it isn't the identity. Wouldn'
William A. Rowe, Jr. wrote:
> Just a quick tangent on weak ETags
>
> let's say I have a transform to convert (charset-any) into utf-8 format...
> and based on a browser string, conditionally insert that filter.
>
> It's a straightforward (predictable) transform so that it retains any strong
hi again...
ok, I think I've worked out all the issues - attached is a new patch with
logic (and spelling :) errors hopefully worked out. also included is a
patch against the perl-framework for testing if you so choose.
one of the issues that needed working out was dealing with multiple ETag
hea
one of the issues that needed working out was dealing with multiple
ETag
headers. my original idea was to have ap_weaken_etag guarantee that
ETag
headers would be weak. with ETag headers entering err_headers_out via
a
third party, there exists the possibility that the server would send
multipl
RFC 2616, section 3.11, BNF does not allow multiple ETag header fields.
^
^14.19 + 3.11
Roy
Roy T. Fielding wrote:
>> one of the issues that needed working out was dealing with multiple ETag
>> headers. my original idea was to have ap_weaken_etag guarantee that ETag
>> headers would be weak. with ETag headers entering err_headers_out via a
>> third party, there exists the possibility
BTW, an entity tag does not identify the entity -- it merely
acts as a key for cache and range request handling.
right. and what I was trying to do was make it possible for
content-altering filters to handle that key a bit more intelligently
than
just removing it altogether. the situation I init
11 matches
Mail list logo
