httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject [patch] mod_include and ETag
Date Thu, 24 Apr 2003 18:06:27 GMT
hi all...

   I think mod_include has an ETag bug when activated using XBitHack Full. 
consider the following series of requests when XBitHack is activated for 
DocumentRoot (uninteresting headers snipped for brevity)

GET /ssi.html HTTP/1.1

HTTP/1.1 200 OK
Last-Modified: Thu, 24 Apr 2003 16:50:50 GMT


GET /ssi.html HTTP/1.1
If-Modified-Since: Thu, 24 Apr 2003 16:50:50 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Thu, 24 Apr 2003 16:50:50 GMT
ETag: "35157-5f-4861ce80"

while mod_include removes the ETag header from the first request, 
default_handler generates an ETag on the subsequent 304, which is bad for 
the same reasons mod_include wanted to remove it in the first place.

the attached patch seems to be a better way for mod_include to handle ETag 
generation, but there might be issues there as well if other handlers want 
to unset the note.

as an aside, for certain content filters, it may be sufficient mark 
future-generated ETag as weak in filter_init rather than forcing its removal 
entirely - an API that allowed filter_init routines to either prevent or 
weaken ETags generated via ap_set_etag() would probably be a good thing. if 
such an API existed, filters (other than mod_include) would have more 
control when filtering content from default_handler: the filter itself may 
not have enough information to discern whether an ETag is in order, but if 
the filter produces semantically equivalent content then it could let 
anybody else generating an ETag know that the validator should be weak.

I had thought about hacking something together that added ETAG_WEAKEN as an 
etag_big and using that as a start, but I didn't want to put too much effort 
into it unless people thought it worthy.


View raw message