[jcifs] Annoying SMB URL question.

[Christopher R. Hertel]

On Mon, Dec 09, 2002 at 09:46:17AM -0800, Conrad Minshall wrote:
> At 8:01 AM -0500 12/9/02, Glass, Eric wrote:
> 
> >> > Just beating a dead horse
> 
> Me too.

Me three.  ;)
I have no idea why I like playing with this stuff, but I do.
My 7-year-old daughter calls me "Captain Pedantic".  Ouch.  :)

> >> > c) Selecting ";" simply because it doesn't have to be
> >> escaped doesn't really
> >> > buy you anything; to be correct, your applications will
> >> still have to be
> >> > able to unescape whatever separator is chosen.  i.e.:
> >>
>
> >Actually, my previous statement above is incorrect.  Using ';' as the
> >reserved (as defined in RFC 2396, section 2.2) delimiter for domain-user
> >separation would NOT necessarily require that an application handle the
> >instance in which the semicolon is escaped as '%3B'.  For the sake of
> >completeness in the spec, it might be worthwhile to specify whether the
> >presence of '%3B' is to be treated as an encoded separator (valid) or as an
> >encoded literal ';' (which would be an illegal character in this case).
> >This would only be significant in determining whether something like:
> >
> >smb://user%3Binfo:password@server
> >
> >should be parsed as the (valid) user "info" in domain "user", or the
> >(invalid) username "user;info" with no domain qualifier.

It would be the latter.  The reason that the escaped backslash is used in
the http: URL scheme is that it is *not* a defined part of that scheme.  
The underlying system (on the server-side, perhaps?) is parsing the domain
name from the username.

Using the semi-colon (unescaped) we are specifying that the SMB URL 
recognizes the user and domain as separate fields, delimited by the 
semicolon.  If you had "user%3Binfo" then, yes, that would be considered 
the username and passed to the server as "user;info" with no 
authentication domain qualifier.

In the odd case that you would have a semicolon in a username or an 
NTdomain name the escape would be your only way of including that 
character.

> 2396 defines "unreserved characters" (and excludes semicolon from 
> that list).  2396 also says "data must be escaped if it does not have 
> a representation using an unreserved character".  2396 also defines 
> "reserved characters" (and includes semicolon).
> 
> So interpreting a %3B as a delimiter rather than as data invalidates 
> escaping, the only mechanism available to represent a semicolon as 
> data.  In the password component for instance this would mean no way 
> exists to embed a "@" as password data. 

Right.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org