[jcifs] Re: SMB URL encoding/decoding
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.
>>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
>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.
More information about the jcifs