W3C home > Mailing lists > Public > www-jigsaw@w3.org > January to February 1998

Servlet caching problem solved

From: Dave Harris <scorp@btinternet.com>
Date: Mon, 16 Feb 1998 11:16 +0000 (GMT Standard Time)
To: www-jigsaw@w3.org
CC: brangdon@cix.co.uk
Message-Id: <memo.19980216111639.36933A@btinternet.com>
I've just moved a servlet from the JSDK/FastTrack to Jigsaw. I found that
GET requests weren't always getting through to the servlet. I believe I've
fixed the problem by having the servlet set the Last-Modified header
explicitly.

As I understand it, I shouldn't need to do that. I was returning a
sensible value from HttpServlet.getLastModified(), and the javax code
automatically puts that into the header - provided the header hadn't
already been set.

The difference between the JSDK/FastTrack combination and Jigsaw is that
Jigsaw installs a default Last-Modified time before calling the servlet.
This defeats the code in javax.servlet.http.HttpServlet. And the default
value is the time I changed the servlet's configuration, which was days
ago, so the browser thought the page hadn't changed.

I can see that setting Last-Modified explicitly is a good defensive thing
to do, especially as the servlet API is vague about what really happens. I
thought I'd mention it anyway, in case someone else has the same problem.

I wonder if Jigsaw should remove its Last-Modified value before calling
the servlet, and put it back after the servlet has returned if the servlet
hasn't set it itself? This would at least make the Jigsaw behaviour more
consistent with the JSDK.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."
Received on Monday, 16 February 1998 06:18:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:27 GMT