[jcifs] Re: SMB URL encoding/decoding

[James Nord]

by the way,

|the example on |http://jcifs.samba.org/src/docs/api/jcifs/smb/SmbFile.html
|
     smb://Administrator:P@ss@msmith1/c/WINDOWS/Desktop/foo.txt|
            - A relativly sophisticated example that references a file 
|msmith1|'s desktop as user |Administrator|.

Is this not illegal according to the draft?

/James

Christopher R. Hertel wrote:

>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?
>>
>
>