Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: question re: cookies
Date: Thu, 25 Mar 2004 08:29:18 -0000
Message-ID: 
 <825BF35A92B3F0479CC164ECBBE9376E0DE6F8@kccxoex06.corp.kpmgconsulting.com>
Thread-Topic: question re: cookies
Thread-Index: AcQSPEChugh+wQNjRXOiJbn/rGnRBwABlWAA
From: "Kalnichevski, Oleg" <oleg.kalnichevski@bearingpoint.com>
To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>


Gil, Roland
Pluggable cookie policies as well as ability to manually set cookie headers=
 are supported in the development branch only. For 2.0 there is no way=
 around forking HttpClient

Oleg

-----Original Message-----
From: Roland Weber [mailto:ROLWEBER@de.ibm.com]
Sent: Thursday, March 25, 2004 8:39
To: Commons HttpClient Project
Subject: RE: question re: cookies


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" <Gil@pogo.com>
25.03.2004 08:04
Please respond to "Commons HttpClient Project"
=0D
        To:     "Commons HttpClient Project"=0D
<commons-httpclient-dev@jakarta.apache.org>
        cc:=0D
        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:ROLWEBER@de.ibm.com]=0D
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


***************************************************************************=
************************
The information in this email is confidential and may be legally=
 privileged.  Access to this email by anyone other than the intended=
 addressee is unauthorized.  If you are not the intended recipient of this=
 message, any review, disclosure, copying, distribution, retention, or any=
 action taken or omitted to be taken in reliance on it is prohibited and=
 may be unlawful.  If you are not the intended recipient, please reply to=
 or forward a copy of this message to the sender and delete the message,=
 any attachments, and any copies thereof from your system.
***************************************************************************=
************************

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org