hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wierd Programmer" <wierdprogram...@gmail.com>
Subject Re: Session handling in HttpClient
Date Thu, 26 Jun 2008 01:33:19 GMT
Hi Quitin,

 Thanks for the response.

 That does help me understand clearly about sessions.

 I will try to implement the same and incase of any questions, will get back
to you.

 Thanks again for your time.

Regards,
Jade

On Wed, Jun 25, 2008 at 12:47 PM, Quintin Beukes <quintin@last.za.net>
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 <wierdprogrammer@gmail.com> 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: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message