On Fri, 2008-03-07 at 13:24 +0800, micky wrote:
> Dear,
> 
> I finally figure out how to log!!
> 

> Please help me find out why these two connections' cookie are different.
> 

Because HttpClient does not find the first cookie when executing the
second request. You are not creating a new instance of HttpClient for
each request, are you?

Oleg 

> Thanks for your kindly help.
> 
> 
> Sincerely,
> Micky
> 
> 
> 
> 
> -----Original Message-----
> From: Roland Weber [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 06, 2008 1:02 AM
> To: HttpClient User Discussion
> Subject: Re: cookie or session-id is different from the same HttpClient 
> connection?!
> 
> Hello Micky,
> 
> > I just use HttpsURLConnection.getHeaderField("Set-Cookie") to get a cookie 
> > String, then I use HttpURLConnection.setRequestProperty("Cookie", cookie 
> > String) for the next connection.
> > And it worked well. 
> 
> That surprises me.
> 
> > It seems Sun HttpURLConnection didn't handle cookie internally.
> 
> So it didn't work before you copied the cookie in your application.
> Interesting.
> 
> >> HttpClient maintains a shared default session state for all
> >> connections. If you don't do something to prevent it, it will
> >> pick up the cookies that were previously set.
> > I think HttpClient should do this as you said too. But I don't know why it 
> > doesn't work for my code now.
> 
> Logging should help to find that out. You can also modify the
> code and put some System.out.println()s into interesting places,
> when the cookies for the request being sent are selected.
> 
> > Should I handle the cookie management in the server? 
> > The server is Struts on Tomcat, and I didn't do any additional action for 
> > handling cookie because I think the server should handle it itself.
> 
> If it's about a session cookie and your server-side application
> is a servlet or some other standard J2EE thing, you don't have
> to worry about session management.
> 
> > When I print the cookie content from 
> > HttpClient.getCookieStore().getCookies(), it shows as followings.
> > ----
> > [version: 0][name: JSESSIONID][name: 
> > 8C20EDB1D409B3AFCE1A1D25CCDE59CE][domain: 127.0.0.1][path: /agent][expiry: 
> > null]
> > ----
> 
> This looks OK. However, it specifies both a domain "127.0.0.1" and
> a path "/agent". If your next request is NOT to 127.0.0.1, then the
> cookie will not be sent. The comparison is on the string level, so
> if the next request goes to "localhost" instead of "127.0.0.1", then
> it will NOT match. Also, if your next request does not go to a path
> starting with /agent, this cookie will not match.
> 
> cheers,
>    Roland
> 
> 
> ---------------------------------------------------------------------
> 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]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to