[jcifs] Re: SMB URL encoding/decoding

[Christopher R. Hertel]

Michael B Allen wrote:
:
> Actually it should look for the '/' like you describe but then search
> *backwords* from there for the '@' so that even if there are more than
> one '@' it will still work because '@' will not appear in the server
> name.

Two things on that:
- Any '@' other than the one that separates the <userinfo> from the
  <hostport> should be escaped anyway.  If you try to accomodate
  un-escaped '@' signs then you are providing a user-friendly feature,
  which is a good thing.

- One gotcha, however, is that some other SMB URL implementer may do it a
  different way, searching from left to right.  In that case, the behavior
  is different for the same URL string in the same context using different
  implementations.

Since the non-escaped '@' would be against URL rules anyway, I think that
providing the user-friendly feature is okay.
- It's a feature
- It doesn't break anything else.
- If it's not the same as someone else's feature, well...tough.

> This way, only an unescaped '/' in the password would cause it to
> fail. This is really much better than what we're doing now the more I
> think about it. No one ever uses '/' in a password. I can't beleive I
> didn't do that originally. It would have been soooooo much easier.

The whole URL string "should" be escaped to be "correct", but that's the
theory side of the house talking.  As I said a while ago, Netscape can
rendor really bad HTML.  I've seen some of the stuff it manages to display.
Ick.  Making jCIFS resilient to users who (*gasp*) don't quite grok the
details of URL syntax is probably a very good idea.

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