[jcifs] Re: jcifs-0.9.4 released

eglass1 at comcast.net eglass1 at comcast.net
Wed Jun 30 15:54:37 GMT 2004

I think I see the issue -- are you using XmlRpcClientLite?  That implementation
uses sockets directly, rather than HttpURLConnection.  The user agent string
from your previous post seemed to match what that client sends, which would
account for this behavior (also the "Unexpected response from server" message).
If so, try using org.apache.xmlrpc.XmlRpcClient and see if that works properly.


-------------- Original message -------------- 

Hmmm. Here's the test class I slapped together, using Apache XML-RPC
version 1.2-b1:

import java.util.Vector;
import jcifs.Config;
import org.apache.xmlrpc.XmlRpcClient;
public class TestXmlRpc {
public static void main(String[] args) throws Exception {
Config.setProperty("jcifs.smb.client.domain", "TEST");
Config.setProperty("jcifs.smb.client.username", "Administrator");
Config.setProperty("jcifs.smb.client.password", "admin");
XmlRpcClient xmlrpc = new XmlRpcClient("http://test2/getPing.asp");
System.out.println(xmlrpc.execute("getPing", new Vector()));

I noticed your previous post mentioned you were getting an "Access denied"
error back; this may be relevant, as I wasn't seeing any error at all
(just a hang). It may indicate that the jCIFS handler isn't getting
loaded, or something else funky is happening. Try inserting a couple
of println statements in NtlmHttpURLConnection (i.e. at the top of the
connect method or similar).


-------------- Original message -------------- 

Sorry, this didn't change anything for me. May it be there's something tricky going on within Apache XML-RPC?
----- Original Message ----- 
From: eglass1 at comcast.net 
To: Alexander Langer ; Michael B Allen 
Cc: jcifs at lists.samba.org 
Sent: Wednesday, June 30, 2004 12:42 PM
Subject: Re: [jcifs] Re: jcifs-0.9.4 released

Fixed! There were two things going on:

1) The XmlRpcClient doesn't explicitly set the request method
(i.e., setRequestMethod("POST"). The underlying connection
apparently switches from "GET" (the default) to "POST" when
a write is actually attempted; this seems to be undocumented
behavior, so it's probably not good that they rely on it. In
any case, this was causing jCIFS to send a "GET" on the second
request (since that's what our wrapper connection thought it
was doing). I fixed this by adopting the final status of the
current underlying connection before reconnecting.
2) We send the POST content initially (at the first POST attempt)
and with the Type 3 message (the third POST request); we don't
send it with the Type 1, since the server is expected to reject
the request with a Type 2 message. The XmlRpcClient had set
the content length explicitly however, so we were sending
Content-Length=xxxx with no content; this was causing IIS to block
on a read (as it was expecting to get xxxx bytes). I fixed this
by setting content length to 0 on the Type 1 request.

Attached is the updated version, along with an example trace; let
us know if this works properly, and I'll see if Mike would be kind
enough to release. Thanks!

-------------- Original message -------------- 

> ----- Original Message ----- 
> From: "Michael B Allen" 
> To: "Alexander Langer" 
> Cc: 
> Sent: Wednesday, June 30, 2004 9:36 AM 
> Subject: Re: [jcifs] Re: jcifs-0.9.4 released 
> > 
> > Have you verified that it works without NTLM? Maybe there's something 
> > more fundamental going on. Send me a capture and I'll have a look [1]. 
> > 
> Yes, it works without NTLM.. See attached dump. 
-------------- next part --------------
HTML attachment scrubbed and removed

More information about the jcifs mailing list