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

[Adam Barth <[e-mail]>]

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: [phone] · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>
>
>