Re: Conditional GET handling with filters.

[Cliff Woolley <jw...@virginia.edu>]

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.

--Cliff

Re: Conditional GET handling with filters.

[Justin Erenkrantz <je...@apache.org>]

On Thu, Jun 06, 2002 at 04:11:12PM -0700, Ryan Bloom wrote:
> 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.

Yup, the deflate case is especially bad.  So, we need to make the
decision before the handlers run.

> 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.

#1 is wrong because we're clearly violating the RFC on this.
#2 seems like r->no_local_copy is the right flag.

The problem seems to be where we can set this?  -- justin

P.S. rbb and I are in irc.openprojects.net #apr tossing around
some ideas about where we can stick this check.

RE: Conditional GET handling with filters.

[Ryan Bloom <rb...@covalent.net>]

> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> 
> 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

Re: Conditional GET handling with filters.

[Justin Erenkrantz <je...@apache.org>]

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

Re: Conditional GET handling with filters.

[Joshua Slive <jo...@slive.ca>]

On Thu, 6 Jun 2002, 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.

You may be right about the content-length (although that means the
content-length filter is buffering the whole request -- Ewww!).  But the
ETag certainly seems wrong, and responding with a 304 on If-Modified-Since
requests also seems wrong.  There is no way that we can know that the SSI
page is unmodified unless XBitHack is set to full.

Now, whether the problem is in the core, or is mod_include and php, I have
no idea.

Joshua.