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

[Klaus Weide]

On Tue, 10 Aug 1999, John Hascall wrote:
> 
> > 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.
> 
>  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".

This formulation is at least ambiguous; does "prefix' include the string
itself, i.e. is N <= strlen(path) or N < strlen(path)?

Your interpretation seems to be the most straightforward reading, but
I have some doubts that that is actually what was intended.  Matching
based on path segments (as lynx does) instead of chars just seems to
make more sense.  It is more in line with how URL paths are handled in
other situations: the base URL when resolving relative URLs, and (I
think - haven't checked now) matching of URLs for determining the
realm for authentication [also lynx's -realm btw.].

OTOH the "Preliminary Specification" from Netscape at
<http://home.netscape.com/newsref/std/cookie_spec.html> does give an
explicit example that shows unstructured string matching:
   'The path "/foo" would match "/foobar" and "/foo/bar.html".'
I am just not sure whether the later specs really intend to work the
same way.  

I intend to ask the draft's author for clarification.

Even if lynx is doing path matching right, the confirmation prompt text
may still be misleading:
   Accept invalid cookie path=/cgi-bin/somecgi as a prefix of '/cgi-bin'?
The question isn't really whether '/cgi-bin/somecgi' is a prefix of
'/cgi-bin', but whether '/cgi-bin/somecgi' is a prefix of '/cgi-bin/somecgi'
(itself).

Strictly speaking, the sentence you quoted is from the 'Sending Cookies'
section; the 'Rejecting Cookies' section is more directly relevant, it
lists (as one reason for rejection)

      * The value for the Path attribute is not a prefix of the request-
        URI.

so this is in accordance with what you quoted, as it should be.
(With the minor difference "is" vs. "matches".)

>  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 /.

This is one indication that path is meant to work in a structured way,
not just as an unstructured string.

Btw. this *has* changed between RFC 2109 and state-man-mec-10, the latter
now has

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

In the Netscape "Preliminary Specification" the behavior when path= is
missing is describes so sloppily that I can't tell whether it is meant
to be as in RFC2109, as in state-man-mec-10, or something yet different.
Maybe that is why most "netscape" cookies always are sent with path=/,
so in practice path is rarely used.  (That or some "bug" in handling
the cookie path in some NS browser versions - I remember reading something
like that, but not any details.  Maybe the bug is the specification...)

> > 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.

Yes, that's still the latest one.  As far as I understand it is not
the author's fault that it's old, but it got delayed by other factors
in the process of becoming an RFC.  Therefore it is still up for
consideration as a "Proposed Standard" RFC afaik.  It is listed in
<ftp://ftp.ietf.org/iesg/1protocol_actions.txt>.  (I don't understand
the process well enough to know what exactly that implies.)


   Klaus