> From: Geoff Soutter
/snip/
> >* Don't implement getLastModified() explicitly
> >
> >* At the beginning of your doGet() method, define
> > the logic needed to determine whether the page
> > that this user has already cached is stale or not.
> >
> >* If it is not stale, do the following:
> > response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
> > return;
> > which is essentially what the HttpServlet.service() method
> > does for you if you do implement getLM.
> >
> >* If it is stale, or if the client does not have a current
> > copy of the page (i.e. no "If-Modified-Since" header),
> > go ahead and generate the page in the usual way.
> >
/snip/
> Yes, that's exactly what i am doing. What I was thinking was, can we encode
> this design pattern into the Servlet API so that anyone can use it, rather
> than just staying with the old way which wasn't working for me, ( and
> presumably for others who have similar requirements)
Ok, forgive my denseness: what's the difference between this design pattern
(call it A) and the 'old way' (call it B)? It seems the only difference is that
(A) let's the getLM()-like code access local variables of the doGet() method (I
dont find the exception-handling objections tentible - see below).
/snip/
> >> 3) getLM() will set LastModified even if doGet() fails and throws an
> >> exception. This means that the client will try and cache your "error"
> page
> >> (unless you do a sendError() or somesuch).
> >
> >I think there's at least a few different issues here:
> >
> >* If you do use getLM and it returns a time before
> > the if-modified-since header in the request, your
> > doGet() method will never get called, so it won't have
> > any opportunity to throw an exception or display an
> > error page. See above for my beliefs about servlets
> > that throw exceptions, but error pages are a legitimate
> > concern.
>
> Not sure I get this one. Why would you return a valid time from getLM() if
> you knew you wanted to send an error?
You would set a valid time from getLM only if you wanted to REsend an error page
(ie, the content of the page has not changed, it's still an error).
In general, it's probably simpler to turn off browser caching on error pages
(ie, response.setHeader("Cache-Control", "no-cache") whenever doGet() returns an
error page), than to keep server-side error caches (which get removed when the
error goes away).
> >* If your app sends back an error page of some sort,
> > (say, input fields failed a validation test), then it's your
> > responsibility to remember that on the subsequent
> > request, so that you send back an appropriate
> > last-modified time that forces a reload of the "real"
> > page. This is true if you are using getLM or if you are
> > embedding your caching logic directly into doGet.
>
> Hmmm, sounds complex. Why not just prevent the error page from being cached
> by not setting the LastModified in the response? This is easy if you write
> your own, but if impossible using getLM().
Why impossible?
If doGet() sends an error page from a specific URL, make sure the browser cache
is off on the response page. That way, getLM() will not even get called on the
next request for that URL because there is no if-modified-since tag in the
request header.
/snip/
> >For any given app, this staleness decision might be based on combining any
> or
> >all of the following factors: logged-in user, request URI, query
> parameters,
> >cookies, HTTP headers, browser making the request (in case you keep
> different
> >versions for different browsers), time of day (you might be producing
> updates
> >on some sort of regular schedule that invalidates the cached copy) and so
> on.
> >Proposed solutions to this, IMHO, suffer from a level of complexity far
> higher
> >than any other concept in the servlet API, and don't belong there. Whether
> to
> >cache, and how to cache, seem to me to be application-level decisions, not
> >generic API level mandates.
>
> Yes, it's nasty alright. :-( But doesn't that make it even more important
> for the Servlet API to offer good support in this area?
>
It seems to me that the service() method works fine (if browser is caching URL
and URL not stale, tell browser the URL's not stale; otherwise doGet()), what we
may need to get some buff server-side caching class(es). Say a
javax.servlet.http.HttpLastModifiedCache which the app developer can
configure/customize to fit their needs (vis-a-vis the above raised points) and
that can be used with getLM().
Though this may a place for third-party developers to step in...
-s
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
