[jcifs] SMB URL parsing [jcifs-0.7.0b5 released]
Allen, Michael B (RSCH)
Michael_B_Allen at ml.com
Wed Oct 23 13:46:54 EST 2002
> -----Original Message-----
> From: Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> Sent: Tuesday, October 22, 2002 11:29 PM
> To: Allen, Michael B (RSCH)
> Cc: jcifs
> Subject: Re: [jcifs] SMB URL parsing [jcifs-0.7.0b5 released]
> On Tue, Oct 22, 2002 at 07:49:54PM -0400, Allen, Michael B (RSCH) wrote:
> > > -----Original Message-----
> > > From: Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> > > Sent: Tuesday, October 22, 2002 5:25 PM
> > > To: Michael B. Allen
> > > Cc: jcifs
> > > Subject: Re: [jcifs] jcifs-0.7.0b5 released
> > >
> > > Ah. This is what I was missing when I read your questions about URL
> > > parsing a while back. Sorry I was being dense...
> > >
> > > * URLs that represent workgroups, servers, shares, or directories
> > > must have a trailing slash '/'.
> > >
> > > That's a problem from a user-interface point of view. People are used
> > > to entering http://yahoo.com and getting yahoo.com. No trailing slash.
> > > I am surprised that the java.net.URL class doesn't handle this sort of
> > > thing.
> > >
> > This is true of http URLs so no surprise here. If you leave off the
> > slash the server will reply with an error.
> The server will, because the server is expecting correct syntax. It's not
> dealing directly with users.
> > The browsers have been given the brains necessary to try again with
> > a slash which is what jCIFS users will be required to do to their
> > applications.
> Those brains need to be on the client side, as with the browser. Since
> jCIFS is client code, I'm thinking that these features could be coded up
> and included with the toolkit to avoid wheel-reinvention.
> > This actually isn't as much of a problem as you might think. For
> > certain applications (crawlers, file browsers) it would have been
> > annoying if you are composing URLs with the parent SmbFile + getName()
> > where the name of a directory didn't have a '/'.
> Yes, I understand that the internal representation of the name must be
> "correct" so that it can be manipulated correctly. That makes sense.
> > To get around this problem I have changed getName() to include the
> > '/' of the SmbFile is a directory.
> Makes sense.
> > > * Canonicalization does not exceed the host component of the URL. So
> > > smb://host/share/path/ + ../../../../foo/ is canonicalized to
> > > smb://host/foo/ whereas previously the client would have reduced this
> > > to smb://foo/.
> > >
> > > That's also a problem, but it may be a problem with the SMB URL format
> > > rather than java.net.URL. I don't know of any other URL form that
> > > assigns meaning to <scheme>:// the way the SMB URL does. That's a
> > > question for the URL gurus. It may be inherently broken.
> > It may be possible to intercept this scenario but it was never clear
> > to me that it is problematic. It's awkward when using SmbShell
> > (which I fixed BTW) but consistent with what happens when you
> > compose a URL like smb://server/share/path/to/file + /some/thing/else
> > which gives smb://server/some/thing/else. Meaning the root of the
> > "filesystem" really starts after the server. But this is debatible
> > of course.
> It is also not clearly defined by the SMB URL specification. That is:
> what is the meaning of "smb://name" + ".."?
This will become smb://name/. Note that if this had been
smb://server/path/to/name + .. you would get smb://server/path/ because
name did not end with a slash. If you had smb://server/path/to/name/ + ..
this would give smb://server/path/to/. Gotcha!
More information about the jcifs