hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Possible bug in NetscapeDraftSpec.java
Date Mon, 30 May 2005 10:26:04 GMT
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 implements the most generic validation logic common
to all cookie specs, whereas the latter implements Netscape draft
specific validation in addition to the generic one.

Oleg


On Mon, May 30, 2005 at 01:15:15PM +0300, 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
> 

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