[jcifs] Re: SMB URL encoding/decoding

[Christopher R. Hertel]

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
that most of the browsers out there have generic URL parsers.  Java also has
a generic URL parser, IIRC.

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.  (Last week, you caught me as I was writing
the section of my book that describes the NODE STATUS QUERY...which is why I
was in top form.  ;)

The last few comments that I got regarding the SMB URL were from the authors
of RFC 2396.  I need to integrate their comments into the draft...when I get
some time.  Good stuff.  Very good stuff.

See RFC 2396, Appendix A. Collected BNF for URI

That's a first cut at answering the question.  I hope I'll be able to
provide more useful information later on.

Chris -)-----

Michael B Allen wrote:
> 
> On Sat, 23 Feb 2002 15:38:23 +0100
> James Nord <teilo at teilo.net> wrote:
> 
> > >>ftp://user:pass@foo.com/some/dir/im@home/text.txt is valid no?
> > >>
> > >
> > >Nope. We search for the '@' from the end.
> > >
> > Erm why search for the @ at all (see below for explanation)
> >
> > Ah anyway I see you have reserved the "@" from the smbpath.  but read
> > on. It is allowed in RFC 1738 for the ftpurl (or it was last night when
> > I returned from the pub :-/ )
> >
> > >>But Seeing as a '/' is a reserver char in usernames/pass it would need
> > >>to be escaped here?
> > >>
> > >We don't do encoding/decoding on everything after the server
> > >component.
> > >
> >
> > >This may not be perfectly legit according to the language
> > >layers but there's no way I'm going to URL encode my password and server
> > >names cannot have '@' signs in them so...
> > >
> > OK, I can follow your logic
> >
> > <SNIP for reference>
> >
> > smb_server    = [ [ smb_userinfo "@" ] smb_srv_name [ ":" port ] ]
> >
> > smb_userinfo  = [ ntdomain ";" ] username [ ":" password ]
> >
> > username      = *( unreserved | escaped |
> >                          "&" | "=" | "+" | "$" | "," )
> >
> > password      = *( unreserved | escaped |
> >
> >                          "&" | "=" | "+" | "$" | "," )
> >
> > </SNIP>
> >
> > But what happens for instance if my password is "password at foo/"?
> > My point is that you reservere the / and @ in anycase from user/pass so
> > this is illegal in the smburl - we must encode.  so then we are left
> 
> So if my password is 'mba at 2foo' I have to do:
> 
>   smb://miallen:mba%402foo@server/c$/My Documents/seti at home.txt
> 
> I don't know. The URL decoding/encoding issue deserves work but a *lot*
> of people have '@' signs in their password. Is '\' reserved? Maybe that
> could be confiscated as a cheesy escape so we can do:
> 
>   smb://miallen:mba\@2foo@server/c$/My Documents/seti at home.txt
> 
> The language lawers would probably baulk at that one.
> 
> In hindsight it is compelling considering that damn '@' sign is the
> whole reason we need to escape everything.
> 
> > with the / following the server.
> > why not use this as the delim
> >
> > smb://user:pass@server/
> > everything before the first / must be [user[:pass]@]server? and as
> > *both* @ and : are *reserved* you know uniqly what is user/pass/server?
> > And then you can unreserve @ from path alla the ftpurl?
> >
> > Comments?
> 
> 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