Hendrik,
Thanks for the info.
Let me see if I have this right.
The server is capable of managing session objects that have references
mapped to session IDs which are transported from the client upon each
request. The cookie based means of transport supplies the session ID in the
request header, namely the cookie header. If cookies are disabled, the
client must have some other means of communicating its session ID such as
urlEncoding, in which the session ID is written to the page hrefs.
I suppose another limitation would be if the user typed in a url directly,
thus failing to transmit the SID encoded in the page-written urls, a
not-uncommon scenario.
Are cookies and urlRewriting the only two norms for sessioning.
HTTP is curretnly a stateless protocol. Do you expect a revision to allow
statefulness for the purposes of session management?
Thanks!
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Hendrik Schreiber
Sent: Wednesday, August 16, 2000 3:28 AM
To: [EMAIL PROTECTED]
Subject: Re: url rewriting for sessions
The servlet API will NOT do it automatically. You have to make sure yourself
that URLs are
rewritten if you need to, because cookies are disabled on the clientside.
-hendrik
Khem Chand Sachdeva wrote:
> I have read that if cookies r disabled on client side then the Session API
in servlet
> will be using URL rewriting to pass the sesssion id back and forth and all
this will be
> done automatically.
> SO Session API will work even if client has disabled cookie.
> I am not sure whether it really happens or not.
> Khem Chand
>
> Hendrik Schreiber wrote:
>
> > Hi!
> >
> > URL rewriting means that a URL in a page, that your JSP or servlets
produces, is
> > encoded with the method response.encodeURL(String yourURL).
> >
> > So in a JSP instead of writing:
> > <a href="someURL">target</a>
> >
> > you should write:
> > <a href="<%=response.encodeURL("someURL")%>">target</a>
> >
> > pretty much the same applies to servlets.
> >
> > And that is exactly the limitation: you have to rewrite every single URL
you
> > produce!
> > The session id is sent back from the client to the server by clicking on
the
> > encoded link.
> > Contrary to Cookies, URL rewriting does not make use of headers.
> >
> > If you want to make sure everybody out there shall be able to use your
application,
> > use URL rewriting where necessary (see
request.isRequestedSessionIdFromURL() and
> > request.isRequestedSessionIdFromCookie()).
> >
> > If you don't want to go through the hassle, just use cookies and tell
you users to
> > accept them. IMHO they are absolutely no scurity risk.
> >
> > -hendrik
> > - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > tagtraum industries http://www.tagtraum.com/
> > jo! small&smart 2.2 servletengine
> > Java Server & Servlets The web-application book
> > The WebApp Framework http://www.webapp.de/
> >
> > Joe Hanink wrote:
> >
> > > Questions about URL Rewriting:
> > >
> > > what exactly is this and how is it done?
> > > what does the server do, and what is programmed?
> > >
> > > i've read that sessions tied to cookies can fail due to client side
> > > settings. url-rewriting was indicated as the workaround.
> > >
> > > do you build an adapted url or is it automated by some setting?
> > > does the client app pass its session id with every request, via some
header?
> > >
> > > finally, what are the limitations of url-rewriting... that is, what
are the
> > > failure modes (e.g. user clicks back button?)
> > >
> > >
===========================================================================
> > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> > > Some relevant FAQs on JSP/Servlets can be found at:
> > >
> > > http://java.sun.com/products/jsp/faq.html
> > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> >
> >
===========================================================================
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> > Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
>
===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
--
- - - - - - - - - - - - - - - - - - - - - - - - - - -
tagtraum industries http://www.tagtraum.com/
jo! small&smart 2.2 servletengine
Java Server & Servlets The web-application book
The WebApp Framework http://www.webapp.de/
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
