You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/02/05 10:19:25 UTC

Re: HTTP 304 Not Modified (fwd)

Found this on the resin list...

...we had problem with that, too. But I haven't
had the time to look into it yet. So we just
disabled the resin's proxy cache.

Anyone an idea? Is it resin's or is it cocoon's
fault?
--
Torsten

---------- Forwarded message ----------
Date: Mon, 04 Feb 2002 13:44:53 -0800
From: Scott Ferguson <fe...@caucho.com>
Reply-To: resin-interest@caucho.com
To: resin-interest@caucho.com
Subject: Re: HTTP 304 Not Modified

Max Kutny wrote:

>  TM> When I access GIFs through Cocoon, I get back the image the first
>  TM> time, but the second user accessing the same image doesn`t get it.
>  TM> The stderr.log shows that the image is cached the first time and the
>  TM> second client gets an HTTP 304 Not Modified.
>
>  TM> If you think that it is NOT a Resin bug but a Cocoon problem: is there
>  TM> a way to protocol the request headers to find out who is wrong?
>
> At first you may simply telnet on your httpd port and get desired GIFs by
> hand. It looks somthing like:
>
> thomas@somehost> telnet localhost 8080
> GET /images/broken.gif HTTP1.0
>
> And check what the actual response is.


Yep.

Although it's possible there's a Resin bug, the Cocoon people may just
be confused about what Resin's caching is doing.

Resin's cache is a real HTTP proxy cache.  Even if the client sends a
normal request, Resin's cache may still serve the page out of the cache.
  Resin's cache may need to ask the servlet if the page has changed.  To
do that, it sets the If-None-Match (and If-Modified-Since) headers and
sends that to the servlet.  The servlet may send back 304 Not Modified
to Resin's cache.  Resin's cache will then send the full, cached
response to the original client.  It will not send the 304 to the client.

So in this case, the cocoon servlet will not exactly know what the
client is receiving, and may log a 304 to stderr even though the client
is seeing a full 200 response.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org