You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/07/12 23:06:04 UTC
bug - c2 is caching too aggressively!
okay, that's a bad way to state this, but hear me out. c2 is setting the
HTTP response code 304, SC_NOT_MODIFIED, too aggressively. that is to say,
it appears that clients who do not have a copy of the resource cached are
erroneously receiving the 304 response code. a grep of my access_log
reveals:
66.45.6.30 - balld [12/Jul/2001:16:48:55 -0400] "GET
/database/resources/default.css HTTP/1.1" 304 0
"https://intranet.webslingerZ.com/database/tables/employee_client_table/edit/form?employee_id=8"
"Mozilla/5.0 (compatible; Konqueror/2.1.2; X11)"
66.45.6.30 - balld [12/Jul/2001:16:50:10 -0400] "GET
/database/resources/default.css HTTP/1.0" 304 0 "-" "Mozilla/4.77
(Macintosh; U; PPC)"
the first line is from me browsing my site using konqueror. i should be
getting code 304 in this case - konqueror already has the resource cached.
the second line is from me browsing the site using a fresh netscape
instance on a nearby mac with a cleared cache. i should not be getting
code 304 in this case, afaik. has anyone else experienced this behavior?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: bug - c2 is caching too aggressively!
Posted by giacomo <gi...@apache.org>.
On Sun, 15 Jul 2001, Donald Ball wrote:
> On Sun, 15 Jul 2001, giacomo wrote:
>
> > To be honest, the code base has grown very quickly the last few month.
> > I thought that the 304 was only produced by the ResourceReader so far
> > but it seems that other parts of the code will produce 304 as well.
> > Actually I don't know which part is also producing 304 but a find/grep
> > should uncover those parts.
>
> they're ultimately being generated by the stream pipeline components now,
> actually, in the the processReader method. anyway, as it turns out, the
> bug was not in c2 at all but rather caucho resin's cache engine. it's
> adding an if-modified-since header to the request and erroneously shooting
> off a 304 to apparantly all clients, regardless of if they sent an
> if-mofified-since header or not. turning off caucho's cache fixes the
> problem and is probably a good idea anyway since c2's cache is more
> sophisticated.
Cool to hear that.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: bug - c2 is caching too aggressively!
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 15 Jul 2001, giacomo wrote:
> To be honest, the code base has grown very quickly the last few month.
> I thought that the 304 was only produced by the ResourceReader so far
> but it seems that other parts of the code will produce 304 as well.
> Actually I don't know which part is also producing 304 but a find/grep
> should uncover those parts.
they're ultimately being generated by the stream pipeline components now,
actually, in the the processReader method. anyway, as it turns out, the
bug was not in c2 at all but rather caucho resin's cache engine. it's
adding an if-modified-since header to the request and erroneously shooting
off a 304 to apparantly all clients, regardless of if they sent an
if-mofified-since header or not. turning off caucho's cache fixes the
problem and is probably a good idea anyway since c2's cache is more
sophisticated.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: bug - c2 is caching too aggressively!
Posted by giacomo <gi...@apache.org>.
On Sat, 14 Jul 2001, Donald Ball wrote:
> On Sat, 14 Jul 2001, giacomo wrote:
>
> > The 304 code should only be set if there was a is-modified-since header
> > presented from the client (browser).
> >
> > Everything else is nonsens.
>
> that's what i thought too, and the code seems to back us up, but my
> _experience_ has been different. i was hoping to see if anyone else shared
> the same _experience_. this isn't _nonsense_, i'm trying to track down a
> bug.
To be honest, the code base has grown very quickly the last few month.
I thought that the 304 was only produced by the ResourceReader so far
but it seems that other parts of the code will produce 304 as well.
Actually I don't know which part is also producing 304 but a find/grep
should uncover those parts.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: bug - c2 is caching too aggressively!
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sat, 14 Jul 2001, giacomo wrote:
> The 304 code should only be set if there was a is-modified-since header
> presented from the client (browser).
>
> Everything else is nonsens.
that's what i thought too, and the code seems to back us up, but my
_experience_ has been different. i was hoping to see if anyone else shared
the same _experience_. this isn't _nonsense_, i'm trying to track down a
bug.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: bug - c2 is caching too aggressively!
Posted by giacomo <gi...@apache.org>.
On Thu, 12 Jul 2001, Donald Ball wrote:
> okay, that's a bad way to state this, but hear me out. c2 is setting the
> HTTP response code 304, SC_NOT_MODIFIED, too aggressively. that is to say,
> it appears that clients who do not have a copy of the resource cached are
> erroneously receiving the 304 response code. a grep of my access_log
> reveals:
>
> 66.45.6.30 - balld [12/Jul/2001:16:48:55 -0400] "GET
> /database/resources/default.css HTTP/1.1" 304 0
> "https://intranet.webslingerZ.com/database/tables/employee_client_table/edit/form?employee_id=8"
> "Mozilla/5.0 (compatible; Konqueror/2.1.2; X11)"
> 66.45.6.30 - balld [12/Jul/2001:16:50:10 -0400] "GET
> /database/resources/default.css HTTP/1.0" 304 0 "-" "Mozilla/4.77
> (Macintosh; U; PPC)"
>
> the first line is from me browsing my site using konqueror. i should be
> getting code 304 in this case - konqueror already has the resource cached.
> the second line is from me browsing the site using a fresh netscape
> instance on a nearby mac with a cleared cache. i should not be getting
> code 304 in this case, afaik. has anyone else experienced this behavior?
The 304 code should only be set if there was a is-modified-since header
presented from the client (browser).
Everything else is nonsens.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org