[jcifs] Re: SMB URL encoding/decoding

[Christopher R. Hertel]

Michael B Allen wrote:
:
> > MIME may decode the "+" at the MIME level, before it becomes visible
> > as a URL string...  I'm just guessing.  I don't have a lot to go on,
> > just that I looked through and found examples in the RFC where a space
> > was translated to %20 but no mention of "+" being used.
> 
> Actually it's important that we do not use Java's URLDecoder then. Since
> we have to run all paths through a decoder routine any '+' would have
> to be escaped if we used java.net.URLDecoder. We should provide our
> own decode() that' *does not* decode '+'. If of course a user uses '+'
> they will get File not found or create files with '+' but that would be
> user error because a) they shouldn't be enoding path components b) it's
> not defined by the spec and c) they should use the jCIFS provided
> decode(). I wonder why Java didn't stop encoding the '+'. I guess if
> they decode it they have to encode it too and either way they start to
> ruin backwards compatability.

I'm going to weigh in with a big "I haven't a clue" on this one.

The problem with path components (and I think that this is a problem in
the RFC) is that the permitted character set is different than in other
parts of the URL.  Eg:

      pchar         = unreserved | escaped |
                      ":" | "@" | "&" | "=" | "+" | "$" | ","
vs.

      userinfo      = *( unreserved | escaped |
                      ";" | ":" | "&" | "=" | "+" | "$" | "," )


So the problem is that you need to escape a ';' if you want to use it in a
path, but not if you use it in <userinfo>, and you have to escape an '@' if
you want to use it in <userinfo> but not in the path.

Boink.

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