[jcifs] Re: SMB URL encoding/decoding

[Michael B Allen]

On Sat, 23 Feb 2002 15:10:11 -0600
"Christopher R. Hertel" <crh at ubiqx.org> wrote:

> Well, the first comment is that the SMB URL needs to meet the requirements
> of a URL string as described in RFC 2396.  There are two reasons for this. 
> The first is that IETF will never accept it if it doesn't, and the second is

Why wouldn't they if it followed the ftp RFC James is referencing?

> that most of the browsers out there have generic URL parsers.  Java also has
> a generic URL parser, IIRC.

But it's very limited. You have to pretty much override it entirely with
the exception of the most trivial of URLs. It only decodes the host,
port, file (path), and ref components and it will certainly fail to do
even that with anything that has arbitrary characters in the password
of some auth info.

  http://java.sun.com/products/jdk/1.2/docs/api/java/net/URL.html

Perhaps we could just drop the authentication creadentials and pass them
as QUERY_STRING parameters instead. In practice it would probably be
easier to work with anyway instead of piecing together user info to build
a full URL. Or maybe just drop the password field since it's the culprit
and source of security concerns cited elsewhere for obvious reasons.

Let's not loose the focus of the real problem here though. SMB servers
allow the '@' sign but the various URL RFC's do not. If we can circumvent
this one issue it will not be necessary to URL encode/decode anything.

> 
> As with most parsers, there is an operator hierarchy.  I *think* that the
> '/' character is higher precedence than th '@' but I am not sure, as I
> haven't looked at it recently.

I don't see how assigning precidence helps.

Mike

-- 
May The Source be with you.