Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

Barry Leiba <barryleiba@computer.org> Mon, 08 July 2013 20:43 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665A521F9DFE for <http-state@ietfa.amsl.com>; Mon, 8 Jul 2013 13:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.97
X-Spam-Level:
X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXpIX12qITP8 for <http-state@ietfa.amsl.com>; Mon, 8 Jul 2013 13:43:38 -0700 (PDT)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id CD53521F9DFB for <http-state@ietf.org>; Mon, 8 Jul 2013 13:43:34 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id n1so2545434qcx.36 for <http-state@ietf.org>; Mon, 08 Jul 2013 13:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zKFXZ1/jV6Cu4ndtXn3eiUiqMNSViAq85N9Fq+D9eaI=; b=C8bP9YCGTuIatL70kIs8GZVxG1l64QmijWM7jksIp1m+CaNkVcpdo07wO2AYgUKspL HUNs/CFeXWfgYuKKQ1aJekC+Jl4cB3L4COE4Uhytawu0hz4rDl2JwLQ4SohF0y2DR2KZ DBYKHRwpMY8bsjWA9z+5HDEZGck3PDnoJDnHqIZZBiSvaJ6Y4CxFGiVVrTPV0p3JZ1oJ ddEq9i8HmRGS9HRmWGltvN0PF2Y3KJuA+aXZDhpKlb43j1hBDF/vfPfdbnoorHzj4c1G aie+GddpmigNN+KApSSIMOUSBIvItq2gBmwSxQQ3BdAEbWnqME4ZbOrjJbXkFtlT2+LG DE4Q==
MIME-Version: 1.0
X-Received: by 10.229.93.72 with SMTP id u8mr4086252qcm.102.1373316204801; Mon, 08 Jul 2013 13:43:24 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.216.201 with HTTP; Mon, 8 Jul 2013 13:43:24 -0700 (PDT)
In-Reply-To: <CAJE5ia84biazW1-yOWwUmx94SGLL2daF2PPdWaj6+=5qCaigJg@mail.gmail.com>
References: <20130618002830.7DF236211A@rfc-editor.org> <7mavr8hhrqsfmcqt77181vqc3g3nl25s1d@hive.bjoern.hoehrmann.de> <9beb9558a94c434d84a0ccebfe4cc582@BY2PR03MB269.namprd03.prod.outlook.com> <CAJE5ia84biazW1-yOWwUmx94SGLL2daF2PPdWaj6+=5qCaigJg@mail.gmail.com>
Date: Mon, 8 Jul 2013 16:43:24 -0400
X-Google-Sender-Auth: HUgJsYtJne01B5OwHvaBc6Rlf9Y
Message-ID: <CALaySJL21aYDJKAq233FkZrUqk2H7uboo5GwgfURsB7hnRgkqQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Adam Barth <ietf@adambarth.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "presnick@qti.qualcomm.com" <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Dave Thaler <dthaler@microsoft.com>, "http-state@ietf.org" <http-state@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2013 20:43:39 -0000

Where are we on this?  Adam, Dave... should I mark this "Rejected"?
Dave, do you still contend that this report is correct?  Or should
some other change be proposed?

Barry

On Tue, Jun 18, 2013 at 5:29 AM, Adam Barth <ietf@adambarth.com>; wrote:
> On Mon, Jun 17, 2013 at 5:45 PM, Dave Thaler <dthaler@microsoft.com>; wrote:
>> Thanks Bjoern.
>>
>> Interesting, well in that case there may be an issue in the RFC 6265 algorithm for path matching.
>> That's because it requires comparison for "identical" and "ab", "AB", "aB", and "Ab" are not "identical".
>>
>> So
>> http://www.example.com/%AB/foo
>> http://www.example.com/%ab/foo
>> http://www.example.com/%Ab/foo
>> http://www.example.com/%aB/foo
>>
>> are all "equivalent" in the language of RFC 3986, but not "identical" and hence a cookie on one will not match the others.
>
> The path-match algorithm does exactly what it says.  Even though RFC
> 3986 might say that those strings are equivalent in some sense
> (perhaps as URIs?), the path-match algorithm in RFC 6265 treats them
> differently.  In particularly, they're not identical and the
> path-match algorithm will likely return "false" for one or more of
> them.
>
>> It may still be worth having an errata noting the above issue, even if it's Hold For Document Update.
>
> As far as I can tell, the errata is incorrect.
>
> On Mon, Jun 17, 2013 at 6:04 PM, Dave Thaler <dthaler@microsoft.com>; wrote:
>> I checked with one of the test teams at Microsoft and got this back:
>>
>>> There is a gap in the RFCs 3986 and 6265. RFC 3986 talks about the URI path and equivalence of
>>> encoded Unicode characters in the path section of the URI.
>
> I don't believe there is a gap.
>
>>> However, RFC 6265 section 5.1.4
>>> does not specifically state that the pre-fix match should be done on the unescaped URL path.
>
> RFC 6265 gives a complete description of how to perform a path-match.
> A compliant implementation will appear to operate as if it does
> exactly what the specification says to do.  Given that RFC 6265
> doesn't say to unescape the path, that means you ought not unescape
> the path.
>
>>> All the browsers we tested against (IE, Chrome, Firefox) do this case-sensitive prefix matching
>>> before sending the cookies to the other page.
>
> Indeed.
>
>>> For IIS applications created with Unicode characters, IIS converts the escaped characters
>>> (like %0D%0C) to lower case, and they are justified since the URI spec clearly calls out that they
>>> are equivalent.
>
> IIS is welcome to do that by the URI spec.  However, the strings are
> not treated equivalently by RFC 6265.
>
>>> When one page re-directs to another in IIS application, the cookies set for the
>>> first page are not presented to the application on the other pages. This problem exists with
>>> the cookie handling by all the browsers we tested against (IE, Chrome, Firefox). This is due to
>>> the gap I explained above.
>
> I don't see that as a problem.  All the implementations are
> interoperating perfectly and matching the specification.  It sounds
> like IIS has some undesirable behavior that its authors might want to
> modify.  In any case, there's nothing to change about RFC 6265.  The
> specification and the implementations are identical on this point.
>
> Adam
>
>
>> -----Original Message-----
>> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
>> Sent: Monday, June 17, 2013 5:36 PM
>> To: RFC Errata System
>> Cc: abarth@eecs.berkeley.edu; barryleiba@computer.org; presnick@qti.qualcomm.com; Jeff.Hodges@kingsmountain.com; Dave Thaler; http-state@ietf.org
>> Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)
>>
>> * RFC Errata System wrote:
>>>Notes
>>>-----
>>>HEXDIG is defined in [RFC5234], Appendix B.1 as
>>>  HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
>>>Note that lower case a-f are not legal.
>>
>> As per RFC 5234:
>>
>>    NOTE:
>>
>>       ABNF strings are case insensitive and the character set for these
>>       strings is US-ASCII.
>>
>>    Hence:
>>
>>          rulename = "abc"
>>
>>    and:
>>
>>          rulename = "aBc"
>>
>>    will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
>>    "ABC".
>> --
>> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
>> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>>
>>
>>