[jcifs] Re: SMB URL encoding/decoding

[James Nord]

Christopher R. Hertel wrote:

>James Nord wrote:
>:
>
>>>I'm not sure what you mean by "we are only allowed" but none of the
>>>above is true (which may be your point). You cannot count certain
>>>characters. The password field could have three ':' or fifteen '@'s in
>>>it. It can have anything. *That's* the real problem.
>>>
>>No it can not.
>>
>>again password != password field
>>
>>the password field cannot contain any of,
>>
>>      reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
>>                      "$" | ","
>>
>>(note that is not an exhaustive list we also have öäåÖÄÅ....)
>>
>
>Much easier to denote what the field may contain.  :)
>
>It may contain anything that <userinfo> may contain, including a colon.  The
>*first* colon in <userinfo> is used as a delimiter.  
>
But the *smb url draft* does not allow for more than one colon in the 
userinfo part.

      smb_server    = [ [ smb_userinfo "@" ] smb_srv_name [ ":" port ] ]

      smb_userinfo  = [ ntdomain ";" ] username [ ":" password ]
      ntdomain      = *( unreserved | escaped |
                         "&" | "=" | "+" | "$" | "," )
      username      = *( unreserved | escaped |
                         "&" | "=" | "+" | "$" | "," )
      password      = *( unreserved | escaped |
                         "&" | "=" | "+" | "$" | "," )



>Since the <password>
>field is specifically not defined by the BNF grammar given in the RFC we
>don't have anything that says it can't contain a colon.
>...yes, I'm really annoying when it comes to fine details.
>
Then you deviate in your definition of the SMB URL draft (see above)

>
>
>Since
>
>        userinfo    = *( unreserved | escaped |
>                         ";" | ":" | "&" | "=" | "+" | "$" | "," )
>
>and we are allowing for
>
>        userinfo    = user [ ":" password ]
>
>we have
>
>        password    = *( unreserved | escaped |
>                         ";" | ":" | "&" | "=" | "+" | "$" | "," )
>
Ah, doesn't the draft have precedence in this case over the URL RFC as 
it is more explicit.
(yes draft changing work in progress etc...) but I always look at the 
most specific ;-)

/James