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

[Allen, Michael B (RSCH)]

> -----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:
> smb:// + foonet/   --> smb:/foonet/
> smb:// + //foonet/ --> smb://foonet/
> smb:////           --> smb://
> 
> 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:
> 
> 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.
> 
> 
	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.


> 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? 
> 
> -- 
> 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 important, to tasks that have not
> yet been conceived.