tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Applying a servlet filter to a static resource
Date Thu, 11 Mar 2010 15:35:29 GMT
Caldarale, Charles R wrote:
>> From: Matt Veitas [mailto:mveitas@gmail.com]
>> Subject: Applying a servlet filter to a static resource
>>
>> I am using Tomcat 6.0.24 and am trying to use a servlet filter 
>> on a static resource and am having some troubles as the 2nd 
>> request returns a 304.
> 
> Are you sure it's Tomcat returning the 304, or is that being done by some intermediary?
> 
>> unfortunately I can't change the calling url.
> 
> What is the URL of interest?  Under what name is the webapp deployed?
> 
>> <filter-mapping>
>>    <filter-name>TestFilter</filter-name>
>>    <url-pattern>/js/config/my.json</url-pattern>
>> </filter-mapping>
> 
> The above should give the filter control, if the <url-pattern> is correct.
> 
>> Is there anything I can do to make Tomcat not return the 
>> 304 for the 2nd request to my.json?
> 
> The 304 is generated in Tomcat's DefaultServlet; your filter should be getting control
before that servlet is invoked, if it's configured properly and there's nothing between the
client and Tomcat that's caching the request.  Try verifying that the subsequent requests
are actually making it to Tomcat (enable the AccessLogValve in server.xml).
> 

What also helps a lot usually in such cases, is using a browser add-on 
such as HttpFox (Firefox) or Fiddler2 (IE), to see the exact sequence of 
HTTP requests/responses, and their associated HTTP headers.
For example, you would see there if it is really the server sending a 
304 (not modified), or the browser just serving the document from its 
own cache.
Or you would see if the response comes from Tomcat or from Apache httpd 
or IIS or some other proxy, if you have one of those in front of Tomcat 
(as seen from the browser end).

To the browser, the above URI "/(webappname)/js/config/my.json" 
certainly looks like a static resource, so it would not be surprising if 
it just cached it the first time, and served it from cache the second time.

I have not tested the following, and it is not based on any certain 
knowledge based on the HTTP RFCs, so treat with caution, but you could 
try a cheap trick :
In the link to that "document" in the html page, add a dummy query 
string, like :
instead of
http://servername/webappname/js/config/my.json
try
http://servername/webappname/js/config/my.json?a=my.json

The presence of the query string /might/ trick the browser in thinking 
that this is not a static page, and force it to re-request it from the 
server.

(And the reason for which I am adding the "=my.json" at the very end, is 
to get over a nasty habit of IE browsers, who try to "evaluate" the URL 
and guess themselves what the content might be based on the "extension", 
instead of believing what the server tells them in the Content-type header).



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message