[jcifs] RE: Lots of jCIFS stuff

eglass1 at attbi.com eglass1 at attbi.com
Fri May 23 23:06:52 EST 2003


> Eric,
> 
> Test.java doesn't work for me. Does this work with our own NTLMSSP server
> implementation. Did something change in 1.4 that affects getResponseCode()?
> 
> java.io.IOException: Server returned HTTP response code: 401 for URL: 
> http://httpserver.com:800/servlet/NetworkExplorer/smbserver/
>         at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.jav
> a:562)

This was a bug in various versions.  Basically, getResponseCode() used to do:

if (responseCode != -1) return responseCode;
// ensure headers have been read
getInputStream();
String response = getHeaderField(0);
// parse response header to get response code

The problem was that getInputStream() threw a FileNotFoundException if the
response code was > 400.  This was "fixed" by throwing a FileNotFoundException
only if the response code was 404 or 410, and throwing a generic IOException
for other 400+ codes -- which didn't really solve the original problem, since
getResponseCode() still ended up barfing.

They finally ended up (I believe) fixing it by doing something like:

if (responseCode != -1) return responseCode;
try {
    getInputStream();
} catch (Exception ex) {
    // store the exception for later if needed
    cachedEx = ex;
}
String response = getHeaderField(0);
// parse response header to get response code

The attached fix manually parses the response code (rather than relying on
getResponseCode()), which should hopefully fix the issue you are seeing.  I'm
not sure which exact revision you're running, but "java -version" should tell
you.

Also, in some older revisions keep-alives were broken as well (disconnecting
on 400+, rather than when the server explicitly indicated such).  I have tested
against 1.3.1_03, and it appears to work properly.  This wouldn't be an issue
connecting to the jCIFS servers (since we don't require a persistent
connection), but would be when connecting to IIS (since they do).  There isn't
too much we could do about this without actually implementing a full-blown
HttpURLConnection implementation.

> Do those 5 classes need to be in the jcifs.smb package? I can publicise the
> get*NtlmResponse() methods. Perhaps we should create a jcifs.ntlmssp package?
> 

They are only in the jcifs.smb package because they require the
get*NtlmResponse() stuff.  I would concur with this recommendation; they don't
really belong in jcifs.smb.

Also (on a completely unrelated note) NtlmHttpServletRequest should probably
override getAuthType() to return "NTLM" -- don't know why I didn't notice
that previously.

Eric

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 16620 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030523/aaea6011/attachment.obj


More information about the jcifs mailing list