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

[Dave Thaler <[e-mail]>]

Edited version looks good to me.

Thanks,
-Dave

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Barry Leiba
> Sent: Wednesday, August 7, 2013 12:04 PM
> To: Dave Thaler
> Cc: Bjoern Hoehrmann; RFC Errata System; [e-mail];
> [e-mail]; [e-mail]; Adam Barth
> Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)
> 
> Dave, have a look at the edited version before I click "HFDU", because once I
> do I can't edit it any more:
> http://www.rfc-editor.org/errata_search.php?rfc=6265&eid=3663
> 
> Does that work?
> 
> Barry
> 
> On Thu, Jul 11, 2013 at 12:06 AM, Dave Thaler <[e-mail]>
> wrote:
> > Based on my reading of
> > http://www.ietf.org/iesg/statement/errata-processing.html
> > it seems that problems like the one I'm pointing out should still be
> > Rejected if the WG had consensus at the time on what the current
> > design is.  As far as I know, that's the case and hence an erratum appears to
> be the wrong way to track the "flaw" (or unexpected
> > behavior).   So while I've written a longer summary (attached), I'm not
> adding it into the errata system.
> >
> > What I think is, however, reasonable in an errata is to point out that
> > the current odd/inefficient behavior was intended by the WG, and thus
> > the reader should expect it.  I think that would be a legitimate HFDU
> > case under the argument that the current text causes confusion (it
> certainly did for the Microsoft folks that caused me to file the erratum).
> >
> > Suggested updated text you can edit in...
> >
> > ===<begin snip>===
> >
> > Section 5.1.4 states:
> >>   A request-path path-matches a given cookie-path if at least one of
> >>   the following conditions holds:
> >>
> >>   o  The cookie-path and the request-path are identical.
> >
> > The "identical" rule differs from the URI equivalence rule(s) in RFC
> > 3986 sections 6.2 and 2.1 (e.g., "If two URIs differ only in the case
> > of hexadecimal digits used in percent-encoded octets, they are
> > equivalent.")  The fact that equivalent URIs have different cookies
> > arguably violates the principle of least astonishment.  To avoid
> > significant confusion and prevent such surprise, this fact should be noted
> so that it is at least not unexpected.
> >
> > OLD:
> >>   o  The cookie-path and the request-path are identical.
> > NEW:
> >>   o  The cookie-path and the request-path are identical. Note that this
> >>        differs from the rules in RFC 3986 for equivalence of the path
> component,
> >>        and hence two equivalent paths can have different cookies.
> >
> > ===<end snip>===
> >
> > If you can replace the original erratum text with the above, please do so.
> > If you cannot, feel free to append the above prefixed with some
> > statement to the effect that ABNF strings are case insensitive and so
> > the statements about HEXDIG were incorrect, and this text is a corrected
> summary of the issue.
> >
> > -Dave
> >
> > -----Original Message-----
> > From: Dave Thaler
> > Sent: Monday, July 8, 2013 1:53 PM
> > To: Barry Leiba; Adam Barth
> > Cc: Bjoern Hoehrmann; RFC Errata System; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: RE: [http-state] [Technical Errata Reported] RFC6265 (3663)
> >
> > 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/
> >>>
> >>>
> >>>