httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: [PATCH] If-None-Match requests always return 304 with FileETag None directive
Date Sun, 01 Sep 2002 18:54:17 GMT
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

Mime
View raw message