Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 74.125.44.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=YUlLE6FSHT0Gq3KgxKX7POJ6HjXr3OHrhfqe292qJj0KxxXhftq+BCutcVuataxsCE
         ZMDBpENqXgCtqFbvRs3qVROvaxdZHRaUAoCwE5/isMYUDX69NX6s3SdYZU/vRK6mKlLm
         zSh0QPEx0bT3kP4z5GVyfv79UB8zcf0xDthiY=
Message-ID: <25aac9fc0810260749nf019ee5qd43ab135c0d75d55@mail.gmail.com>
Date: Sun, 26 Oct 2008 15:49:36 +0100
From: sebb <sebbaz@gmail.com>
To: "HttpComponents Project" <dev@hc.apache.org>
Subject: Re: BestMatchSpec - why does it not choose RFC2109?
In-Reply-To: <1225028136.15262.2.camel@ubuntu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <25aac9fc0810251555o1209f547j78d263a385f2004@mail.gmail.com>
	 <1225017462.11216.11.camel@ubuntu> <1225023302.14954.2.camel@ubuntu>
	 <25aac9fc0810260622l609411abhd8a3155aac43a80e@mail.gmail.com>
	 <1225028136.15262.2.camel@ubuntu>

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