XML-RPC
  1. XML-RPC
  2. XMLRPC-148

Streaming mode not working as documented

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Gentoo / Sun JDK 1.6

      Description

      Here is my mail posted in the developer mailing list describing the issue(s):
      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!

      1. streaming.patch
        25 kB
        Andreas Sahlbach
      2. xmlrpc.patch
        2 kB
        Andreas Sahlbach

        Issue Links

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              Andreas Sahlbach
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development