[jcifs] SMB URL parsing buglet?
Michael B. Allen
miallen at eskimo.com
Fri Sep 6 18:13:04 EST 2002
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
> 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
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.
More information about the jcifs