Hi Toby,
thank you very much for your hints. Since we have a tapestry-only
application, i added a request filter that sends the cache control
headers (expires, pragma, cacha-control, last-change etc.).
I used your settings with no success so far.
But I finally found a solution: I am appending a random string to all
urls with the tapestry url-rewriting machanism, so browsers can't cache
them. This is an ugly workaround since all urls look now cryptic, but it
works.
On our test-environment we have encountered similar problems with other
websites, so maybe this problem is not tapestry related at all but
occurs very often since the request-redirect-request mechanism is used
on every page. Maybe this is a browser-bug (strange thing is we have it
in firefox and customers report problems with IE 7).
If anybody has problems like this: Please report here.
Thanks
Felix
Toby Hobson schrieb:
I've had similar problems (caching in general). I was running a mixed
T5/Spring MVC app so in the end I wrote a filter which set the various http
headers and I then mapped certain requests to that filter. In the end I
found that I needed to set quite a few cache related headers to get things
working across all browsers:
<filter>
<filter-name>NoCacheFilter</filter-name>
<filter-class>com.thc.util.servlet.ResponseHeaderFilter</filter-class>
<init-param>
<param-name>cache-control</param-name>
<param-value>private,no-cache,no-store,must-revalidate,max-age=-1</param-value>
</init-param>
<init-param>
<param-name>pragma</param-name>
<param-value>no-cache,no-store</param-value>
</init-param>
<init-param>
<param-name>expires</param-name>
<param-value>-1</param-value>
</init-param>
</filter>
As you see I needed to set the cache-control, pragma and expires headers to
get it to play nicely
You might want to try something along those lines, of course if you have a
pure T5 app you could you a Tapestry filter instead of a standard servlet
filter as I did
2009/10/23 Felix Gonschorek <fe...@ggmedia.net>
Hi all,
we're experiencing a weird problem here with a live system (big b2b
enterprise shop frontend): Some users report that nothing happens when they
click on links.
We narrowed things down and found out that only component event links are
affacted that do not redirect to another page, for example:
Page is: "/productlist". The page contains a product listing with a pager -
users can navigate with the pager (switch pages, sort products)
When the user clicks on an pager event link to go for example to the second
page, the link looks like this: "/productlist.pager:gotopage/2".
The event handler sets the page number session variable to the value "2"
and returns null - the same page ("/productlist") should be rendered again -
but this time page two of the paged product list should be rendered.
On most browsers and clients this works, but as mentioned: Some browsers do
not follow the header "Location" - i can see it in the logfiles on the
server. The PageRendering request ("header: Location") is not executed and
the client loads the page from the browser cache - and page 1 of the paged
products is displayed. So the users experience that "nothing happens".
We heard from users using internet explorer 7 on the live system (tomcat 6
behind apache with mod_jk) experiencing this problem and we could reproduce
this with one system on our test environment (jetty 6, firefox 3.0.14) - the
browser does not follow the Location header. If we deactivate the browser
cache completely on firefox the problem does not occur.
Only thing special we have is a "X-Ua-Compatible" header to force internet
explorer 8 to be IE7 compatible. In the meanwhile we added the
"last-modified","expires","pragma" and "cache-control" header to modify the
browser cache behaviour, but so far with no success.
This are the server response headers for the component event request:
HTTP/1.x 302 Found
Location: http://localhost:8080/drw/en/productlist/$N
Content-Length: 0
Server: Jetty(6.1.16)
This are the server response headers for the page render request:
HTTP/1.x 200 OK
Last-Modified: Fri, 23 Oct 2009 12:51:42 GMT
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Content-Type: text/html; charset=utf-8
X-Ua-Compatible: IE=EmulateIE7
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Transfer-Encoding: chunked
Server: Jetty(6.1.16)
Has anybody experienced similar problems? Does anybody have a hint how we
could force all browsers to do the page render request after the component
event request, even if we do not change the page? As the problem occured on
jetty and tomcat, firefox and internetexplorer we assume that some headers
are incorrect, but we don't know which.
Any help is much appreciated!
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
