Re: draft-ietf-http-state-man-mec-03: $Version and path

Gisle Aas <aas@bergen.sn.no> wrote on 19 Sep 1997 11:59:27 +0200:

  > dmk@research.bell-labs.com (Dave Kristol) writes:
  > 
  > > Gisle Aas <aas@bergen.sn.no> wrote on Mon, 15 Sep 1997 21:41:31 +0200:
  > > 
  > >   > I have tried to implement support for cookies in libwww-perl based on
  > >   > draft-ietf-http-state-man-mec-03.txt and have trouble finding answers
  > >   > to the following two questions.
  > >   > 
  > >   >   1) What to do for "Cookie: $Version=?" if the matching "Set-Cookie2"
  > >   >      fields have different value of their Version attributes?  What if
  > >   >      you have a mix of old "Set-Cookie" and "Set-Cookie2" fields that
  > >   >      match.
  > > 
  > > Think of sending separate Cookie headers for each Set-Cookie[2].  The
  > > $Version you send with each Cookie header corresponds to the one you
  > > received in the Set-Cookie[2] for that cookie.  So a $Version applies
  > > to all cookie-value's that follow it lexically in a Cookie header.
  > 
  > or just use "," as separator before a new $Version attribute?
  > 
  >   Cookie: $Version=1; foo=bar; $Path="/foo", $Version=2; foo=bar

Yes, we're saying the same thing.  If there are multiple Cookie headers,
they may be folded together using a ',' separator.  The end result would
be what you've shown.

  > 
  > >   >   2) Can the path attribute contain URL escapes (%XX) as substitues for
  > >   >      the "real" chars?
  > >   >      Does '"Set-Cookie2: ...;  Path="/foo%2f%62ar"' match for a URL
  > >   >      like http://www/%66oo/bar?   If not, what are the rules?
  > > 
  > > You are correct that the specification does not say.  It should.
  > > Should we allow/require the value for the Path attribute to be
  > > URL-encoded?
  > 
  > what I have done now is to let URL-encoded chars and unencoded chars
  > match and then let "%2F" and "/" be the exception.  Perhaps ";" should
  > be special too?

I'm not sure I understand what you're saying.  It sounds like you're saying
the % escapes wouldn't be interpreted, except sometimes.  So
	Path="/%66oo"
and	Path="/foo" 
would be different, but
	Path="/foo%2F"
and	Path="/foo/"
would be the same.

That would be silly, IMO.  Rather, it would be better either to
interpret all % escapes or none.

A look at RFC 822 for quoted-string shows that the stuff inside the
quotes can be essentially anything.  In particular, it (qtext) can be any
CHAR except ", \, or CR, and those can be specified (quoted-pair) as an
escaped pair, as in "\\\"" for the string \".  So there really isn't any
need for URL encoding.  (I was probably sleeping when I answered your
question the first time. :-)

  > 
  > 
  > I have another question.  draft-ietf-http-state-man-mec-03 says:
  > 
  > | If multiple cookies satisfy the criteria above, they are ordered in the
  > | Cookie header such that those with more specific Path attributes precede
  > | those with less specific.  Ordering with respect to other attributes
  > | (e.g., Domain) is unspecified.
  > 
  > First of all I don't understand why you want to impose this order.
  > Can you comment on that?

Yes.  The order derives from the order described in Netscape's original
cookie spec.:  "When sending cookies to a server, all cookies with a
more specific path mapping should be sent before cookies with less
specific path mappings."

  > 
  > Does this apply to cookies both with a specified and a default path?

Yes.

  > Does paths belonging to different domains have to be ordered by most
  > specific path?

According to my reading of section 4.3.4, yes.

  > 
  > Consider these:
  > 
  >   Set-Cookie2: foo=bar1; Path="/foo"; Domain="www.acme.com"; Version=1
  >   Set-Cookie2: foo=bar2; Path="/foo/bar"; Domain=".acme.com"; Version=1
  >   Set-Cookie2: foo=bar3; Version=1; (response from http://www.acme.com/foo/bar/baz/)
  > 
  > and a request for
  > 
  >   http://www.acme.com/foo/bar/baz/x.html
  > 
  > Does the order have to be
  > 
  >   Cookie: $Version=1;
  >              foo=bar3;
  >              foo=bar2; $Path="/foo/bar"; $Domain=".acme.com";
  >              foo=bar1; $Path="/foo"; $Domain="www.acme.com"
  > 
  > or is it unspecified (which I hope :-)?

I think it has to be as you've shown it, based on how I read the spec.

Dave Kristol

Received on Monday, 22 September 1997 13:32:10 UTC