[jcifs] jcifs encoding issue with NtlmHttpFilter and IE 6.0

[Michael B Allen]

On Wed, 29 Mar 2006 09:50:06 -0800
"David Sprowls" <ctasprowls at fastmail.fm> wrote:

> I just upgraded from jcifs 1.2.7 to 1.2.8.  Everything works fine if I
> use a mozilla based browser; however, if I use Internet Explorer, I get
> an unsupported encoding exception.
> 
> java.io.UnsupportedEncodingException: Cp850
> sun.io.Converters.getConverterClass(Unknown Source)
> sun.io.Converters.newConverter(Unknown Source)
> sun.io.ByteToCharConverter.getConverter(Unknown Source)
> java.lang.StringCoding.decode(Unknown Source)
> java.lang.String.<init>(Unknown Source)
> java.lang.String.<init>(Unknown Source)
> jcifs.ntlmssp.Type1Message.parse(Type1Message.java:236)
> jcifs.ntlmssp.Type1Message.<init>(Type1Message.java:86)
> jcifs.http.NtlmSsp.authenticate(NtlmSsp.java:88)
> jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:160)
> jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
> 
> I see that the default encoding was changed from file.encoding to
> "Cp850" in NtlmMessage.java.
> 
> If I set jcifs.encoding to cp1252, then the problem is resolved.

I'm not sure Cp1252 is quite right. Cp850 and Cp1252 are totally
different. If characters above 0x7f are encountered they will be decoded
incorrectly if the wrong encoding is used. Specifically if you have share
names or passwords with these characters (or Unicode is not negotiated)
the shares will be displayed incorrectly or plaintext authentication
may fail. This is very unlikely to impact the average user of the NTLM
HTTP authentication filter however so your using Cp1252 is fine. I need
to investigate which encoding is really used by Win2K3 server.

> I am running NtlmHttpFilter in Tomcat 5.5 on windows 2000 sp3 with JRE
> 1.5.0_06
> 
> Why must I suddenly set the encoding, and why is it only a problem for
> IE?

I don't know why it would only be a problem for IE. I guess the NTLMSSP
messages that IE sends have some non-Unicode strings that trigger the
decoding.

I'm not quite positive as to how I should resolve this issue. The
Cp850 converter is in jre/lib/charsets.jar. Cp1252 is in
rt.jar. Apparently charsets.jar is not loaded by default and thus the
UnsupportedEncodingException. I suspect the answer will indeed be to use
Cp1252 even though it may not be right just so that users don't have to
trip over some obscure character encoding mumbo jumbo.

Mike