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]
