[jcifs] SMB URL parsing [jcifs-0.7.0b5 released]

[Allen, Michael B (RSCH)]

> -----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!