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

/James





More information about the jcifs mailing list