[jcifs] Re: jcifs-0.9.4 released

[eglass1 at comcast.net]

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");
        Config.registerSmbURLHandler();
        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).

Eric

-------------- 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!

Eric
-------------- 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