[jcifs] java.net.URL for SMB URL not quite right

[Christopher R. Hertel]

"Allen, Michael B (RSCH)" wrote:

Now that my brain isn't stuck in a mobius bagel...

> > -----Original Message-----
> > From: Michael B. Allen [SMTP:miallen at eskimo.com]
> > Sent: Monday, October 07, 2002 4:44 AM
> > To:   Christopher R.Hertel; jcifs at samba.org
> > Subject:      [jcifs] java.net.URL for SMB URL not quite right
> >
> > The  java.net.URL class parses everything ok except for plain 'smb://'
> > URLs and URLs derived from them. For example:
> >
> > smb://             --> smb:

That's annoying.

> > smb:// + foonet/   --> smb:/foonet/
> > smb:// + //foonet/ --> smb://foonet/
> > smb:////           --> smb://

I have been paying so much attention to the rest of the URL structure
that I have to admit that my understanding of the use of the // is not
up to speed.

> > You  can  see that this breaks the current model a bit. If a user
> > creates a
> > URL with 'smb://' the various java.net.URL.getXxx methods return:
> >
> >    authority:
> >         file:
> >         host:
> >         port: 139
> >         path:
> >        query: null
> >          ref: null
> >     userinfo: null
> > externalform: smb:
> >       string: smb:

Well, hmmm.  The RFC says:

   The authority component is preceded by a double slash "//" and is
   terminated by the next slash "/", question-mark "?", or by the end of
   the URI.  Within the authority component, the characters ";", ":",
   "@", "?", and "/" are reserved.

   An authority component is not required for a URI scheme to make use
   of relative references.  A base URI without an authority component
   implies that any relative reference will also be without an authority
   component.

[RFC2396, Sec.3.2]

So the "//" is considered part of the authority section.  That's fine by
me, but "//" should be an allowed authority section in and of itself, I
would think.  That means that the parser should return the above with
"authority: //".  ...but it doesn't.

> > I  can override the arguments so that passing 'foonet/' is substituted
> > with '//foonet/'  before  passing  it  to the default parser.  That
> > works ok, and makes  sense. I can trap the 'smb://' case and pass
> > 'smb:////' too but this
> > gives:
> >
> >    authority:
> >         file: //
> >         host:
> >         port: 139
> >         path: //
> >        query: null
> >          ref: null
> >     userinfo: null
> > externalform: smb://
> >       string: smb://
> >
> > As  you  can  see  this  hack makes the file and path '//' which makes
> > less sense  to me.

Agreed.  The "//" should be in the authority field.

> Actually overloading 'smb://' with 'smb:////' and
> 'smb://' + 'WORKGROUP/' with 'smb://' + '//WORKGROUP/'
> appears as though it may work fine. The '//' for the
> filename is a little strange but that is a bit of an exotic corner case
> that in theory should not cause a problem for anyone.

Would it be better to look for an empty authority field and assume that,
if authority is blank then you need to add "//" somewhere?  That would
mean:

  'smb://'                - Would be parsed into 'smb:' with the auth field
                            blank.
  'smb://' + 'WORKGROUP/' - The "smb://" would already be in java.net.URL
                            class format, so you check for a blank auth
                            field and add "//" to "WORKGROUP/".

> > Does this behavior gibe with your draft and RFC 2396 Chris? I
> > find  it  hard  to  believe Sun got it wrong. If java.net.URL is right
> > then what should proper semantics be for SMB URLs?

I don't know that the Java implementation is "wrong", per se.  It may be
that the case of "<scheme>://" being a valid URL is unique to the SMB URL.
That would be worth knowing, if true.  My guess is that this is a condition
that Sun did not need to consider, so it's not "wrong", exactly, just
"new".  There are lots of URL schemes which do not use the authority portion
at all.  Things like mailto: and, I think, news:.  The news: scheme
is probably worth looking at.

So my guess is that java.net.URL was written to handle both formats as they
existed.  When I can find time to get back to the draft I will ask the RFC
authors their thoughts on the matter.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org