No guru available? I just want to know what is the official roadmap regarding streaming. Has it changed away from the documented features or is it maybe currently unknown? Or is it just a personal problem of my installation? Any hint would be welcome so I can figure out what to do next...
Thanks, Andreas On 9/14/07, Andreas Sahlbach <[EMAIL PROTECTED]> wrote: > > Hi xmlrpc-gurus! > > I am trying to migrate my projects from xmlrpc 2.0 to xmlrpc 3.1. I need > to migrate one of the clients and the server, so I am very interested, that > this part of the documentation is true: > > > If streaming mode is disabled, then the server will always behave like a > standard XML-RPC server. Otherwise, the server will verify, whether the > client sends a content-length header. If so, then the server assumes that > > the client is able to accept a missing content-length header in the > response as well. Otherwise, the server will still disable streaming for > this particular requests. In other words, traditional clients will still > receive a traditional > response and one server can serve both data types. > > Unfortunately during verification of this I encountered two problems: > > 1) client: I am using the sun classes on a linux system. It looks like > that it doesn't actually matters if I set contentLengthOptional and > enabledForExtensions to tue or false. The request _always_ contains a > content-length header. I debugged it but couldn't find place, where this > header is added. I found the place in the client where the configuration was > correctly read out and where the client was skipping the part to add this > header. But nevertheless my request contains a content-length header at the > end (I am using wireshark to sniff the network traffic). In the case I set > the two configurations to true, the content-length header is always the last > header in the header section. Can it be, that java is adding the > content-length header by itself? If this is the case then using the > content-length header for detection if the server should answer in streaming > mode or not is not working! > > 2) server: I actually can't find the part in the sources where the server > is honoring the content-length header in the request. It looks like the > server is acting in streaming mode if I set both options to true and is not > acting in streaming-mode, if I set both options to false. At least that is > wireshark telling me. Could you give me a pointer to the code part that is > doing the magic as stated in the documentation? > > I don't want to nit-pick, but not becoming incompatible is essential for > my service. Within the enterprise of my customer a number of clients are not > under my control and I am in deep shit if they stop working :) > > Thanks for your time guys! > -- Andreas Sahlbach
