On Fri, Aug 30, 2002 at 11:05:47PM -0700, Andrew Ho wrote: > Hello, > > You can find further details on the problem in the report I filed in Bug > 12202 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12202). The short > summary is that if FileETag is set to None, any HTTP request with an > If-None-Match header will result incorrectly in a 304 Not Modified > response from Apache 1.3.
Actually, FileETag None segfaulted for me because it was doing a strlen on an empty string and then trying to set the previous character to be NULL. So, I went in and fixed that too. What I did instead of what you submitted was that ap_set_etag() won't set the header to be "" - rather, it just won't set the header in this case. Oh, perhaps the docs lead you to believe step #5 would work, but the code certainly doesn't allow for that. If FileETag is set to None, we don't compute the ETag. Looking at the code, it seems that the original intention might have been to store the ETag in the header and then remove it later, but it doesn't do that - it never generates the ETag in the first place. So, I think we might want to do some refactoring of how FileETag works as I think returning "" instead of NULL in ap_make_etag() is not correct. If you'd like to take a shot at fixing that up to be cleaner, patches would be welcomed. What is in CVS for both repositories won't segfault and shouldn't produce invalid results. Thanks! -- justin
