wicket is a framework for dynamic webpages, so 99% of the time you don't want to cache and you want to make sure that the browser does query again for the page. Also the none bookmarkable pages are like wicket:interface=xxxx and that xxx can be anything and 2 the same values could point to completely different things over multiply runs of the browser.
if you want caching you have to do it your self in Page.configureResponse() or in your Resources.configeResponse() In both default imp we do already some stuff for example Page is configured to not cache and a resource if it is cacheable will send 2 headers. Also we have special support for the head request: 'If-Modified-Since' johan On 7/17/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
http://www.infoq.com/articles/etags What is an "ETag"? The HTTP protocol specification defines an ETag as the "entity value for the requested variant" (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html - Section 14.19.) Another way of saying this is that the ETag is a token that can be associated with web resource. The web resource is typically a web page, but could also be a JSON or XML document. The server is solely responsible for figuring out what the token is and means, and transfers it to the client in the HTTP Response Header. The process looks like this: 1. Client requests a page (A). 2. Server sends back page A, plus an ETag for A. 3. Client renders the page then caches it, along with the ETag. 4. Client requests page A again, passing along the ETag it got back from the server the last time it made the request. 5. Server examines the ETag and determines that the page hasn't changed since last time the client requested it, so sends back a response of 304 (Not Modified) with an empty body. What you guys think about this? :) Is the wicket cache system "etagged" already? []'s!! -- Bruno Borges Summa Technologies Inc. www.summa-tech.com (11) 8565-7739 (11) 3055-2060 (48) 8404-1300
