[jcifs] SMB URL

[Christopher R. Hertel]

On Tue, Jul 09, 2002 at 07:31:37PM -0400, Allen, Michael B (RSCH) wrote:
> If I do 
> 
>   f1 = new SmbFile( "smb://foo%2Ebar.what.snu.com" )
> 
> and I call toString() for display purposes in a status bar or something I
> might get:
> 
>   smb://foo.bar.what.snu.com

Ouch.  No, you should get

  smb://foo%2Ebar.what.snu.com

For display, the escaped version is the correct syntax.  Anything else is
a misinterpretation of the string.  Assuming NetBIOS names,
smb://foo.bar.what.snu.com and smb://foo%2Ebar.what.snu.com have different
meanings.

> But internally if I create a new object like:
> 
>   f2 = new SmbFile( f1, "share" );
> 
> and print that I correctly get:
> 
>   smb://foo.bar.what.snu.com/share

Again, no.  If the host string represents a NetBIOS name you should only
ever display it as "smb://foo%2Ebar.what.snu.com/share".

> then I call getPath() and should get:
> 
>   smb://foo%2Ebar.what.snu.com/share
> 
> So far so good. Seems conceptually easy enough. But if I had inadvertently
> used foo.bar.what.snu.com to build my new SmbFile object or a user
> accedentally used new SmbFile( f1.toString(), "share" ) the new url would
> represent a host foo with scope bar.what.snu.com which is not correct. 
> There are surely other pitfalls where this can occur. In general the
> escape is easily lost. It's not a robust technique.

Clearly not, not if the escape is lost... but I don't think that this is a 
problem of the proposed SMB URL format.  Consider something a bit 
different:

  ftp://crh:p@ssw0rd@ftp.ubiqx.org/pub/

the above string is clearly wrong.  A human eye can look at it and see 
that what I meant was:

  username = crh
  password = p at ssw0rd
      host = ftp.ubiqx.org
      path = /pub/

As it stands, though, I cannot use the example string as a URL because it
has an '@' character in the password field, which is against the syntax
rules.

The solution is to write the string as:

  ftp://crh:p%40ssw0rd@ftp.ubiqx.org/pub/
             ---

That is syntactically correct, and conveys the same information.

Whenever the URL is displayed (not that it's wise to display the password, 
but this is just an example) the substrings would all need to be escaped.  
The URL is syntactically "wrong" otherwise.  On the wire, of course, the 
unescaped string is used.


Okay...  Back to the topic at hand.

If we move the ScopeID to the ?query section, then any name (that is,
non-IP address) is either a NetBIOS name (no scope) or a DNS name.  This
successfully simplifies things by removing the dot question.  The dot no
longer needs to be escaped in a NetBIOS name (though we still need to go
through all of the resolution tests to figure out, semantically, what kind
of name it is).

On the other hand, brackets, colons, semi-colons, ampersands, non-printing
characters, etc. will still need to be escaped in a NetBIOS name.

  [Side note:  starting with NT4, Windows will whine if you try to create
  a machine name that contains a dot.  It is "legal", in NetBIOS terms, 
  but not very common at all.  Lots of other "unusual" characters are also
  frowned upon by windows.  That means that we are talking about a rare
  problem.  1% of the possibilities causes 99% of the problems.  Sigh.]

So, there would still be a class of characters for which maintaining the 
escaping is required.  Same problem.  For example...

  smb://foo@bar/

Is that
  user: foo
  host: bar
or NetBIOS name "FOO at BAR"?

If the latter was what was intended, then we would need to write:

  smb://foo%40bar/

...and we're right back where we started from.

Looking over this message, I think my argument is reasonable but it's 
really, really long-winded.  I should be able to do better.  Sorry.

The upshot is: scope or not, the escapes must be preserved when displaying 
the URL.  Otherwise, the syntax is lost and (as you point out) that 
changes the meaning of the string.

Chridz -)-----

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