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.