hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: BestMatchSpec - why does it not choose RFC2109?
Date Sun, 26 Oct 2008 14:49:36 GMT
On 26/10/2008, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sun, 2008-10-26 at 14:22 +0100, sebb wrote:
>  > On 26/10/2008, Oleg Kalnichevski <olegk@apache.org> wrote:
>  > > On Sun, 2008-10-26 at 11:37 +0100, Oleg Kalnichevski wrote:
>  > >  > On Sat, 2008-10-25 at 23:55 +0100, sebb wrote:
>  > >
>  > >
>  > > Sebastian,
>  > >
>  > >  You were right. It seems the easiest and cleanest fix would be the make
>  > >  best-match cookie spec pick up RFC2109 spec for cookies generated from
>  > >  'Set-Cookie' headers.
>  > >
>  >
>  > Agreed, and always use RFC2965 for Set-Cookie2 headers.
>  >
>  > The Set-Cookie header did not have a domain, so there may also be a
>  > problem with the RFC2965 handling of a missing domain (it is optional,
>  > just checked).
>  >
>  > The extracted cookie was set up with the domain "localhost", which of
>  > course does not have the ".local" part attached. Same thing happened
>  > when I used the actual local name for the host. Seems to me that
>  > RFC2965 should add the ".local" suffix if necessary when generating
>  > the missing domain.
>  >
>
>
> This sounds odd, because that is what it does. I could not reproduce the
>  problem with a test case. Would you be able to put together a junit to
>  reproduce the issue?
>

I'll have a go later.

What I used was the Tomcat Cookie Example running locally combined
with a modified ClientFormLogin example from HC SVN, but that's
overkill for a test case.

Examples that failed are as follows:

<abcd=efgh>    Set-Cookie: special="abcd=efgh"; Version=1
<abcd efgh>     Set-Cookie: special="abcd efgh"; Version=1

Ones that worked OK are:

<abcdefgh>      Set-Cookie: special=abcdefgh
<"abcd efgh">  Set-Cookie: special="abcd efgh"

It's the ones that have a "Version" attribute that fail for me.

Note: the <> above are used to enclose the "cookievalue" parameter I
used in the CookieExample form.

>  Oleg
>
>
>
>
>
>  >
>  > >
>  > >  Oleg
>  > >
>  > >
>  > >
>  > >  > Hi Sebastian,
>  > >  >
>  > >  > Formally speaking RFC2965 superseded RFC2109 and rendered it obsolete.
>  > >  > However, RFC2965, probably, _should_ be backward compatible
>  > >  >
>  > >  > > I've been doing some testing with HttpClient 4.0 beta1, and it
is
>  > >  > > rejecting cookies of the form:
>  > >  > >
>  > >  > > Set-Cookie: special="abcd efgh"; Version=1
>  > >  > >
>  > >  >
>  > >  > This cookie seems to work for me. One with an explicit domain attribute
>  > >  > does not:
>  > >  >
>  > >  > Set-Cookie: special="abcd efgh"; domain="localhost"; Version=1
>  > >  >
>  > >  >
>  > >  > > when tested against a server on localhost, the error message is:
>  > >  > >
>  > >  > > Illegal domain attribute: "localhost".Domain of origin: "localhost.local"
>  > >  > >
>  > >  > > This appears to be coming from the RFC2965Spec validation which
is
>  > >  > > chosen by the BestMatchSpec class.
>  > >  > >
>  > >  > > Surely only Set-Cookie2: headers should be required to pass the
>  > >  > > RFC2965 validation?
>  > >  > >
>  > >  >
>  > >  > Probably you are right, but I would like to revisit the spec to be 100%
>  > >  > sure.
>  > >  >
>  > >  > > It looks like the BestMatchSpec class does not allow for using
>  > >  > > RFC2109, which I would expect to be used here.
>  > >  > >
>  > >  >
>  > >  > We could make this configurable. Would that make sense for you?
>  > >  >
>  > >  > Oleg
>  > >  >
>  > >  >
>  > >  > > I can get round the problem by using an IP address instead of a
>  > >  > > un-dotted host name, but it seems to me that the wrong Cookie spec
>  > >  > > class is being chosen here.
>  > >  > >
>  > >  > > ---------------------------------------------------------------------
>  > >  > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>  > >  > > For additional commands, e-mail: dev-help@hc.apache.org
>  > >  > >
>  > >  >
>  > >  >
>  > >  > ---------------------------------------------------------------------
>  > >  > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>  > >  > For additional commands, e-mail: dev-help@hc.apache.org
>  > >  >
>  > >
>  > >
>  > >  ---------------------------------------------------------------------
>  > >  To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>  > >  For additional commands, e-mail: dev-help@hc.apache.org
>  > >
>  > >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>  > For additional commands, e-mail: dev-help@hc.apache.org
>  >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>  For additional commands, e-mail: dev-help@hc.apache.org
>
>

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


Mime
View raw message