Re: How do you set cache-control for static (gif, jpg) resources

[Dennis Dai]

I've been reading this thread back and forth for quite a few times :)
My observations are tomcat does send response code 304 on static 
contents (.js, .jpg, .gif, etc.), so I don't know why you said "Tomcat 
always returns Cache-Control: no-cache with every response" at the very 
beginning of this thread. Well I haven't done any request dump to see if 
that's the case, but I do see lots of 304s in my access log (which, I 
assume, is not quite possible if it sets Cache-Control to no-cache with 
every response).

Speaking of cache, there was an onJava article about caching with 
filter, but that's mostly for caching dynamically generated pages, which 
may or may not be of interests to you guys:

http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html?page=3
Regards,
Dennis
On 7/30/2004 8:25 AM, Keith Bottner wrote:
It must be something particular about Tomcat, or some other weirdness with
my configuration. I will continue to look for the long term problem/solution
when I have more time.
Thanks again,
Keith
-----Original Message-----
From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 30, 2004 10:14 AM
To: Tomcat Users List
Subject: RE: How do you set cache-control for static (gif, jpg) resources


Hi,
No problem about the help ;)  Sadly enough, I know most of the Servlet Spec
by heart now. But more importantly, I have filters that do stuff on the
request side, check the response headers, and then add headers on the
response side, and they work just as the Spec says on every stable Tomcat
version I've used within the last couple of years.
Yoav Shapira
Millennium Research Informatics

-----Original Message-----
From: Keith Bottner [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 11:10 AM
To: 'Tomcat Users List'
Subject: RE: How do you set cache-control for static (gif, jpg)
resources
Actually I never got any IllegalStateExceptions. When I get some more
time
I
will have to step through the Tomcat code and find out why I get called 
twice since I should only be getting called once.

BTW, the 2.4 Servlet spec supports your analysis. It says the steps are 
(specifically step4-5):

Step 1: The method examines the request's headers.
Step 2: The method may wrap the request object with a customized 
implementation of ServletRequest or HttpServletRequest in order to 
modify request headers or data.

Step 3: The method may wrap the response object passed in to its
doFilter
method with a customized implementation of ServletResponse or 
HttpServletResponse to modify response headers or data.

Step 4: The filter may invoke the next entity in the filter chain. The
next
entity may be another filter, or if the filter making the invocation is
the
last
filter configured in the deployment descriptor for this chain, the next 
entity is the target Web resource. The invocation of the next entity is
effected
by
calling the doFilter method on the FilterChain object, and passing in
the
request and response with which it was called or passing in wrapped 
versions it may have created.

The filter chain's implementation of the doFilter method, provided by
the
container, must locate the next entity in the filter chain and invoke
its
doFilter method, passing in the appropriate request and response
objects.
Alternatively, the filter chain can block the request by not making the 
call to
invoke the next entity, leaving the filter responsible for filling out
the
response
object.
Step 5: After invocation of the next filter in the chain, the filter
may
examine response headers.
Step 6: Alternatively, the filter may have thrown an exception to
indicate
an error in processing. If the filter throws an UnavailableException
during
its doFilter processing, the container must not attempt continued 
processing down the filter chain. It may choose to retry the whole
chain at
a later time if the exception is not marked permanent.
Step 7: When the last filter in the chain has been invoked, the next
entity
accessed is the target servlet or resource at the end of the chain.
Step 8: Before a filter instance can be removed from service by the 
container, the container must first call the destroy method on the
filter
to
enable the filter to release any resources and perform other cleanup 
operations.

Thanks for all you help, I appreciate your time.
Keith
-----Original Message-----
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 9:55 AM
To: Tomcat Users List
Subject: RE: How do you set cache-control for static (gif, jpg)
resources

Hi,
Yeah, I saw his response, but you didn't mention IllegalStateExceptions
in
your log so I assumed the response being committed wasn't the problem
;)  Weird.
Yoav Shapira
Millennium Research Informatics

-----Original Message-----
From: Keith Bottner [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 10:45 AM
To: 'Tomcat Users List'
Subject: RE: How do you set cache-control for static (gif, jpg)
resources
RequestDumperValve dump's the request and the response.
So the request is first and the response follows the double dash line
for
that request.
Tim Funk though pointed out the problem.
"You probably can't set headers after doChain() because the response
was
committed."
See his entire message for more details. For now my filter works, I
will
just have to use setHeader instead of addHeader and be happy with it
being
called twice.
Keith
-----Original Message-----
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 9:28 AM
To: Tomcat Users List
Subject: RE: How do you set cache-control for static (gif, jpg)
resources

Hola,
How's the RequestDumperValve useful, if what you want to inspect are
the
response headers?  Unless you're sending the response to another
Tomcat
server and this is the RequestDumperValve's log from that second
server?
Yoav Shapira
Millennium Research Informatics

-----Original Message-----
From: Keith Bottner [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 9:59 AM
To: 'Tomcat Users List'
Subject: RE: How do you set cache-control for static (gif, jpg)
resources

Unfortunately HttpServletResponse has now way to query the headers
only
to
set them and determine if they exist. However I have the
RequestDumperValve
for both editions of the code. Here is the log for the 1st set of
code
(your suggestions).
: ---------------------------------------------------------------
:           authType=BASIC
:      contentLength=659
:        contentType=image/gif
:             header=Pragma=No-cache
:             header=Cache-Control=no-cache
:             header=Expires=Wed, 31 Dec 1969 18:00:00 CST
:             header=ETag=W/"659-1091194009140"
:             header=Last-Modified=Fri, 30 Jul 2004 13:26:49 GMT
:            message=null
:         remoteUser=username
:             status=200
:             scheme=http
:         serverName=localhost
:         serverPort=8080
:        servletPath=/common/inject/emp-ui-bg-con-tl.gif
:           isSecure=false
: ---------------------------------------------------------------
: ---------------------------------------------------------------
:           authType=BASIC
:      contentLength=7675
:        contentType=image/gif
:             header=Pragma=No-cache
:             header=Cache-Control=no-cache
:             header=Expires=Wed, 31 Dec 1969 18:00:00 CST
:             header=ETag=W/"7675-1091194009140"
:             header=Last-Modified=Fri, 30 Jul 2004 13:26:49 GMT
:            message=null
:         remoteUser=username
:             status=200
Above you can see that none of my changes to the response stream were
used.

Here is the headers for the 2nd set of code (the original)
: ---------------------------------------------------------------
: REQUEST URI       =/common/inject/emp-ui-bg-con-tl.gif
:           authType=BASIC
:  characterEncoding=null
:      contentLength=-1
:        contentType=null
:        contextPath=
:             cookie=JSESSIONIDSSO=47372C3C7BB03505C936A20970ACB1F9
:             cookie=JSESSIONID=B75E4FA2AA8047CCD40A885A0A84DFB5
:             header=accept=*/*
:             header=accept-language=en-us
:             header=accept-encoding=gzip, deflate
:             header=user-agent=Mozilla/4.0 (compatible; MSIE 6.0;
Windows
NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
:             header=host=localhost:8080
:             header=connection=Keep-Alive
:             header=authorization=Basic ZGhhbHBpbjpkaGFscGlu
:             locale=en_US
:             method=GET
:           pathInfo=null
:           protocol=HTTP/1.1
:        queryString=null
:         remoteAddr=127.0.0.1
:         remoteHost=127.0.0.1
:         remoteUser=username
: requestedSessionId=B75E4FA2AA8047CCD40A885A0A84DFB5
:             scheme=http
:         serverName=localhost
:         serverPort=8080
:        servletPath=/common/inject/emp-ui-bg-con-tl.gif
:           isSecure=false
: ---------------------------------------------------------------
: ---------------------------------------------------------------
:           authType=BASIC
:      contentLength=7675
:        contentType=image/gif
:             header=Pragma=No-cache
:             header=Cache-Control=no-cache
:             header=Cache-Control=max-age=1800
:             header=Expires=Wed, 31 Dec 1969 18:00:00 CST
:             header=Cache-Control=no-cache
:             header=Cache-Control=max-age=1800
:             header=ETag=W/"7675-1091159753343"
:             header=Last-Modified=Fri, 30 Jul 2004 03:55:53 GMT
:            message=null
:         remoteUser=username
:             status=200
Do you see the duplicate Cache-Control above? The first 
Cache-control=no-cache is the default then my addition then another
filter
adds the Expires and then both of the cache control lines are added
again.
Thanks for the performance tip, now if I can just get this!
I appreciate any help you can offer.
Keith
-----Original Message-----
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 8:40 AM
To: Tomcat Users List
Subject: RE: How do you set cache-control for static (gif, jpg)
resources

Hi,
Previously I was calling doChain at the end of my doFilter method.
Making the change you suggest, calling doChain at the top like
<snip />
DOES NOT INSERT any of my changes into the response stream. If I do
it
like
this:
<snip />
Then I get two additions in the response stream.
Any more ideas?
That's a bit strange.  Are you wrapping the response or setting these 
headers elsewhere?  Can you print out to the log a listing of all the 
response headers at the end of your filter?

The addHeader method allows for multiple values, but many readers
will
only
see the first.  So if something in your code sets the cache-control
header,
then you call it again, the header will be present twice with two
values
(which is legal in the HTTP protocol for most headers).
As an aside, you can read the enumeration of the init parameters in
the
filter's init method, store it in some member variable, and that will 
improve the performance of your filter because you won't have to do
it
on
every request.
Yoav Shapira

--
Dennis Dai
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]