Duffey Kevin wrote:
> Hi,
>
> >The HttpSession does what you say, associates a 'session' (some java object)
> >with an id. The id is passed as the Cookie to the browser.
>
> Yeah..this much I knew. I just wasn't sure if I didn't use cookies or URL
> rewriting, if the HttpSession does it for you. I now know that you must use
> one or the other to preserve the state of the session (or should I say, to
> keep the client inline with the session on the server they belong to?).
>
The servlet container will do cookie passing for you with no changes in your
servlets or JSP pages. However, if your client does not support cookies, then URL
rewriting is the only choice supported by the servlet API for maintaining session
identity.
Without doing either of the above, an HttpSession is pretty useless, because there
would be no way to recognize that a subsequent request did or did not belong to the
same session.
>
> >And yes URL re-writing does entail changing all of the URLs on a page
> >dynamically so that each client sees a unique URL - you don't need to use
> >JavaScript, you encode the URLs in the JSP page using a scriptlet (or
> >equivalent),
>
> Can anyone give an example? I can imagine it might be something like:
>
You don't have to write your own bean to do it -- see below for a revised version
of your example:
>
> <jsp:useBean id="utilbean" scope="request" class="com.bm.ui.beans.UtilBean" />
>
> <HTML><HEAD><TITLE></TITLE></HEAD>
> <BODY>
>
> <a href="<%= utilbean.encodeUrl("/somepath/somepage/mypage.jsp") %>">Click
> here</a>
>
> </BODY>
> </HTML>
>
The revised example would look like this:
<HTML><HEAD><TITLE></TITLE></HEAD>
<BODY>
<a href="<%= response.encodeURL("/somepath/somepage/mypage.jsp") %>">Click
here</a>
</BODY>
</HTML>
As you can see, encodeURL() is a standard method of the HttpServletResponse
interface, and performs URL rewriting in whatever way your servlet container
normally does so. (Prior to version 2.2 of the servlet API, there was freedom to
do this in various ways.) There is no need to implement your own version --
indeed, it would not do any good, because the servlet container would not recognize
your own proprietary method of passing the ID.
Because JSP pages are compiled into servlets, I would suggest that you also read
the Servlet API specification, as well as the appropriate API documents, to
understand the full power at your disposal. The various books and tutorials on
servlets also describe in much more detail how sessions work, and why they were
designed that way (based on the fact that the HTTP protocol is "connectionless" in
nature).
[snip]
> Also, is it recommended to do it this way? I hate to think on EVERY jsp
> page wherever I have a link to anything, I have to call this method. It
> kind of sucks to see it this complicated. Isnt there a way I can just set
> some HttpHeader myself without having to set every single URL on the page,
> so that I can "fake" as if a cookie was coming with the header? Maybe at
> the top of the page, I can put the cookie right in the header myself?
>
A cookie *is* the standard HTTP header that is defined for this purpose. It's not
so much setting something on the output of the page that matters -- what you are
trying to accomplish is to make the browser return something with subsequent
requests so that your servlet container can figure out which session those requests
belong to. If your browser does not support (or has turned off) cookies, you don't
have any other weapons at the HTTP level to do this -- all you've got left is URL
rewriting of every hyperlink that points back in to your application.
Or, you can educate your users about how silly it is to turn off cookies in their
browsers ... sometimes that is actually an easier problem to deal with :-).
>
> Thanks.
>
> Kevin Duffey
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
