You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by John Tangney <jt...@knowledgeplanet.com> on 2000/07/15 00:23:15 UTC
struts-example, browser caches and state
Hi
I hope this is not off topic, but it does relate to struts: That's where I'm
having problems, and where I hope to find a solution. I have been looking
into the problem discussed in
http://archives.java.sun.com/cgi-bin/wa?A2=ind0005&L=jsp-interest&D=0&m=126
86ITEM+&P=46427
on the JSP list. So I did some experiments with some browsers using
struts-example, and I found some behavior I couldn't quite understand.
Unfortunately, the three browsers I used not only (often) exhibit different
behavior, but they each offer different inspection capabilities, making it
hard to see what's really going on and compare (without sniffing.)
Scenario A (using iCab on MacOS)
1) Go to main example page - /struts-example/index.jsp
2) Click on Log on - /struts-example/logon.jsp
3) Enter info; click submit - /struts-example/logon.do
4) Click Log off - /struts-example/logoff.do
5) Now repeat steps 2-4
The server does NOT see the second logoff.do. The browser has cached it.
Although this appears to be a browser bug, I don't see why the browser
should NOT have cached it - what's special about it? iCab has a nice logging
facility, and the http requests and responses are what you'd expect: All
server responses are 200, and the final request for logoff.do is never sent
to the server.
Scenario B (using IE 5.0 on MacOS)
The same scenario "works" here - the browser sends the request for logoff.do
to the server. But why? How does IE (notoriously over-zealous about caching)
know not to cache the page?
Scenario C (using Netscape 4.7 on MacOS)
Behavior is the same as IE (is this history? ;-> ). Netscape has the neato
"Page Info" feature, which explicitly says that /struts-example/logoff.do IS
in the cache.
So my question is: Is there something struts is doing to make B and C work?
If so, what is it?
I know that rf2068 section 13.9 says:
We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those containing a
"?" in the rel_path part) to perform operations with significant side
effects, caches MUST NOT treat responses to such URLs as fresh unless
the server provides an explicit expiration time. This specifically
means that responses from HTTP/1.0 servers for such URIs should not
be taken from a cache. See section 9.1.1 for related information.
OK, that would explain why some of the other URLs are not cached, but it
does not explain /struts-example/logoff.do
Oh yeah. The server is tomcat (standalone).
All help appreciated!
--johnt
Re: struts-example, browser caches and state
Posted by John Tangney <jt...@knowledgeplanet.com>.
Thanks for the response, Craig.
See below.
On 7/14/00 3:39 PM, Craig R. McClanahan at Craig.McClanahan@eng.sun.com
wrote:
See below.
John Tangney wrote:
[snip]
Scenario A (using iCab on MacOS)
1) Go to main example page - /struts-example/index.jsp
2) Click on Log on - /struts-example/logon.jsp
3) Enter info; click submit - /struts-example/logon.do
4) Click Log off - /struts-example/logoff.do
5) Now repeat steps 2-4
The server does NOT see the second logoff.do. The browser has cached it.
Although this appears to be a browser bug, I don't see why the browser
should NOT have cached it - what's special about it? iCab has a nice logging
facility, and the http requests and responses are what you'd expect: All
server responses are 200, and the final request for logoff.do is never sent
to the server.
Scenario B (using IE 5.0 on MacOS)
The same scenario "works" here - the browser sends the request for logoff.do
to the server. But why? How does IE (notoriously over-zealous about caching)
know not to cache the page?
Scenario C (using Netscape 4.7 on MacOS)
Behavior is the same as IE (is this history? ;-> ). Netscape has the neato
"Page Info" feature, which explicitly says that /struts-example/logoff.do IS
in the cache.
So my question is: Is there something struts is doing to make B and C work?
If so, what is it?
[snip]
--johnt
It would be interesting to know if a "Last-Modified" header is being
included in the response. Struts is not sending either of these explicitly,
but the underlying servlet API classes (or the JSP compiler in the case of
JSP pages) might be.
Nope. No cache-control stuff whatsoever.
One thing you can do to Struts is ask it to include HTTP headers as follows
on all the responses it creates that go through the controller servlet (i.e.
all the *.do paths):
Pragma: No-cache
Cache-Control: no-cache
Expires: <<<a time far in the past>>>
You do this by adding the following initialization parameter to the action
servlet in your web.xml file:
<init-param>
<param-name>nocache</param-name>
<param-value>true</param-value>
</init-param>
This should help convince browsers that *none* of the pages being produced
should be cached.
Sure, that would force it, but I want to know *why* it appears to work as is
in IE & NS. In other words, can I depend on it always working, and under
what circumstances can I depend on the server being hit?
This may not be an appropriate topic for this list, given that struts is not
doing anything explicit...
Thanks again
Craig McClanahan
--johnt
RE: struts-example, browser caches and state
Posted by Robert Edgar <ro...@hkstar.com>.
The settings suggested by Craig wont necessarily work, in fact to really not
cache a page IE requires the addition of another HEAD section with all these
settings AT THE BOTTOM of the the page ie after the body section.
Then again adding these settings causes Netscape to be unable to submit a
form to the same page as the form is on (ie place a poll on your home page
and have a submit button with the result returning back to the home page).
Yet again IE on Mac works differently (and differnet version of IE on Mac
behave VERY differently) ... I havent worked with web pages on Mac for about
six months but from memory they die if you try to insert some of these tags
in the HEAD(maybe fixed in latest IE on Mac)
Globaly turning on/off this setting is to my mind not needed, for a
logon/logoff forms yes you want it but say for a listing of last weeks
orders then I would want these cached why hit the server just cause someone
reopened the same page.
The issues are not really Struts specifc the topic has been discussed many
times on other forums though with no single conclusion, as there is no
simple answer, its a nightmare.
BTW Yet another method to defeat caching is to add a dummy param on the GET
call which is the current time, IE see this as a different request so
forwards it to the server, the server just ignores the param, you can calc
the time param using javascript on the client for a static page (I guess if
using JSP you could do this in Java on the server)......
Rob
-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: Saturday, July 15, 2000 6:39 AM
To: struts-user@jakarta.apache.org
Subject: Re: struts-example, browser caches and state
See below.
John Tangney wrote:
Hi
I hope this is not off topic, but it does relate to struts: That's where
I'm
having problems, and where I hope to find a solution. I have been
looking
into the problem discussed in
http://archives.java.sun.com/cgi-bin/wa?A2=ind0005&L=jsp-interest&D=0&m=126
86ITEM+&P=46427
on the JSP list. So I did some experiments with some browsers using
struts-example, and I found some behavior I couldn't quite understand.
Unfortunately, the three browsers I used not only (often) exhibit
different
behavior, but they each offer different inspection capabilities, making
it
hard to see what's really going on and compare (without sniffing.)
Scenario A (using iCab on MacOS)
1) Go to main example page - /struts-example/index.jsp
2) Click on Log on - /struts-example/logon.jsp
3) Enter info; click submit - /struts-example/logon.do
4) Click Log off - /struts-example/logoff.do
5) Now repeat steps 2-4
The server does NOT see the second logoff.do. The browser has cached it.
Although this appears to be a browser bug, I don't see why the browser
should NOT have cached it - what's special about it? iCab has a nice
logging
facility, and the http requests and responses are what you'd expect: All
server responses are 200, and the final request for logoff.do is never
sent
to the server.
Scenario B (using IE 5.0 on MacOS)
The same scenario "works" here - the browser sends the request for
logoff.do
to the server. But why? How does IE (notoriously over-zealous about
caching)
know not to cache the page?
Scenario C (using Netscape 4.7 on MacOS)
Behavior is the same as IE (is this history? ;-> ). Netscape has the
neato
"Page Info" feature, which explicitly says that
/struts-example/logoff.do IS
in the cache.
So my question is: Is there something struts is doing to make B and C
work?
If so, what is it?
I know that rf2068 section 13.9 says:
We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those containing a
"?" in the rel_path part) to perform operations with significant side
effects, caches MUST NOT treat responses to such URLs as fresh unless
the server provides an explicit expiration time. This specifically
means that responses from HTTP/1.0 servers for such URIs should not
be taken from a cache. See section 9.1.1 for related information.
OK, that would explain why some of the other URLs are not cached, but it
does not explain /struts-example/logoff.do
Oh yeah. The server is tomcat (standalone).
All help appreciated!
--johnt
It would be interesting to know if a "Last-Modified" header is being
included in the response. Struts is not sending either of these explicitly,
but the underlying servlet API classes (or the JSP compiler in the case of
JSP pages) might be.
One thing you can do to Struts is ask it to include HTTP headers as
follows on all the responses it creates that go through the controller
servlet (i.e. all the *.do paths):
Pragma: No-cache
Cache-Control: no-cache
Expires: <<<a time far in the past>>>
You do this by adding the following initialization parameter to the action
servlet in your web.xml file:
<init-param>
<param-name>nocache</param-name>
<param-value>true</param-value>
</init-param>
This should help convince browsers that *none* of the pages being produced
should be cached.
Craig McClanahan
RE: Turbine VS Struts?
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
Thanks for the reply. I really enjoy using Struts. Its amazing how fast and
simple it is to use once you get up to speed, and for the most part, its not
hard to use at all.
> > Anyone have any insight (Craig most likely) as to where the
> Turbine project
> > fits in with Struts? It appears Turbine is quite alot like
> Struts, but has
> > alot more features. I am not trying to sway Struts users to Turbine, my
> > interest is in knowing if Turbine does the same thing. It states its a
> > single servlet, but I am wondering if it does the bean
> auto-population and
> > reads in an xml config file? I can't seem to find it in the
> docs and I don't
> > have alot of time to download and play with it right now. I
> just wonder if
> > it does do things the same way Struts does with actions,
> mappings, auto-bean
> > population, etc but also offers a host of other features (or is
> the Struts
> > framework the heart of Turbine?), if its better to go that route or not?
>
> Turbine is emacs, Struts is vi :-)
>
> No but seriously... Craig can speak to the design goals, but I can give
> my perspective as someone who has used both. You really have to answer
> the question "is it better to go one route or not?" by taking some time
> looking each over and considering your application.
>
> For my applications, Struts is a good fit because it provides the core
> functionality I need in a well designed way without introducing mandatory
> dependancies on a lot of other stuff.
>
> It has i18n built in from the start.
>
> Writing my own application-specific custom tag libraries is cool.
>
> Very portable. There isn't a bunch of services sitting in the JVM as
> singletons, which sort of relies on servlet container implementation
> details (a custom class loader) to keep multiple applications from
> interfering with one another.
>
> I want to use the build in authentication features of the Servlet 2.2
> spec.
>
> I'm anticipating good tool support for JSP content development. Any day
> now... ;-)
>
> It's pretty easy to get up to speed on, especially for content developers
> and junior developers I work with.
>
> Either way, these are two great project under the Jakarta umbrella, and
> both have lots of active developers pitching in.
>
> -jh
>
>
> --
> Jeff Hutchison <jh...@inst.strykercorp.com>
> Stryker Instruments, Kalamazoo, MI
>
>
Re: Turbine VS Struts?
Posted by "Hutchison, Jeff" <jh...@inst.strykercorp.com>.
On Sat, 15 Jul 2000, Kevin Duffey wrote:
> Anyone have any insight (Craig most likely) as to where the Turbine project
> fits in with Struts? It appears Turbine is quite alot like Struts, but has
> alot more features. I am not trying to sway Struts users to Turbine, my
> interest is in knowing if Turbine does the same thing. It states its a
> single servlet, but I am wondering if it does the bean auto-population and
> reads in an xml config file? I can't seem to find it in the docs and I don't
> have alot of time to download and play with it right now. I just wonder if
> it does do things the same way Struts does with actions, mappings, auto-bean
> population, etc but also offers a host of other features (or is the Struts
> framework the heart of Turbine?), if its better to go that route or not?
Turbine is emacs, Struts is vi :-)
No but seriously... Craig can speak to the design goals, but I can give
my perspective as someone who has used both. You really have to answer
the question "is it better to go one route or not?" by taking some time
looking each over and considering your application.
For my applications, Struts is a good fit because it provides the core
functionality I need in a well designed way without introducing mandatory
dependancies on a lot of other stuff.
It has i18n built in from the start.
Writing my own application-specific custom tag libraries is cool.
Very portable. There isn't a bunch of services sitting in the JVM as
singletons, which sort of relies on servlet container implementation
details (a custom class loader) to keep multiple applications from
interfering with one another.
I want to use the build in authentication features of the Servlet 2.2
spec.
I'm anticipating good tool support for JSP content development. Any day
now... ;-)
It's pretty easy to get up to speed on, especially for content developers
and junior developers I work with.
Either way, these are two great project under the Jakarta umbrella, and
both have lots of active developers pitching in.
-jh
--
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments, Kalamazoo, MI
Turbine VS Struts?
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi all,
Anyone have any insight (Craig most likely) as to where the Turbine project
fits in with Struts? It appears Turbine is quite alot like Struts, but has
alot more features. I am not trying to sway Struts users to Turbine, my
interest is in knowing if Turbine does the same thing. It states its a
single servlet, but I am wondering if it does the bean auto-population and
reads in an xml config file? I can't seem to find it in the docs and I don't
have alot of time to download and play with it right now. I just wonder if
it does do things the same way Struts does with actions, mappings, auto-bean
population, etc but also offers a host of other features (or is the Struts
framework the heart of Turbine?), if its better to go that route or not?
Thanks.
Re: struts-example, browser caches and state
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
See below.
John Tangney wrote:
> Hi
>
> I hope this is not off topic, but it does relate to struts: That's where I'm
> having problems, and where I hope to find a solution. I have been looking
> into the problem discussed in
>
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0005&L=jsp-interest&D=0&m=126
> 86ITEM+&P=46427
>
> on the JSP list. So I did some experiments with some browsers using
> struts-example, and I found some behavior I couldn't quite understand.
> Unfortunately, the three browsers I used not only (often) exhibit different
> behavior, but they each offer different inspection capabilities, making it
> hard to see what's really going on and compare (without sniffing.)
>
> Scenario A (using iCab on MacOS)
> 1) Go to main example page - /struts-example/index.jsp
> 2) Click on Log on - /struts-example/logon.jsp
> 3) Enter info; click submit - /struts-example/logon.do
> 4) Click Log off - /struts-example/logoff.do
> 5) Now repeat steps 2-4
> The server does NOT see the second logoff.do. The browser has cached it.
> Although this appears to be a browser bug, I don't see why the browser
> should NOT have cached it - what's special about it? iCab has a nice logging
> facility, and the http requests and responses are what you'd expect: All
> server responses are 200, and the final request for logoff.do is never sent
> to the server.
>
> Scenario B (using IE 5.0 on MacOS)
> The same scenario "works" here - the browser sends the request for logoff.do
> to the server. But why? How does IE (notoriously over-zealous about caching)
> know not to cache the page?
>
> Scenario C (using Netscape 4.7 on MacOS)
> Behavior is the same as IE (is this history? ;-> ). Netscape has the neato
> "Page Info" feature, which explicitly says that /struts-example/logoff.do IS
> in the cache.
>
> So my question is: Is there something struts is doing to make B and C work?
> If so, what is it?
>
> I know that rf2068 section 13.9 says:
>
> We note one exception to this rule: since some applications have
> traditionally used GETs and HEADs with query URLs (those containing a
> "?" in the rel_path part) to perform operations with significant side
> effects, caches MUST NOT treat responses to such URLs as fresh unless
> the server provides an explicit expiration time. This specifically
> means that responses from HTTP/1.0 servers for such URIs should not
> be taken from a cache. See section 9.1.1 for related information.
>
> OK, that would explain why some of the other URLs are not cached, but it
> does not explain /struts-example/logoff.do
>
> Oh yeah. The server is tomcat (standalone).
>
> All help appreciated!
>
> --johnt
It would be interesting to know if a "Last-Modified" header is being included in
the response. Struts is not sending either of these explicitly, but the
underlying servlet API classes (or the JSP compiler in the case of JSP pages)
might be.
One thing you can do to Struts is ask it to include HTTP headers as follows on
all the responses it creates that go through the controller servlet (i.e. all
the *.do paths):
Pragma: No-cache
Cache-Control: no-cache
Expires: <<<a time far in the past>>>
You do this by adding the following initialization parameter to the action
servlet in your web.xml file:
<init-param>
<param-name>nocache</param-name>
<param-value>true</param-value>
</init-param>
This should help convince browsers that *none* of the pages being produced
should be cached.
Craig McClanahan