[jcifs] Re: SMB URL encoding/decoding

[Michael B Allen]

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

> > 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
> 
> Which arbitrary characters?  This is where precedence comes in.  If you
> parse based on the '/' character first (and escape any '/' characters in the
> <server> string) then you will never get confused by '@'s elsewhere in the
> URL.

You can have ANY characters in a password. So there's NO way to traverse
it. You HAVE to come in from the end looking for something and when I did
this it was determined that '@' was what I looked for. I don't remember
exactly why I did what I did but I rememeber mulling it over pretty hard.

> 
> I will try to get time to look at the link above.
> 
> > Perhaps we could just drop the authentication creadentials and pass them
> > as QUERY_STRING parameters instead.
> 
> No, because the generic URL/URI syntax already supports the use of
> credentials as part of the <server> field.  RFC2396:

Ok, nobody seems to like that idea. Forgotten.

> > > 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.
> 
> Consider:
> 
> ftp://user:pass@foo.com/some/dir/im@home/text.txt
> 
> If the '/' has precedence over '@' then the parse tree is (roughly):
> 
>                         ["://"]
>                           / \
>            [scheme: "FTP"]  ['/']
>                              / \
> [server: "user:pass at foo.com"]  [abs_path: "some/dir/im at home/text.txt"]

Well, then assigning "operator hierarchy" is inherent to parsing. I
wasn't sure what you meant. At any rate, you can't do this because '/'
can appear in a password. It's a pretty rare character to appear in a
password though. I suppose we could make users URL encode a '/' in the
password and then disect by '/' like you have above. That would be
wonderfully easy actually and cause far less confusion.

Mike

-- 
May The Source be with you.