Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
From: "micky" <micky_lee@cyberpowersystems.com.tw>
To: "'HttpClient User Discussion'" <httpclient-users@hc.apache.org>
References: <11567676.4218291204093616422.JavaMail.servlet@kundenserver>
 <000301c879ea$f9b695e0$ed23c1a0$@com.tw> <47C8ED33.3070309@dubioso.net>
 <001d01c87c64$c9783010$5c689030$@com.tw> <47CAA914.4020702@dubioso.net>
In-Reply-To: <47CAA914.4020702@dubioso.net>
Subject: RE: cookie or session-id is different from the same HttpClient
 connection?!
Date: Tue, 4 Mar 2008 10:53:52 +0800
Message-ID: <001701c87da2$faf6a060$f0e3e120$@com.tw>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
thread-index: Ach80mKk0RerYOm3SfqVZ2Ad1FmETAAzaYIg
Content-Language: zh-tw

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 .=20
> 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.=20

> 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.=20
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?=20
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