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

Dave Kristol (dmk@research.bell-labs.com)
Tue, 23 Sep 97 11:23:23 EDT 

Gisle Aas <aas@bergen.sn.no> wrote:

  > 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.
  > [...]
  > | 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 | ":" | "@" | "&" | "=" | "+"
  > [...]
  > Which might suggest that "/", ";", "=", and "?" should not match their
  > URL-encoded versions.
  >
  > [DMK's inappropriate citation of RFC 822 deleted]

Okay, I see your point now.  I think what you're saying, in fact, is
any character that is not a pchar must be escaped, and that an explicit
non-pchar does not match its escaped form.

So now we need words to say that.  How about these, for 4.3.4, under
Path Selection:

Two paths match if
	- respective characters match exactly; or
	- respective characters are represented by % escapes, and the values
		of the % escapes are equal; or
	- one path has an explicit character, the second path has a % escape,
		the % escape evaluates to the character, and the character
		is a pchar (RFC 2068).
Otherwise the paths do not match.

Dave Kristol