[jcifs] SmbURL's with @'s in the path portion

[Allen, Michael B (RSCH)]

Like I was saying I sort of side stepped the problem. To implement the spec properly I would
need to just do a URLDecode on the path component in SmbURL.java. I just didn't do it. In
reptrospect this was probably dumb because it doesn't really cost that much compared to
doing network IO. I will try to add it in my current dev. I think all you need to do though is find
the spot in SmbURL.java where the 'path' is finalized and call java.net.URLDecoder.decode (or
whatever it's called). That will decode the string properly first. I think it will work then. Right
now it will use the ..om+%40+... literally which of course doesnt match ..om @ Cann..

Incedentally there was a big discussion about precisely this case when the SMB URL spec
was being drafted up. IOW there are no other cases as troubling as this and there is no way to
avoid it. Trust me, people have spent some time thinking about it.

Mike

> -----Original Message-----
> From:	rjw [SMTP:rob at wygand.com]
> Sent:	Wednesday, November 14, 2001 8:52 PM
> To:	jcifs at samba.org
> Subject:	Re: [jcifs] SmbURL's with @'s in the path portion
> 
> Mike,
> 
> I added some encoding to my code such that my URL's now look like:
> 
> mb://rob:password@hostname/sharename/foo/Mom+%40+Cannes
> 
> However, now when I create an SmbFile from this URL, canRead(), 
> canWrite(), isDirectory() and isFile() all return false. This is not the 
> behaviour I expected.. namely, isDirectory() and isFile should still 
> return properly.
> 
> Is it just that under the covers, because I am encoding first, something 
> wacky is goin' on?\
> 
> rjw
> 
> 
> Allen, Michael B (RSCH) wrote:
> 
> > In accordance with the SMB URL IETF draft all characters not of the defined set suitable for
> > use with URLs (I beleive the HTTP spec was referenced here) must be encoded with the
> > standard %code encoding.
> 
> 
> -- 
> "They that can give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
> 
>