Hello David

If this is true, then why does

https://www.myDomain.com/images/image123.jpg

cache in IE just fine?
(where www.myDomain.com is being served exclusively
by my tomcat 5.0.28)
Note, as I indicated below, caching in IE of image123.jpg
will not occur under https when any other of the mechanisms
below which I have tried are serving the image.

However, I did find IE's

    "Do not save encrypted pages to disk"

setting.   Thanks for mentioning this.


Maurice

David Smith wrote:
Quote:

And finally, Internet Explorer should know to cache
this image and reuse when the request is made again
(assuming image is unmodified, of course).
Well all this works, EXCEPT, for the caching part
(which mozilla does know how to do).

AFAIK Internet Explorer is set by default to not cache SSL content and the user has to configure it to behave otherwise. Nothing in the response will change that.

Otherwise, a simple servlet should be able to do what you are asking without a problem and without all the forwarding/redirecting/request wrapping complexity.

--David

Maurice Yarrow wrote:

Hello Charles

Caldarale, Charles R wrote:
> "Why wasn't Tomcat's default servlet sufficient?"

Glad you asked this question!
My needs are different than those of the
author to whom you responded, but it would seem
that this is an appropriate time for me to explain
my goal and why I have tried numerous different
mechanisms for serving static content either
with my own servlet or by hacking DefaultServlet.
And most important, why all these experiments
failed to give the results I require.

First: the requirement:
The client sends a request for a static page
(in particular, an image).  As is usually the
case, if this will be served by DefaultServlet,
it is possible for anyone to take the request
URL they see in their html source and just
cut-and-paste it into the URL line, since this
has to map into an actual disk location in some
sense.  I do NOT want this to be possible.
What I require:
The client sends a request that has the image
name, but no other information.  First, my app
servlet will authenticate the request via session-
tracking/session-object.  Then the request getPathInfo()
will be massaged/modified to include the complete
location of the image.  Next, the request will be
forwarded to DefaultServlet to be served under https.
And finally, Internet Explorer should know to cache
this image and reuse when the request is made again
(assuming image is unmodified, of course).
Well all this works, EXCEPT, for the caching part
(which mozilla does know how to do).

Note that when DefaultServlet sends an image under
https but via the usual mechanism, say
"https://www.myDomain.net/images/imagename.jpg";

this will cache in IE.

Well, so things I can't permit: use of sendRedirect()
since it puts the URL in the URL bar in the browser.

Things that I have tried:  writing my own downloader
servlet, including all the getLastModifiedDate()
override method, setHeader(..."public"...), etc., etc.,
all of it basically copied from
DefaultServlet.   I have also tried taking the
DefaultServlet code and making it into one of my
own servlets, but it still will not induce IE to
cache under https.  (And this version had only
the most minimal changes to the DefaultServlet code.)
I have tried a filter and <filter-mapping> to map
the servlet-name to

 <servlet-name>default</servlet-name>

(I guess I did not yet try <servlet-name>/*</servlet-name> )

Hassan Shroeder just posted a suggestion that I try
the http://tuckey.org/urlrewrite/ module, and I am
looking into that.

Anyhow, I'll keep trying different ideas until something
works.  I'm nearly masochistically persistant...

But any suggestions would be greatly appreciated!

Maurice Yarrow



Caldarale, Charles R wrote:

From: John Laughton [mailto:[EMAIL PROTECTED] Subject: Re: static server implementation?

I ended up created a second context in tomcat that allows access to the static content (ie. large jpegs)




I'm confused.  Why wasn't Tomcat's default servlet sufficient?  It's
sole purpose is to deliver static content.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to