Re: lynx-dev LYCookie.c handles path (w/o trailing slash) incorrectly

[John Hascall]

> On Mon, 9 Aug 1999, John Hascall wrote:
> > While this works as expected:
> >     lynx http://some.web.host/cgi-bin/somecgi/
> > if, for example, we do:
> >     lynx http://some.web.host/cgi-bin/somecgi
> > and somecgi sends a cookie back containing:
> >     path=/cgi-bin/somecgi
> > then lynx[1] complains:
> >     Accept invalid cookie path=/cgi-bin/somecgi as a prefix of '/cgi-bin'?
> > because it is finding that last slash and whacking off everything after it.
> > It appears that the solution is to change line 1845 of LYCookie.c
> > from:
> >        } else {
> > to:
> >        } else if (*(ptr+1) == '\0') {        /* only zap a trailing slash *
/
> > -----------------
> > [1] I'm using 2.8.2 but viewing the 2.8.3 source looks like it is the same.

> Consider that lynx may actually be right, and this is actually an "invalid
> cookie" (according to the spec we are trying to implement[1]) as it says.
> In other words, your expectation may be wrong.  Have you checked?

 I have checked RFC2109 which says:

   The Path attribute of the cookie must match a prefix of the request-URI.

 Since it does not define prefix I can only assume it has the standard
 meaning of "1..N of the leftmost characters".  Perhaps this whacking
 it off at the last slash comes from a misreading of what the *default*
 path is if it is omitted:

   Path   Defaults to the path of the request URL that generated the
          Set-Cookie response, up to, but not including, the
          right-most /.

> I remember dimly having some open question about the path matching thing.
> (state-man-mec was unclear? different from RFC2109?)
> 
> [1] draft-ietf-http-state-man-mec-NN.txt, see links from
>     <http://www.bell-labs.com/mailing-lists/http-state/>.

    The only I-D there is draft-ietf-http-state-man-mec-10.txt
    which 'expired' sometime ago -- but it doesn't appear to
    change how Path is defined anyway.


John