[jcifs] SMB URL parsing buglet?

[Michael B. Allen]

On Thu, 05 Sep 2002 11:14:26 -0500
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:

> > For NetworkExplorer even the NetworkExporer code should encode those
> > paths.
> 
> Should?  I'm lost...

Yeah,  I botched that. NetworkExplorer appends paths to the end of the http
URL. So I guess even NetworkExplorer does not need to encode *SMB* URLs. It
needs  to encode the path component for inclusion in *HTTP* URLs. So only a
web browser/file manager type application that directly supported SMB would
really need an encoded SMB URL. 

> > I think the key here this very simple premise: You get out what you put
> > in.
> 
> Perhaps there should be two methods then.  One that returns what the user
> put in, and one that returns the corrected field.

These  URLs  are  used  almost entirely internally to applications. This is
fundamentally  different  from a protocol like HTTP where the URL is passed
to  a  server  process and interpreted. CIFS does not identify resources by
URL. We introduced that as a convenience for users. An application that did
transport SMB URLs over a network would be reponsible for encoding them. 

However,  I  agree  that  we  should provide a method that returns the full
encoded  URL because the jCIFS client is in a much better position to do so
oppose  to  an  application  using  jCIFS  because the URL would need to be
completely  re-interpreted  to  encode  it  properly.

This  is just for jCIFS of course. I'm not suggesting that the SMB URL IETF
draft  should not specify that SMB URL be encoded to be "proper". It's just
in  our  case  where  were  using  these  SMB URLs extensively interally to
identify resources. If we decoded and encoded a URL everytime a sub-SmbFile
were created like: 

f1 = new SmbFile( "smb://server/share/path" );
f2 = new SmbFile( f1, "additional/path" );

The   performace   impact   would  be  significant  for  certain  types  of
applications. When I rewrite the SmbURL parser I will add a getEncodedPath.
The  toString,  getPath,  and getCanonicalPath methods will return what was
given. 

> Personally, I would prefer to see the latter echoed back to me by a
> browser or other tool, but then I'm pedantic.  Since jCIFS is a toolkit
> providing methods for both means that the application writer can decide
> for themselves what it is they want to do.

Right.   The   "browser"   scenario   is  a  corner  case  so  it  can  use
getEncodedPath. 

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and more importantly to tasks that have not
yet been conceived.