> Justin wrote... > > No - this patch breaks conditional GETs which is what I'm against. > > See the problem here is that you have to teach ap_meets_conditions() > about this. An ETag of "1234-gzip" needs to also satisfy a > conditional request when the ETag when ap_meets_conditions() is run is > "1234". In other words, ap_meets_conditions() also needs to strip > "-gzip" if it is present before it does the ETag comparison. But, the > issue is that there is no real way for us to implement this without a > butt-ugly hack. > > However, I disagree with Roy in that we most certainly *do* treat the > ETag values as opaque - Subversion has its own ETag values - Roy's > position only works if you assume the core is assigning the ETag value > which has a set format - not a third-party module. IMO, any valid > solution that we deploy must work *independently* of what any module > may set ETag to. It is perfectly valid for a 3rd-party module to > include "-gzip" at the end of their ETag.
...or "-bzip2". mod_bzip2 has been working fine for almost a year now and presents the same issue Justin is talking about here. It (can) generate it's own ETag values, if you want it to ( configurable ), and ap_meets_conditions isn't going to know what to "strip" or "not strip". Yours Kevin
