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

[Dave Thaler <[e-mail]>]

Certainly the original issue as I phrased it is incorrect, so in that sense it's Rejected.
However, there is a functionality issue as I noted that results in unexpected behavior because two RFCs have differing definitions of equivalent.
The current RFCs do match the implementations, so it's really a design flaw in the RFCs not any bug in the implementations or doc per se.
I think the issue of unexpected behavior isn't an errata per se, it's a protocol "flaw" (in some sense) that should be noted somehow.
A HFDU errata would be one way to do that.  There may be other ways.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Barry Leiba
Sent: Monday, July 8, 2013 1:43 PM
To: Adam Barth
Cc: Dave Thaler; Bjoern Hoehrmann; RFC Errata System; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

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 <[e-mail]> wrote:
> On Mon, Jun 17, 2013 at 5:45 PM, Dave Thaler <[e-mail]> 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 <[e-mail]> 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:[e-mail]]
>> Sent: Monday, June 17, 2013 5:36 PM
>> To: RFC Errata System
>> Cc: [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]; Dave 
>> Thaler; [e-mail]
>> 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:[e-mail] · 
>> 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/
>>
>>
>>