Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.216.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Y+nEh52W7YSJcX9VbscwWF6uxBZobG2EQoGliWQ3/C6PaOpqBlbbMHPN60U7rtNyvm
         NC5vCPJWj7jQ1Fao59RHf8BO+hfuv9JRadQ927ZFIYitXq3IuXJ4HwzwvHo5LgFJm7yA
         2rC1E9bK6rBVhKacIxoz6zRj8nZvw3+GnnSqQ=
MIME-Version: 1.0
In-Reply-To: <1294573124.1813.4.camel@ubuntu>
References: <AANLkTi=hMkGHeKJKp7E1JDOVgHvrXLr5oYQOcZJqWj2X@mail.gmail.com>
	<1294573124.1813.4.camel@ubuntu>
Date: Sun, 9 Jan 2011 15:03:34 +0000
Message-ID: <AANLkTi=-f1VcM5QBHwxPr-R9-QLG-qQ2xk42b8+bEMYY@mail.gmail.com>
Subject: Re: bug report: invalid cookie format detected for IIS
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 9 January 2011 11:38, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sat, 2011-01-08 at 08:34 +0100, Magnus Leuthner wrote:
>> Hello developers,
>>
>> I've tried to use httpclient 3.x and 4.x with www.hotelextranet.com and from
>> what I observe it always seems to get the cookie format wrong.
>
> The cookie is question violates the HTTP state management specification
>
>> The cookies
>> end up garbled unless I specifically set the "NETSCAPE" standard. The
>> "BESTFIT" of 4.x doesn't seem to be the best fit for this IIS6 server. The
>> headers are (anonymized):

That's because there is no "expires" qualifier for the user cookie.

The "expires" qualifier is unique to Netscape cookies, and is used to
identify them.

>>
>>
>> Connection: close
>> Date: Sat, 08 Jan 2011 07:28:19 GMT
>> Server: Microsoft-IIS/6.0
>> Content-Type: text/html; charset=utf-8
>> Client-Date: Sat, 08 Jan 2011 07:28:19 GMT
>> Client-Peer: X.X.X.X:443
>> Client-Response-Num: 1
>> Client-SSL-Cert-Issuer: /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
>> Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
>> Client-SSL-Cert-Subject:
>> /C=US/postalCode=98005/ST=Washington/L=Bellevue/street=3150 139th Avenue
>> SE/O=Expedia Inc./OU=Ecommerce Ops/OU=Issued through Expedia Inc. E-PKI
>> Manager/OU=Comodo PremiumSSL/CN=hotelextranet.com
>> Client-SSL-Cipher: RC4-MD5
>> Client-SSL-Warning: Peer certificate not verified
>> P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA
>> PSD DELi OUR COM NAV PHY ONL PUR UNI"
>> Set-Cookie:
>> user=v.8,0,XXXXXXXXXXXXX$XXX$XXXXXXX$D46!G0.!5010$1C!70.$EFj$9D$2E$FBl$B9!4$FF!e02000;
>> Domain=.hotelextranet.com; path=/
>> Set-Cookie: tpid=v.1,20001; expires=Sunday, 31-Dec-2015 23:59:59 GMT;
>> Domain=.hotelextranet.com; path=/
>> Set-Cookie: MC1=GUID=XXXXXXXXXXXXXXXXXXXXX; expires=Sunday, 31-Dec-2015
>> 23:59:59 GMT; Domain=.hotelextranet.com; path=/
>> Set-Cookie:
>> NSC_ipufmfyusbofu.dpn-443-mc=XXXXXXXXXXXXXXXXXXXXXXXXXXX;expires=Sat,
>> 08-Jan-2011 07:38:19 GMT;path=/;secure
>>
>>
>> Without the NETSCAPE cookie format the first comma in the "user" cookie is
>> seen as a delimiter and the next cookie begins (name in example:
>> XXXXXXXXXXXXX$XXX...), which is not how it should work.

Set-Cookie headers that adhere to the RFC2109 standard may include
multiple cookies separated by commas.

So in the case of the user cookie, the header passes RFC2109, and
creates 3 cookies, two with empty values.

>
> You are wrong. Please refer to the HTTP state management spec for
> details.
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> 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