[jcifs] Annoying SMB URL question.

Michael B. Allen miallen at eskimo.com
Mon Dec 9 22:09:08 EST 2002

On Mon, 9 Dec 2002 05:08:54 -0500
"Glass, Eric" <eric.glass at capitalone.com> wrote:

> Just beating a dead horse -- I would think the escaped-backslash syntax
> (i.e., DOMAIN%5Cuser) would be more consistent, given that
> a) The DOMAIN\user syntax is most widely used by the MS tools
> b) You can already do http://DOMAIN%5Cuser:pass@webhost for NTLM-protected
> content on IIS webservers (not entirely relevant, I know, but maybe
> worthwhile for consistency's sake)

Not even going to discuss these first two arguments.

> c) Selecting ";" simply because it doesn't have to be escaped doesn't really
> buy you anything; to be correct, your applications will still have to be
> able to unescape whatever separator is chosen.  i.e.:

But ';' does not *require* you to use an escape whereas using '\' does
if the URLs are going to travel. You might as well say "lets use '%3b'
as the domain user separator".

> smb://DOMAIN%3Buser:pass@server
> is just as valid as:
> smb://DOMAIN;user:pass@server
> Basically, you still have to be able to do a hex to char conversion to cover
> the possibility that the user simply chose to escape the separator.
> Just my two cents.  On another note (out of curiosity), in my environment we
> have two domains (for example, "DOM1" and "DOM2") which I'm assuming are set
> up with some sort of trust relationship; that is, I can log into box
> "server" which is a member of DOM2 using my account "eric" in DOM1.  How
> would that be represented in a URL, where my user credentials are for an
> account in one domain ("DOM1\eric"), but I am accessing a resource on a
> server which is a member of another domain ("DOM2\server")?

I don't know if the domain that this server is a member of differs from
it's workgroup but if there is any semantic difference I don't know
of any case where that would need to be represented with an SMB URL. A
"server that's a member of a domain" is not an addressable resource.

> Eric
> > -----Original Message-----
> > From: Conrad Minshall [mailto:conrad at apple.com]
> > Sent: Friday, December 06, 2002 3:44 PM
> > To: Christopher R. Hertel; Matthew Tippett
> > Cc: jcifs at samba.org
> > Subject: Re: [jcifs] Annoying SMB URL question.
> > 
> > 
> > At 11:54 AM -0600 12/6/02, Christopher R. Hertel wrote:
> > 
> > >>  Which begs the question, if the domain is used for 
> > authentication, why
> > >>  not leave the user field in the userinfo section of the URL as
> > >>
> > >>    DOMAIN%5Cuser
> > >>
> > >>  Since the domain is an integral part of the credentials.
> > >
> > >The application (the client parsing the URL string and 
> > converting it into
> > >SMB calls) needs to parse the NTDomain from the username.  
> > You are right
> > >that we could have chosen to separate the two using an 
> > escaped backslash
> > >or, perhaps an escaped percent sign.  Instead, we found that the
> > >semi-colon did not need to be escaped in the username field 
> > and could be
> > >used as a separator.
> > >
> > >It just seemed easier and more readable to use the semicolon.
> > 
> > Yes.  Having all separators unescaped means I can look at a URL and 
> > ignore escape sequences rather than doing a hex to char on each to 
> > see if it is important. 
> > 
> **************************************************************************
> The information transmitted herewith is sensitive information intended only
> for use by the individual or entity to which it is addressed. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.

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. 

More information about the jcifs mailing list