On Wed, 2008-11-05 at 09:04 -0800, Eugene Kondrashev wrote: > Hi! > >Alternatively, to generically support all servers, you might want to > >do a periodic "is session open" request, which is basically a request > >to the server that checks if the session is open. If you want to do > >this, there is a very safe way to implement something like this. Just > >ask me and I'll explain it (it's not as simple as checking for the > >presense of a session, as this will always return true). > > So can you explain how to do such a periodic "is session open" request? >
Just hit the target server with a HEAD or GET and see if you get the same session cookie (session id) back. Oleg > > Q Beukes wrote: > > > > Well, sessions are server related. Let me give you an idea of how sessions > > work: > > > > In this example I will use "SESSID" as the cookie name, but this can > > be configured, and differs in all implementations. > > > > First Request > > 1. Client visits server for the first time. > > 2. Server checks if the "SESSID" is set, it is NOT, so it creates a > > new session and generates a session ID to identify this session. > > 3. Server sends a "Cookie" header so teh client will create the cookie. > > 4. Client saves cookie for given domain. > > > > Second request > > 1. Client sends request a second time > > 2. Client also sends all cookies it now has, in this case SESSID which > > contains a string session id. > > 3. Server checks to see if SESSID was sent. > > 4. It was, so server takes this session id it received in the cookie, > > and sees if it has a session by that identification > > 5. Server locates the session data, and loads it into instance > > variables for the script/jsp/servlet/whatever. > > > > This is basically what happens. A session is nothing more than a way > > for the server to identify that the same client is visiting. This is > > done with cookies 99% of the time, and sometimes with GET variables > > (but same story, just a variable sent with every request containing > > the session id). > > > > Sessions are 100% server side. The client does nothing more than carry > > a unique identifier, and all session variables/data is stored in a > > persistent state on the server. There is no special communication or > > nothing. It's nothing special. > > > > You can create your own session implementation by simple having an > > array of open sessions, and each array items is a Map<String, String> > > of variable:value pairs. Then send cookies to track the clients, to > > know which Map to use. Simple. > > > > So the solution to your problems are this: > > You can support the session by receiving/resending cookies on all > > requests. > > > > You can do timeouts ONLY by knowing what timeout is configured on the > > server and having a timer track this yourself. So if the server > > session timeout is 1 hour, then have a time that checks the period of > > inactivity for requests, when it exceeds 1 hour, kill the session on > > your side by deleting the cookie and doing any > > cleanup/reinitialization. > > > > Alternatively, to generically support all servers, you might want to > > do a periodic "is session open" request, which is basically a request > > to the server that checks if the session is open. If you want to do > > this, there is a very safe way to implement something like this. Just > > ask me and I'll explain it (it's not as simple as checking for the > > presense of a session, as this will always return true). > > > > Q > > > > On 6/25/08, Wierd Programmer <[EMAIL PROTECTED]> wrote: > >> Hi folks, > >> > >> I am planning to use HttpClient in the client end of a Swing based > >> client - > >> server(Jboss) application. > >> > >> I am wondering how to handle sessions and specially session time out > >> situations...Are there any listener kind of things for session? Incase > >> If I > >> would like to show a message to the user saying session will time out in > >> so > >> and so seconds/minutes how do I do it? > >> > >> Please let me know how to go forward with this. > >> > >> Regards, > >> Jade > >> > > > > > > -- > > Quintin Beukes > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Session-handling-in-HttpClient-tp18106268p20343451.html > Sent from the HttpClient-User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
