Well, the servlet would then need to know when the JSP's content changed in
order to know whether to return the 304 or forward the request to the JSP.
Yes, I suppose that is possible.
I think I would prefer to keep everything in the JSP though, since it is
already responsible for changing its own content....I think I may opt for
(gulp) hacking the servlet code generated by the JSP. Hmmm, maybe not.
I'll continue to think about it. I really wish JSP supported a
"getLastModified()"!.
Thanks for the suggestion.
----- Original Message -----
From: "Michael Weller" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 04, 2002 6:50 AM
Subject: Re: ??? Using JSPs to Send Not-Modified-Since Header ???
> hi!
> this is just a workaround, but anyway:
> can't you have a servlet receive the clients' requests and have the
> servlet's if-modified functionality, the only thing this servlet does is
> forwarding to your jsp (only in case it has been modified).
> another option would be to check the date in your jsp, and in case it
didn't
> change return a 304 explicitly.
>
> -mw
>
> ----- Original Message -----
> From: "Tony LaPaso" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 04, 2002 9:28 AM
> Subject: ??? Using JSPs to Send Not-Modified-Since Header ???
>
>
> > Hi all,
> >
> > In looking at past posts, I'm afraid I know the horrible answer
> > to this issue but I thought I'd ask just in case I missed
> > anything.
> >
> > Let me start by saying I'm using Tomcat v4.0.4 beta 3.
> >
> > As you know, when a client (usually a web browser) has a cached
> > version of a resource (usually a web page) it can send an
> > "If-Modified-Since" header to the HTTP server. The server
> > compares the time/date stamp specified in the header with that of
> > the requested resource. If the resource has *not* been modified
> > since the time specified in the "If-Modified-Since" header, the
> > server sends back a 304 (Not-Modified) response, effectively
> > telling the client (usually a web browser) that its cached
> > version of the resource is still valid.
> >
> > When writing a servlet, it's easy to handle this sort of
> > scenario. The javax.servlet.http.HttpServlet class has a
> > "service()" method. This method first checks if the incoming HTTP
> > method is a GET. If it is, the "service()" method proceeds to
> > call the "getLastModified()" method of the servlet. As a
> > developer, you can override "getLastModified()" to return a long
> > value representing the last time the requested resource was
> > changed. Depending on the value returned by "getLastModified()"
> > (note that -1 is returned if you don't override the method) the
> > "service()" method may simply return a 304, Not-Modified response
> > rather than calling the servlet's "doGet()" method.
> >
> > Now, the $18.32 Question: How do you ensure "getLastModified()"
> > is called in JSP?
> >
> > No, you cannot simply do this:
> >
> > <%!
> > public long getLastModified() {
> > return xxx;
> > }
> > %>
> >
> > The problem is that the above method will never be called by the
> > container.
> >
> > I traced through some of the Tomcat/Catalina/Jasper code and it
> > seems to me that the response code is being set to 200/OK very
> > early on in the processing.
> >
> > I also took a cursory look at the JSP spec and didn't find any
> > indication of setting a "Not-Modified" response code...so, I am
> > thinking this is something that is (strangely) missing in the JSP
> > specification. I have a JSP page that needs to update itself once
> > per day. Therefore, it would be very handy to have the
> > "getLastModified()" functionality enjoyed by servlet writers.
> >
> > Can anyone confirm this?
> >
> > Thanks...
> >
> >
>
___________________________________________________________________________
> > 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
> >
>
>
___________________________________________________________________________
> 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
>
>
___________________________________________________________________________
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
