Ah yes, cookie headers that were manually set used
to get overridden. As far as I remember, that changed
a while back. Though I cannot tell whether the change
went into 2.0 or only into the development branch.
cheers,
Roland
"Alvarez, Gil" <[EMAIL PROTECTED]>
25.03.2004 08:04
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project"
<[EMAIL PROTECTED]>
cc:
Subject: RE: question re: cookies
Thanks, yes, the old code pulled it out of the header directly, but the
rest of the story is that I save that cookie for later submittal in a
url request. I tried using addRequestHeader("Cookie", ...) and that
didn't work. I surmised that it was because httpclient liked to operate
with higher-level abstractions, so I switched to using real Cookie
objects. I'd much rather do a getHeader()/setHeader() operation or
getCookie()/setCookie()operation; I don't want to mix the semantics
(such as getHeader()/setCookie()). Sounds like the cookie policy is the
way to go.
-----Original Message-----
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 10:51 PM
To: Commons HttpClient Project
Subject: Re: question re: cookies
Hello Gil,
two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?
Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.
You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.
cheers,
Roland
