hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "micky" <micky_...@cyberpowersystems.com.tw>
Subject RE: cookie or session-id is different from the same HttpClient connection?!
Date Tue, 04 Mar 2008 02:53:52 GMT
Dear Roland,

> You set up the configuration, then you run your application.
> Note that the website has instructions for HttpClient 3.x.
> The package names as well as the name of the wire logger(s)
> have changed in 4.0.
I will try how to use the loggers in HttpClient 4.0.

> I am sure the server response a valid cookie because of the old code I wrote can work
well.
> The old code I use are HttpsURLConnection and HttpURLConnection . 
> I get a cookie from HttpsURLConnection.getHeaderField(), then I set the cookie with HttpURLConnection.setRequestProperty()
for next connection, and it works well.

> How can you be sure that the cookie is valid if you just
> get the header field without parsing and validating it?
> The header field by which cookies are received is "Set-Cookie"
> or "Set-Cookie2". The header field by which cookies are sent
> is "Cookie" and has a different format. Does your code take
> that into account?
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. 

> If not, then the reason why it works is probably that the
> Sun HttpURLConnection internally handles cookies, just like
> HttpClient does.
It seems Sun HttpURLConnection didn't handle cookie internally.

> > Please note that the first one I use is HttpsURLConnection and the second one is
HttpURLConnection.

> Unless the "secure" flag of the cookie is set, that doesn't
> make a difference.
OK, thanks.

>> Does it mean if the protocol changed from HTTPS to HTTP, the connection session will
be different from each other even if I use the same HttpClient instance?
> 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.

>> I think I need not to know which cookie version or protocol I receive or send because
the HttpClient's default cookie policy is "Best Match", am I right?
> If you are using HttpClient 4.0 alpha3, the default policy
> is "best match" and you shouldn't have to worry. If you are
> still on alpha2, there is no "best match" cookie policy.
> The feature was added in alpha3. If you are having problems
> with it, we need to know what goes wrong. There could still
> be a bug somewhere.
Yes, I am using HttpClient 4.0 alpha3. 
And it still can't work well when I want to login a https page then browse to another http
page since the cookie issue occurred.



> In previous releases, the default strategy required strict
> conformance to the specification, while most browsers and
> probably also HttpURLConnection tolerate malformed cookies.
So I have another question.
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.
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]
----

Does it a malformed cookies? Is the "expiry" is null normal?

Is there any other ways to figure out this problem?

Thanks for your kindly reply.

Sincerely,
Micky


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message