hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject RE: question re: cookies
Date Thu, 25 Mar 2004 08:41:10 GMT
Oleg, thanks for the hint.

Gil, if you're using version 2.0, instead of
hacking the HttpClient code, you can go
where others have gone before: write your
own GetMethod/PostMethod.
Just derive the regular ones, then override
addCookieRequestHeader() to do nothing.
Then you can setHeader() your cookies.

Optionally, you can also override method
processResponseHeaders() to do nothing,
so the incoming set-cookie headers will not
be parsed either.


"Kalnichevski, Oleg" <oleg.kalnichevski@bearingpoint.com>
25.03.2004 09:29
Please respond to "Commons HttpClient Project"
        To:     "Commons HttpClient Project" 
        Subject:        RE: question re: cookies

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


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


"Alvarez, Gil" <Gil@pogo.com>
25.03.2004 08:04
Please respond to "Commons HttpClient Project"

        To:     "Commons HttpClient Project"


        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]

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.


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: 
For additional commands, e-mail: 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message