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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
