Firstly, I found this like helpfull:
http://www.mnot.net/cache_docs/
I'm not expert, but my understanding is that you need to decide how long you
are happy for the stuff to be cached (a day, a week, a month) and set the
"Expires" and "Cache-Control" headers. Something like...
response.setHeader("Cache-Control", "public,max-age=86400"); // Cache for
24 hrs
(max-age is in seconds)
Calendar calendar = Calendar.getInstance();
calendar.add(Calendar.DATE, 1); // add one day
response.setDateHeader("Expires", calendar.getTime().getTime());
The link I gave says the Date for the "Expires" header needs to be GMT.
Thats the limit of my knowledge, anyone else who knows more, feel free to
jump in.
Niall
----- Original Message -----
From: "mike" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Struts Users
Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, June 17, 2004 6:31 AM
Subject: Re: Rendering Images
> Hi, Niall,
>
> Could you amplify on your note about "the right headers"? Thanks! I hope
> to learn something from you on this one.
>
> Michael
>
> At 07:33 PM 6/16/2004, Niall Pemberton wrote:
> >No! :-( This wouldn't be as simple as just adding an "imageNotFound"
> >property and for it to work it wouldn't be desirable in this tag.
> >
> >The <html:image..> tag doesn't know whether the image exists or not, all
it
> >does is render the <input type="image src="....." /> markup with the
"src"
> >attribute pointing to the location of the image - its then the browser
which
> >actually downloads the image, based on the src specified. The good thing
> >about this is that it can do caching, making pages load faster on
subsequent
> >visits.
> >
> >In order for the tag to know that the image didn't exist it would have to
> >retrieve it from the location specified - that would happen every time
the
> >jsp was executed to create the page and the browser would still do the
> >download as well. It would be better all round to use the solution
proposed
> >in this thread (using an Action to render an image) as with the right
> >headers set in that action, caching could still occur.
> >
> >Niall
> >
> >----- Original Message -----
> >From: "CRANFORD, CHRIS" <[EMAIL PROTECTED]>
> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> >Sent: Wednesday, June 16, 2004 5:15 PM
> >Subject: RE: Rendering Images
> >
> >
> > > YES! ;-)
> > >
> > > -----Original Message-----
> > > From: Linck, Ken [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 16, 2004 11:57 AM
> > > To: Struts Users Mailing List
> > > Subject: RE: Rendering Images
> > >
> > >
> > > On a sidenote, it would be kind of nice to add some kind of
imageNotFound
> > > property to the <html:image..> tag where you could specify an
alternate
> > > image instead.
> > >
> > > It seems like a common challenge in many places.
> > >
> > > -----Original Message-----
> > > From: mike [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 16, 2004 11:48 AM
> > > To: Struts Users Mailing List; 'Struts Users Mailing List'
> > > Subject: RE: Rendering Images
> > >
> > > I should say also, Jacob, that if you think the simple "URL" or
"protocol"
> > > is important and you wanted to complicate the code you could easily
change
> > > the request in the response to: /resource.do?hello.gif. I use
> > > /resourcedo?file_type=gif&file_name=hello.gif because in fact there
are
> > > other uses for things like /resource.do?hello.gif which are more
important
> > > to me. That is another story, however.
> > >
> > > At 08:34 AM 6/16/2004, Hookom, Jacob wrote:
> > > >Why would you use something like that? I'm maybe not following the
> > > >code? Is this so instead of writing:
> > > >
> > > >/images/hello.gif
> > > >
> > > >you can write:
> > > >
> > > >/resource.do?file_type=gif&file_name=hello.gif
> > > >
> > > >??
> > > >
> > > >-----Original Message-----
> > > >From: mike [mailto:[EMAIL PROTECTED]
> > > >Sent: Wednesday, June 16, 2004 10:14 AM
> > > >To: Struts Users Mailing List; Struts Users Mailing List
> > > >Subject: RE: Rendering Images
> > > >
> > > >I forgot. I have the entire solution I use at the struts wiki at
> > > >http://wiki.apache.org/struts/StrutsCatalogEschewUrlForProtocol. All
> > > >you have to do is to examine the input and give a different output
for
> > > >your problem. I use Wendy's get the data right solution, but I don't
> > > >have your problem. This is the easiest way to do this, I think.
> > > >
> > > >At 11:20 PM 6/15/2004, Linck, Ken wrote:
> > > > >It sounds like you have enough ways to do it and just asking what
> > > > >would be the best way or if there is another way to more
efficiently
> > > > >handle your situation. Yes?
> > > > >
> > > > >I cannot think of one personally. If your only means is HTTP, your
> > > > >only choice is evaluating the response to determine if something
> > > > >exists as far as I can tell. If the request cant be served, I
assume
> > >
> > > > >you get a typical response code like a 404? Not sure what else
there
> > > is.
> > > > >
> > > > >Nothing is real efficient when it comes to file io like functions
via
> > >
> > > > >HTTP. We tried to have a standard once for serving up file like
> > > > >functions via HTTP but it becomes complex if you wanted to perform
> > > > >other file-io activities like list files, seeing if they exist,
list
> > > > >directories, get file modified dates/times, delete files etc.
Almost
> > >
> > > > >felt like putting a square peg in a round hole for us(Course I
might
> > > > >be behind on the latest and greatest of HTTP).
> > > > >
> > > > >If I was concerned about managing unreliable sources, I probably
> > > > >would have attempted a proxy-like solution through a struts action
at
> > >
> > > > >first crack to do as little coding as possible but it sounds like
> > > > >your past the first crack at it?
> > > > >
> > > > >I will offer up my solution for battering by the populous here.
> > > > >
> > > > >You could set up a specific action which serves the images for
remote
> > >
> > > > >sites. Your JSP would have an action with a parameter passing in
the
> > >
> > > > >remote URL of the remote site. Since you indicated that you
> > > > >semi-manage the reference of the image but cant guarantee that it
> > > > >actually exists since its elsewhere, this solution might work
> > > > >good(i.e. you are supplying the remote URL?).
> > > > >
> > > > >You could open a request to the remote site of your URL in a Struts
> > > > >Action instead, if you get a success, take the content of the
> > > > >response and shove it into your response, otherwise, shove the
> > > > >no-image found file(from your server) into the response(Make sure
you
> > >
> > > > >return a null action mapping) since your writing off the content
> > > directly.
> > > > >
> > > > >Your JSP Might look like this:
> > > > ><img
> > > >
>src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=<bean:write
> > > > >name="thisForm" property="remoteURL"/>" width="300" height="300"
> > > > >border=0>
> > > > >
> > > > >Semi/Pseudo Code for proxyRemoteImage.do action:
> > > > >URL theRemoteImageURL = New URL(yourForm.getRemoteURL()); Open
> > > > >theRemoteImageURL Get Response If Response Code good shove content,
> > > > >content type and all the other stuff you need into your response of
> > > > >your users request(that might get rid of you having to handle file
> > > > >type conditions).
> > > > >If Response Code is bad, get the no image file data and shove that
> > > > >into the response instead Return null from execute method.
> > > > >
> > > > >I am sure you can gather upsides and downsides to the proxy-like
> > > > >solution. Just thought I would throw it into the pool of options.
> > > > >Not a great option but at least as simple I think. Not sure if you
> > > > >consider it more flexible or not.
> > > > >
> > > > >Hope you find what your looking for.
> > > > >
> > > > >
> > > > >-----Original Message-----
> > > > >From: CRANFORD, CHRIS [mailto:[EMAIL PROTECTED]
> > > > >Sent: Tuesday, June 15, 2004 4:44 PM
> > > > >To: '[EMAIL PROTECTED]'
> > > > >Subject: RE: Rendering Images
> > > > >
> > > > >Ken,
> > > > >
> > > > >That is what I'd like to do. Have an image which is rendered in
the
> > > > >case
> > > > >when the defined image cannot be loaded. the problem I have is
that
> > > > >our database record says that an image should exist, but the
> > > > >manufacturer/supplier didn't provide it to us... thus I need a way
to
> > >
> > > > >check if that image does exist to test that condition.
> > > > >
> > > > >thanks,
> > > > >chris
> > > > >
> > > > >ps - these images are maintained by a second webapp that is on a
> > > > >different web server all together due to space requirements. so i
> > > > >have to do testing via a HTTP request or something i would think,
no?
> > > > >
> > > > >-----Original Message-----
> > > > >From: Linck, Ken
> > > > >To: [EMAIL PROTECTED]
> > > > >Sent: 6/15/2004 2:32 PM
> > > > >Subject: RE: Rendering Images
> > > > >
> > > > >Just curious but why not just manually make this file once and
return
> > >
> > > > >it when a real image is not found on disk? Why bother creating one
> > > > >on the fly every time? Is it different from request to request?
> > > > >
> > > > >We had done something similar. We created a static image file on
> > > > >disk and return that when a real one is not available. I think we
> > > > >used a struts condition if tag testing if a real one exists
otherwise
> > >
> > > > >use the URL to not found image.
> > > > >
> > > > >-----Original Message-----
> > > > >From: CRANFORD, CHRIS [mailto:[EMAIL PROTECTED]
> > > > >Sent: Tuesday, June 15, 2004 1:21 PM
> > > > >To: '[EMAIL PROTECTED]'
> > > > >Subject: Rendering Images
> > > > >
> > > > >I'm curious if anyone has used or knows of an open-source image
> > > > >rendering servlet that permits rendering a "no image found" image
> > > > >file if the referenced image to be rendered does not exist on disk.
> > > > >
> > > > >Thanks
> > > > >
> > > > >_______________________________________________________
> > > > >Chris Cranford
> > > > >Programmer/Developer
> > > > >SETECH Inc. & Companies
> > > > >6302 Fairview Rd, Suite 201
> > > > >Charlotte, NC 28210
> > > > >Phone: (704) 362-9423, Fax: (704) 362-9409, Mobile: (704) 650-1042
> > > > >Email: [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]
> > > >
> > > >---------------------------------------------------------------------
> > > >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]
> > >
> > >
> >
> >
> >---------------------------------------------------------------------
> >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]
