Juho Mäkinen wrote:
Thanks for you help. I'm also sorry that I didn't notice that TODO earlier.
I got it working now, so problem solved.
No worries, Juho.
I'd still suggest that you add more extension points into the httpclient.
Release 4 will have a complete interface based architecture
Thanks for you help. I'm also sorry that I didn't notice that TODO earlier.
I got it working now, so problem solved.
I'd still suggest that you add more extension points into the httpclient.
Using delivered classes and setting them into use with system properties
is usually an easy and very extend
Oleg, you are right. I just saw that TODO comment as well. I take that
as we are not going to change that to accept a fully qualified class name.
Odi
Oleg Kalnichevski wrote:
Juno,
That particular piece of code is provided for backward compatibility
with HttpClient 2.0. One should be using Co
> Apparently we missed to include the (rather new) IgnoreCookiesSpec in
> DefaultHttpParamsFactory. I will file a bug report for that and attach a
> patch. Having a fully qualified class name is not the purpose of this
> parameter (see below).
>
Odi, this is in fact intended. That piece of cod
Juno,
That particular piece of code is provided for backward compatibility
with HttpClient 2.0. One should be using CookiePolicy#registerCookieSpec
method register custom cookie specs. For more details see:
http://jakarta.apache.org/commons/httpclient/3.0/cookies.html
Hope this helps
Oleg
On M
Juho Mäkinen wrote:
You and Oleg seems to be right; the server is breacking cookie standards.
For my bad luck, the software breacking it is a proprietary one, so I can't
fix it directly.
I guessed that.
use the Browser Compatibility cookie spec instead. If that does not
Browser Compatib
You and Oleg seems to be right; the server is breacking cookie standards.
For my bad luck, the software breacking it is a proprietary one, so I can't
fix it directly.
> use the Browser Compatibility cookie spec instead. If that does not
Browser Compatibility maps itself to use CookieSpecBase -clas
Juho,
The path attribute of the cookie in question clearly violates both
RFC2109 and Netscape draft:
http://wp.netscape.com/newsref/std/cookie_spec.html
http://www.w3.org/Protocols/rfc2109/rfc2109.txt
The invocation of super.validate from the NetscapeDraftSpec#validate is
correct. The former imp
Juho,
This is not a bug. It is a security restriction. That server does not
conform to the standards. Thus the cookie is rejected. You may try and
use the Browser Compatibility cookie spec instead. If that does not
work, you have to write your own cookie spec implementation. Please see
http:/
Here is a copy from the output with log level set to trace. There are
few log lines with "***", those lines I have added later for my own
debug.
[TRACE] CookieSpec - enter CookieSpecBase.parse(String, port, path,
boolean, String)
[TRACE] CookieSpec - enter NetscapeDraftSpec.parse(String, port, pat
Juho,
can you post the Cookie headers and the site URL, please?
Did you read
http://jakarta.apache.org/commons/httpclient/3.0/cookies.html and have
you tried a different cookie spec?
Kind regards
Ortwin Glück
Juho Mäkinen wrote:
Hello.
I'm using commons-httpclient-3.0-rc2 to get pages fro
Hello.
I'm using commons-httpclient-3.0-rc2 to get pages from a site which
uses cookies.
Unfortunately, the site sends cookies with different PATH= than where the page
(which sends the cookie) was requested.
I suppose that the correct way is to use NetscapeDraftSpec class instead of
CookieSpecBas
12 matches
Mail list logo
