Rich Carreiro wrote:
> Hello.
>
> I am very new to servlets (been doing lots of reading recently :-)
Gotta encourage this kind of behavior by answering the "after the reading"
questions :-)
> and
> am still a bit confused by these two methods of session tracking and how
> they interact (or don't :-) with each other. I have spent a decent chunk
> of today reading over the SERVLET-INTEREST archives looking for posts about
> session tracking and they have indeed answered some of my questions.
>
> However...
>
> (1) When one says one is "using URL rewriting", that simply means the
> servlet/JSP developer is choosing to use functions to encode/rewrite
> URLs before those URLs are placed into the response being sent back
> to the browser, right? And it is something the developer has to
> explicitly do himself -- unless he calls the encode functions to
> rewrite the URLs, URLs don't get rewritten?
>
Yes, the developer must explicitly code in order to use URL rewriting. For
example, if you're creating a hyperlink in a servlet, you might do something
like this:
writer.println("<a href=\"" + response.encodeURL("the new URL") +
"\">The hyperlink</a>");
or in a JSP page, you would say:
<a href="<%= response.encodeURL("the new URL")>">The hyperlink</a>
Now, the first time you client makes a request that becomes part of a session,
the server sends both a cookie AND rewrites the URLs, assuming you did the
above. On a subsequent request, it checks to see if the session cookie was
returned. If it was, no more rewriting is done -- the URL is just returned
unchanged. However, if the session ID cookie was not returned, that means the
client doesn't support cookies, so it continues rewriting the URLs for the
remainder of that session.
> (2) [perhaps this is better sent to JSP-INTEREST] But what happens to
> URLs in JSP pages that are not inside of scriptlet code? Are they
> automatically rewritten by the server when it interprets the pages
> or are they left alone? If they are rewritten, what happens if the server
> detects that the browser is cookie-enabled? Will those "embedded" URLs be
> rewritten then? And if they're not rewritten ever, what then? How do
> you track sessions when a browser goes to one of those URLs?
>
Nothing is automatically rewritten for you in JSP. Unless you call the
encodeURL() method yourself (as I illustrated above), your hyperlink will be
passed through unchanged. The way to remember how it works is this: "the JSP
system does not understand HTML". All it does is look for the tags and
scriptlets that it recognizes, and replaces them. Everything else is passed
through unchanged.
>
> (3) Does it make sense to use both technologies? In other words, use
> cookie-based session tracking if the browser is cookie-enabled otherwise
> use URL rewriting? And if so, how is this done? Do you need if/else tests
> in your code everytime a servlet/scriptlet emits an URL (one arm of the
> test would encode the URL before sending and the other arm would just send
> the "raw" URL) or do you just unconditionally call the encode functions and
> they simply do null encoding when cookie-based tracking is being used [my
> scanning of the API indicates this is the case -- the encode functions only
> actually change the URL "when needed"]? If the former (you need to use an
> if/else), why not use only URL rewriting when you want to support
> "cookieable"
> and "non-cookieable" browsers? If the latter, why not always call the
> encode functions -- if cookies are working the URLs won't be rewritten, and
> if they are not working, the URLs will be rewritten -- guaranteeing you can
> work with the browser regardless of the browser's cookie capability?
>
If you create your links with URL rewriting as described above, they will
automatically work with cookie-enabled and cookie-disabled browsers. If you do
not do the rewriting, your app will only maintain sessions on cookie-enabled
browsers.
>
> Rich Carreiro [EMAIL PROTECTED]
> Senior Software Engineer +1 781 994-1135
>
Craig McClanahan
___________________________________________________________________________
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
