David,
I mention the following since your session implementation on your web
server probably defaults to cookies.
We had a similar problem in that we wanted to set a cookie from a servlet
that returned a img i.e. was part of a source tag as in your example. We
could not get the cookie to be written back to the users browser i.e.
subsequent invocations could not find the cookie. Mind you we might have
not configured things properly on the servlet engine - which is possible.
The only explanation I have is that this has to do with the fact that the
html page already has its response header returned (which would have
returned any cookies to set on the users browser) and now you are trying to
write a cookie back into a response header of a url that this page accesses
BUT the response header has already been received therefore the browser
ignores it. I would think though that this would be a bug in browser
implementations - if what I am saying is true - which I can't tell for c
ertain. The only thing I can tell you is that it didn't work with NN 4.5
or IE 4.72.
BUT we did find a way to do this and it works quite well (FOR US) - albeit
its a work around and maybe not the best solution in your case. Since we
had a very small html page and we wanted to refresh the image contained in
it we set the url of the page via javascript with GET parameters and had
the servlet return a text/html page that contained the desired image path
written in the html INSTEAD of a servlet selectively returning a binary
image stream.
There are some PROs - I believe - for this approach:
(1) Chances are quite high that the image being returned is larger than the
html page content and therefore this approach allows the web server AND NOT
the servlet engine to stream back the image data. Who better to return
content than a web server which is specifically designed to do so.
(2) The servlet engine would be in a position to handle requests more
efficiently than before since the time spent on any given request is
reduced. This could make a BIG difference on a high traffic site as was
our case.
(3) You can take advantage of any caching that the web server uses to
buffer recently accessed files as I believe most good web servers probably
do. Servlet engines are not designed to cache files although that doesn't
stop you from maintaining some sort of memory cache yourself - although I
find this approach depends highly on the quantity and size of data
maintained and can be more unweildly than its worth.
The CONs - that I can see:
(1) Page structure is more static and more difficult to maintain if the
structure changes - since it is part of the servlet and not part a simple
html page that can be updated by something as simple as a text editor. In
our case this was not an issue because the content returned was simply a
frame with an image - the bulk of the content was still maintained in html
pages that are easily maintained.
If you have any feedback or find out otherwise please let me know....
Good Luck,
--Nikolaos
On Tuesday, February 01, 2000 12:19 PM, David Galimberti
[SMTP:[EMAIL PROTECTED]] wrote:
> I am having problems with session managment for a servlet that is the src
of an HTML img tag, for example:
>
> <img src="/servlet/imageServlet">
>
> Prior to using the servlet I created a session for the user but the
servlet does not find one for the request (i.e. request.getSession(false)
returns null). If I access the servlet via a redirect I can get to the
session just fine.
>
> Does anyone know if there is something "special" about a request of a
servlet that is the src of an img?
>
> Thanks!
>
> - David
> << File: ATT00060.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
