hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juho Mäkinen <juho.maki...@gmail.com>
Subject Re: Possible bug in NetscapeDraftSpec.java
Date Mon, 30 May 2005 11:09:09 GMT
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 -class,
which is, as noted before, is the base validation class, so it won't work.

There is also a IgnoreCookieSpec -class, which has empty validate -method,
but all the other methods are also empty, so it seems that this class
is designed
to be used when one wants to ignore every cookie (ie, turn the cookies off)

The following code can be found from DefaultHttpParamsFactory.java:

        try {
            defaultCookiePolicy =
System.getProperty("apache.commons.httpclient.cookiespec");
        } catch (SecurityException ignore) {
        }
        if (defaultCookiePolicy != null) {
            if ("COMPATIBILITY".equalsIgnoreCase(defaultCookiePolicy)) {
                params.setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY);
            } else if ("NETSCAPE_DRAFT".equalsIgnoreCase(defaultCookiePolicy)) {
                params.setCookiePolicy(CookiePolicy.NETSCAPE);
            } else if ("RFC2109".equalsIgnoreCase(defaultCookiePolicy)) {
                params.setCookiePolicy(CookiePolicy.RFC_2109);
            }
        }

As you can see, it get's a property and then uses param.setCookiePolicy
according to the property. It only allows me to set one of those three
CookieSpec class, which are part of the httpclient package. After
that, there isn't a choise to use the IgnoreCookiesSpec class, so I'm
guessing that it have been forgotten
because the definition exists in CookiePolicy class (look the snippet below)

I'm proposing the following:

Modify DefaultHttpParamsFactory.java to accept a Fully Qualifed Java Class name
in a different system property. This way it won't broke the
compability with older
versions, and it allows a clear extension point to create custom
CookieSpec classes.

If I'm wrong, and there is already an extension point to this, please
correct me.
Otherwise, at the time you are reading this, I'm creating a patch
against the newest
CVS version to add this functionality.

>From CookiePolicy class:
        CookiePolicy.registerCookieSpec(DEFAULT, RFC2109Spec.class);
        CookiePolicy.registerCookieSpec(RFC_2109, RFC2109Spec.class);
        CookiePolicy.registerCookieSpec(BROWSER_COMPATIBILITY,
CookieSpecBase.class);
        CookiePolicy.registerCookieSpec(NETSCAPE, NetscapeDraftSpec.class);
        CookiePolicy.registerCookieSpec(IGNORE_COOKIES,
IgnoreCookiesSpec.class);



 - Juho Mäkinen, juho.makinen@gmail.com


On 5/30/05, Ortwin Glück <ortwin.glueck@nose.ch> wrote:
> 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://jakarta.apache.org/commons/httpclient/3.0/cookies.html
> 
> Cheers
> 
> Ortwin Glück
> 
> Juho Mäkinen wrote:
> > 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, path,
> > boolean, Header)
> > [TRACE] Cookie - enter Cookie(String, String, String, String, Date, boolean)
> > [TRACE] HttpMethodBase - processResponseHeaders: validating cookie
> > with parser: class
> > org.apache.commons.httpclient.cookie.NetscapeDraftSpec
> > [TRACE] CookieSpec - enterNetscapeDraftCookieProcessor
> > NetscapeDraftSpec.validate(Cookie)
> > [TRACE] CookieSpec - *** Running CookisSpecBase.validate
> > [TRACE] CookieSpec - enter CookieSpecBase.validate(String, port, path,
> > boolean, Cookie)
> > [TRACE] CookieSpec - enter CookieSpecBase.formatCookie(Cookie)
> > [WARN] HttpMethodBase - Cookie rejected:
> > "58d96052313d9e7f=X2yIz07jnG+XXXXXXXXX2kk5FgUtNUr+vcwhvMEZ+svgDuTg4IGk3qPc4pQ3Y8DBLCtS3T8WxVHiOXhVg+WMZkELfC1EezJFxxxxxxxxIKAOtbXuqM99j/H7LFipryX+6xuTYBq4D1pYnC/EYsp1hNaDnkTfuc4xxxxxxxxxxgdhSxJDRdh/JwIPzLd2heapGQ0l5LFavexAW4XYJqdga72xEc9ThzKEQF3UDCWC3Z6FyNaEW3MSjoixsJU68v88Pa+TnJk9tqF52nUU4goN/0xxxxxxxxxxR0boSEBCpcKd0Ju1Acan3kmAVGUMlSxO8rCAAtZR+xxxxxxxxPCIOsCppsG8rBOxHKzYyR1xdF3YevyElftZBS9O8IoeoYgVRxxxxxxxxx/9468eIwanV+nuc0UV4iRC/+ZnkRbVxykTqkF03fIZXeXSoXLQSExxxxxxxrrC/KI3epCLVk7gBYX0uUcT5V/V16kf5LT85dMxr6E6VZcbgsqCbJQyeS16J8+wX4wL5km/2WSXGIoFjrZ3YTrVE1ytLam9zZVcrEExxxxxxxxhRAlg1Rt+ria49UkKWaJObE5wqdBJQh6/SPvkdOCZdJfE8i2Lf/ZRr0f9woagQ4ukT".
> > Illegal path attribute "/uas/0/58d96052313d9e7f". Path of origin:
> > "/uas/main"
> > [TRACE] CookieSpec - enter CookieSpecBase.parse(String, port, path,
> > boolean, String)
> > [TRACE] CookieSpec - enter NetscapeDraftSpec.parse(String, port, path,
> > boolean, Header)
> > [TRACE] Cookie - enter Cookie(String, String, String, String, Date, boolean)
> > [TRACE] HttpMethodBase - processResponseHeaders: validating cookie
> > with parser: class
> > org.apache.commons.httpclient.cookie.NetscapeDraftSpec
> >
> > The request url is basicly https://host:port/uas/main and ans you can
> > see, the cookie PATH is set to /uas/0/58d96052313d9e7f
> >
> > The site is located behind corporate firewall, so you can't access it.
> >
> > The default CookieSpecBase.validate throws MalformedCookieException if
> > the cookie fails the validation. It seems that every other CookieSpec.validate
> > calls first CookieSpec.validate (the super.validate(...) line), and
> > that transforms
> > into a call to CookieSpecBase.validate (as you can see in the debug
> > log snippet above)
> > which fails in the following code (throws the exception, as seen in
> > the log snippet)
> >
> >         ****** From CookieSpecBase.validate ******
> >         if (!path.startsWith(cookie.getPath())) {
> >             throw new MalformedCookieException(
> >                 "Illegal path attribute \"" + cookie.getPath()
> >                 + "\". Path of origin: \"" + path + "\"");
> >         }
> >
> >
> > Again, if the call to super.validate() is a feature, then this could
> > be solved by
> > setting own custom class delivered from CookieSpec, but it seems that
> > the current
> > httpclient code does not allow any generic extension point here (like giving
> > custom class with a property value)
> >
> >
> >  - Juho Mäkinen, juho.makinen@gmail.com
> >
> >
> >
> > On 5/30/05, Ortwin Glück <ortwin.glueck@nose.ch> wrote:
> >
> >>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 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
> >>>CookieSpecBase.java, but I noticed that NetscapeDraftSpec.validate
> >>>calls CookieSpecBase.validate (here's a code snippet from
> >>>NetscapeDraftSpec.validate)
> >>>
> >>>        LOG.trace("enterNetscapeDraftCookieProcessor "
> >>>            + "NetscapeDraftSpec.validate(Cookie)");
> >>>        // Perform generic validation
> >>>        super.validate(host, port, path, secure, cookie);
> >>>
> >>>        // Perform Netscape Cookie draft specific validation
> >>>        if (host.indexOf(".") >= 0) {
> >>>           .......
> >>>
> >>>The validation fails with the line "super.validate(...)" which calls
> >>>CookieSpecBase.validate.
> >>>I believe that the correct operation would NOT to use the
> >>>CookieSpecBase.validate
> >>>when using different (for example, in my case the NetscapeDraftSpec)
> >>>CookieSpec class.
> >>>
> >>>Is it a bug or is it a feature that NetscapeDraftSpec.validate really
> >>>calls super.validate?
> >>>If it's a feature then I'm willing to create a patch which allows clear and
easy
> >>>extension point to use custom CookieSpec class instead of the few
> >>>alternative classes
> >>>which are part of httpclient package.
> >>>
> >>> - Juho Mäkinen, juho.makinen@gmail.com
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >>>
> >>
> >>--
> >>  _________________________________________________________________
> >>  NOSE applied intelligence ag
> >>
> >>  ortwin glück                      [www]      http://www.nose.ch
> >>  software engineer
> >>  hardturmstrasse 171               [pgp id]           0x81CF3416
> >>  8005 zürich                       [office]      +41-1-277 57 35
> >>  switzerland                       [fax]         +41-1-277 57 12
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
> 
> --
>   _________________________________________________________________
>   NOSE applied intelligence ag
> 
>   ortwin glück                      [www]      http://www.nose.ch
>   software engineer
>   hardturmstrasse 171               [pgp id]           0x81CF3416
>   8005 zürich                       [office]      +41-1-277 57 35
>   switzerland                       [fax]         +41-1-277 57 12
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
>

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


Mime
View raw message