> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Thu, Jun 06, 2002 at 05:15:33PM -0400, Cliff Woolley wrote: > > On Thu, 6 Jun 2002, Joshua Slive wrote: > > > > > I got myself into a bug that is way over my head: > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673 > > > It seems that conditional GET (If-Modified-Since) is not working at > all > > > correctly with output filters. If someone wants to take a look, > please > > > have at it. > > > > I just posted some responses on that PR. Not sure about the ETag > > question, but all the rest seems like normal behavior to me. > > I think the ap_meets_conditions() call should be moved to the > ap_http_header_filter(). If the request then fails the > conditions, then the header filter can just pass the appropriate > code down. (If a module changes the content, it needs to remove > Last-Modified as mod_include does.) > > If a module would still like to check the conditions before > processing, they could, but I think that may not be a good > idea because of output filters. > > Note that PHP and mod_include could NEVER return 304. -- Justin
If you delay calling ap_meets_conditions, then you are going to slow down the server. Think about the easiest case, default_handler and mod_deflate. The default_handler grabs a file from the disk and sends it to mod_deflate, which compresses the data. Then, in ap_http_header_filter, we see that the data hasn't changed, so we send a Not-Modified-Since response. Now, we have wasted time compressing the response that was never actually sent. There are only two options in my mind for fixing this correctly. 1) A directive that essentially tells the server not to check for conditional GET requests in a given directory/file/location/whatever. 2) A flag someplace that modules can set to notify the core that it should skip the check. Just removing the ap_meets_conditions() call is the wrong solution. Ryan
