Hello Micky,
The website only demonstrate how to setup the configuration instead of how to
use it for logging...
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 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?
If not, then the reason why it works is probably that the
Sun HttpURLConnection internally handles cookies, just like
HttpClient does.
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.
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 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.
In previous releases, the default strategy required strict
conformance to the specification, while most browsers and
probably also HttpURLConnection tolerate malformed cookies.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
