Am Montag, 3. Februar 2003 15:15 schrieb Adrian Janssen: Hi,
well, he's right. Sessions are a server-side thing, so the server has to generate and track them later on in its effort to overcome the statelessness of the HTTP protocol. There are at least three common approaches to this (cookies, URL rewriting, hidden fields), and a Java server commonly supports the first two by default and transparently to the application. If you say HTTPRequest.getSession(true), a new Session instance is created on the server. The details about how session info is kept on the client side (in any case, the client has to provide some 'token' upon each subsequent request identi- fying it as belonging to a specific session), are beyond that. Normally, the server tries to use cookies first, as this is the fastest and most reliable approach; but if that fails (people not knowing about the intricacies of cookies, but have heard somewhere that cookies may be kind of 'dangerous' regarding privacy concerns (which is not true in case of mere session cookies; still: try to find an end user being able to distinguish :)) tend to generally turn them off), it uses URL rewriting (if you did as well, look out for a JSESSIONID=<cryptic string> thing appended to the URL when accessing a Java web app). In this case, if your app is not browser-based, but a Java GUI client, it should suffice to extract the session id string from the response and append that to subsequent requests. Can't say for sure here, as I never tried it, but it should work, still :) HTH, -- Chris (SCPJ2) Note that the server app should be able to handle URL rewriting as well. Though this is not specific to GUI clients talking to a Java server, but some- thing to be expected from any Java server app, keep special heed of that issue, still. With URL rewriting, you have to make sure the JSESSIONID string is sent back on all responses and returned on each subsequent request, and generally be aware of the URLEncode() method (where that belongs to depends on the JDK version rsp. the Servlet/JSP version the app is coded for). Btw.: one of the 'new' things in KDE 3.1 (Konqueror | KHTML, the thing Apple's new 'Safari' browser is based on) is a fourth option in cookie handling (accept all | reject all | accept only session cookies, each combined with 'ask for permittance each time') that lets you treat all cookies as if they were session cookies, that is, if you close the browser, they're gone for good, regardless of the lifetime they may claim. Just to note. > I thought the browser generated them, but perhaps you are correct and the > server generates them on first request. If so, then you will need to send > the session id back to your client app on first request and then each > subsequent request the client app sends it back to the server. > > Sorry don't really know, let me know what you find out though! -- CLIP! =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
