RE: question re: cookies
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.
cheers,
Roland
"Kalnichevski, Oleg" <[EMAIL PROTECTED]>
25.03.2004 09:29
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project"
<[EMAIL PROTECTED]>
cc:
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
Oleg
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
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" <[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
***
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:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
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
Oleg
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
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" <[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
***
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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" <[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
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
"Alvarez, Gil" <[EMAIL PROTECTED]>
25.03.2004 07:37
Please respond to "Commons HttpClient Project"
To: <[EMAIL PROTECTED]>
cc:
Subject:question re: cookies
Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.
We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.
I obfuscated the url's and data, but the gist of it is that we hit the
url:
2004/03/24 19:06:25:295 PST [DEBUG] wire - ->> "GET /a/b/c/aol
HTTP/1.1[\r][\n]"
We get back a Set-Cookie:
2004/03/24 19:06:25:535 PST [DEBUG] wire - -<< "Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]
I then see this:
2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
"$Version=0
; badsc=cookie-value; $Path=/X/b/c". Illegal path attribute "/X/b/c".
Path of origin: "/a/b/c/aol"
and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:
if (!path.startsWith(cookie.getPath())) {
throw new MalformedCookieException(
"Illegal path attribute \"" + cookie.getPath()
+ "\". Path of origin: \"" + path + "\"");
}
So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.
Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
"Alvarez, Gil" <[EMAIL PROTECTED]>
25.03.2004 07:37
Please respond to "Commons HttpClient Project"
To: <[EMAIL PROTECTED]>
cc:
Subject:question re: cookies
Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.
We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.
I obfuscated the url's and data, but the gist of it is that we hit the
url:
2004/03/24 19:06:25:295 PST [DEBUG] wire - ->> "GET /a/b/c/aol
HTTP/1.1[\r][\n]"
We get back a Set-Cookie:
2004/03/24 19:06:25:535 PST [DEBUG] wire - -<< "Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]
I then see this:
2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
"$Version=0
; badsc=cookie-value; $Path=/X/b/c". Illegal path attribute "/X/b/c".
Path of origin: "/a/b/c/aol"
and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:
if (!path.startsWith(cookie.getPath())) {
throw new MalformedCookieException(
"Illegal path attribute \"" + cookie.getPath()
+ "\". Path of origin: \"" + path + "\"");
}
So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.
Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??
Thanks.
question re: cookies
Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.
We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.
I obfuscated the url's and data, but the gist of it is that we hit the
url:
2004/03/24 19:06:25:295 PST [DEBUG] wire - ->> "GET /a/b/c/aol
HTTP/1.1[\r][\n]"
We get back a Set-Cookie:
2004/03/24 19:06:25:535 PST [DEBUG] wire - -<< "Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]
I then see this:
2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
"$Version=0
; badsc=cookie-value; $Path=/X/b/c". Illegal path attribute "/X/b/c".
Path of origin: "/a/b/c/aol"
and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:
if (!path.startsWith(cookie.getPath())) {
throw new MalformedCookieException(
"Illegal path attribute \"" + cookie.getPath()
+ "\". Path of origin: \"" + path + "\"");
}
So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.
Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??
Thanks.
