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

dmk@research.bell-labs.com (Dave Kristol) writes:

> Gisle Aas <aas@bergen.sn.no> wrote on 19 Sep 1997 11:59:27 +0200:
> 
>   > 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.

No, I meant the opposite.  "%2F" denotes a literal slash in a path
segment.  "/" is the path segment separator.  They are not the same
thing and I don't think they should match (but "%2f" and "%2F" is the
same thing).  "%66" and "f" is encodings for the same unreserved
character, so they match.

draft-fielding-url-syntax-07.txt says:

| 2.3. Unreserved Characters
|
|   Data characters which are allowed in a URL but do not have a reserved
|   purpose are called unreserved.  These include upper and lower case
|   letters, decimal digits, and a limited set of punctuation marks and
|   symbols.
|
|      unreserved  = alphanum | mark
|
|      mark        = "$" | "-" | "_" | "." | "!" | "~" |
|                    "*" | "'" | "(" | ")" | ","
|
|   Unreserved characters can be escaped without changing the semantics
|   of the URL, but this should not be done unless the URL is being used
|   in a context which does not allow the unescaped character to appear.

[...]

| 4.3.2. Path Component
|
|   The path component contains data, specific to the site (or the scheme
|   if there is no site component), identifying the resource within the
|   scope of that scheme and site.
|
|      path          = [ "/" ] path_segments
|
|      path_segments = segment *( "/" segment )
|      segment       = *pchar *( ";" param )
|      param         = *pchar
|
|      pchar         = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
|
|   The path may consist of a sequence of path segments separated by a
|   single slash "/" character.  Within a path segment, the characters
|   "/", ";", "=", and "?" are reserved.  Each path segment may include a
|   sequence of parameters, indicated by the semicolon ";" character.
|   The parameters are not significant to the parsing of relative
|   references.

Which might suggest that "/", ";", "=", and "?" should not match their
URL-encoded versions.


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

RFC-2068 says:

|          CTL            = <any US-ASCII control character
|                           (octets 0 - 31) and DEL (127)>
|
|          TEXT           = <any OCTET except CTLs,
|                           but including LWS>
|
|          quoted-string  = ( <"> *(qdtext) <"> )
|
|          qdtext         = <any TEXT except <">>

which makes me believe that CTLs are hard to represent literally in a
quoted-string.



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

OK, I'll update my implementation to reflect this.

Thanks, for you answers!

Regards,
Gisle

Received on Tuesday, 23 September 1997 04:31:10 UTC