[jcifs] Re: SMB URL encoding/decoding

James Nord teilo at teilo.net
Sun Feb 24 13:50:07 EST 2002

Michael B Allen wrote:

>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
>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.
err yes in a password but not in a *password field* of a URI

password field in URI != password

password field = urlencode (password)

>>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.
>>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. 
Again don't confuse password with password field

>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. 
You have to...

>That would be
>wonderfully easy actually and cause far less confusion.
see above


More information about the jcifs mailing list