XML-RPC
  1. XML-RPC
  2. XMLRPC-171

unable to send the B64encoded data

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Testing

      Description

      My Application is a java application which uses xml-rpc communication with a server which is developed in php.
      the server has one service ( storePhotos) which accepts texti-id( which is a string) and the photoData( which is an encoded data of B64) ..

      it works very well if the size of the file which i am converting to B64 is < 60Kb. but it is failing if the size of the file is more than this.
      the exception which is being thrown by the server is "Parse error. Request not well formed."

      If the request is not well formed .. it should throw the same exception in the case if the file size is <60 Kb, which is not happening..
      but if the file size is greater than 60KB, it is throwing the above mentioned error.

      How can i rectify this?
      please advice me, as this is a sorce stopper for me to go ahead..

      Thanks,
      Jagadeesh

      1. success.pcap
        27 kB
        Jagadeesh Uppala
      2. failure.request.gz
        172 kB
        Jochen Wiedmann
      3. failure.pcap
        302 kB
        Jagadeesh Uppala

        Activity

        Hide
        Jochen Wiedmann added a comment -

        Are you sure, it is the server who creates the message "Parse error"? The more likely reason is that the server fails and creates an invalid response. (For example, by adding PHP strings at an anvalid location.)

        Anyways, please use tcpdump, wireshark, or a similar tool to trace the conversation between client and server and attach it to this bug report.

        Show
        Jochen Wiedmann added a comment - Are you sure, it is the server who creates the message "Parse error"? The more likely reason is that the server fails and creates an invalid response. (For example, by adding PHP strings at an anvalid location.) Anyways, please use tcpdump, wireshark, or a similar tool to trace the conversation between client and server and attach it to this bug report.
        Hide
        Jagadeesh Uppala added a comment -

        Jochen Wiedmann,

        Thanks for working on this ticket.

        I have taken the help of wireshark application to trace the request and response from client to server and response.

        I have seen this error coming from server...
        The servers method name is : device.storePhoto
        and the parameters for that service are
        1) Session id which is a string
        2) textId which is a String
        3) type which is a String
        4) caption which is String
        5) data which is an B64 encoded string. [ the jpg image file which was encoded to B64 data is being sent as part of this field]

        The application is working fine if it is sending the photo data which is < 60Kb. but failing for the photosize which is more than this.

        Show
        Jagadeesh Uppala added a comment - Jochen Wiedmann, Thanks for working on this ticket. I have taken the help of wireshark application to trace the request and response from client to server and response. I have seen this error coming from server... The servers method name is : device.storePhoto and the parameters for that service are 1) Session id which is a string 2) textId which is a String 3) type which is a String 4) caption which is String 5) data which is an B64 encoded string. [ the jpg image file which was encoded to B64 data is being sent as part of this field] The application is working fine if it is sending the photo data which is < 60Kb. but failing for the photosize which is more than this.
        Hide
        Jochen Wiedmann added a comment -

        I have isolated the request document from your failure.pcap file and can't find anything wrong with it. Of course, the base64 section is relatively large, but definitely no reason to consider it anything but well formed.

        In other words, I do believe that the PHP server is wrong and should be checked. I recommend consulting the PHP bug tracker or whatever is responsible for the server side code. Which is, of course, beyond this issues scope. Therefore I intend to close it as INVALID. You may reopen it later on, should my findings turn out to be wrong.

        Show
        Jochen Wiedmann added a comment - I have isolated the request document from your failure.pcap file and can't find anything wrong with it. Of course, the base64 section is relatively large, but definitely no reason to consider it anything but well formed. In other words, I do believe that the PHP server is wrong and should be checked. I recommend consulting the PHP bug tracker or whatever is responsible for the server side code. Which is, of course, beyond this issues scope. Therefore I intend to close it as INVALID. You may reopen it later on, should my findings turn out to be wrong.
        Hide
        Jochen Wiedmann added a comment -

        Closing as invalid, most likely problem in the PHP server. Reopen later, if required.

        Show
        Jochen Wiedmann added a comment - Closing as invalid, most likely problem in the PHP server. Reopen later, if required.
        Hide
        Jagadeesh Uppala added a comment -

        Jochen Wiedmann,

        i have reported the issue with the guy who has done the PHP Server coding.
        He wrote the RPC client in PHP and injected the xmlpayload and the service didnt report any fault.. and it is storing the image into the server( which it is intended to )

        In our case I suspect the XMLRPC client is not sending the full xml if it is long.. that might be the reason for the error message which was thrown by the PHP server..

        Please advice me how to proceed

        Show
        Jagadeesh Uppala added a comment - Jochen Wiedmann, i have reported the issue with the guy who has done the PHP Server coding. He wrote the RPC client in PHP and injected the xmlpayload and the service didnt report any fault.. and it is storing the image into the server( which it is intended to ) In our case I suspect the XMLRPC client is not sending the full xml if it is long.. that might be the reason for the error message which was thrown by the PHP server.. Please advice me how to proceed
        Hide
        Jochen Wiedmann added a comment -

        I think you don't understand the methodology.

        You have traced the request (creating the failure.pcap file). I have extracted the payload and used an XML parser to parse it - nothing wrong. There is nothing like "not sending the full xml", otherwise it wouldn't have been in the .pcap file.

        Sorry, but I can't offer any further help. If the PHP server insists that something's wrong, he should at least offer a more detailed diagnosis like line and column number, or whatever.

        Show
        Jochen Wiedmann added a comment - I think you don't understand the methodology. You have traced the request (creating the failure.pcap file). I have extracted the payload and used an XML parser to parse it - nothing wrong. There is nothing like "not sending the full xml", otherwise it wouldn't have been in the .pcap file. Sorry, but I can't offer any further help. If the PHP server insists that something's wrong, he should at least offer a more detailed diagnosis like line and column number, or whatever.
        Hide
        Jagadeesh Uppala added a comment -

        Jochen Wiedmann ,

        Thanks for the pain which you are taking in helping me...

        I have written some test client which tries to push the arguments to the service..
        code is as follows
        ********************
        XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
        config.setServerURL(new URL("http://192.168.110.72/services/xmlrpc"));
        XmlRpcClient client = new XmlRpcClient();
        client.setTransportFactory(new XmlRpcCommonsTransportFactory(client));
        client.setConfig(config);
        File source = new File("Testing1.JPG");

        byte[] readfromjpgfile = new byte[(int) source.length()];
        FileInputStream jpgfileInputStream = new FileInputStream(source);
        jpgfileInputStream.read(readfromjpgfile);
        byte[] storetoafile = Base64.encode(readfromjpgfile);

        Object[] params = new Object[]

        { new String("d5ad8872afe4ded7893ef1fb5853451e"),new String("01-00915"), new String("installation"),new String("caption2"),storetoafile}

        ;
        Object result = (Object) client.execute("device.storePhoto", params);
        System.out.println("Result is "+result);
        ********************************************

        when i tried to run this , i am getting the below exception..
        could you please advice me what is the best data type which i can take inorder to send Base64 data?

        org.apache.xmlrpc.XmlRpcException: Parse error. Request not well formed.
        at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(XmlRpcStreamTransport.java:197)
        at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:156)
        at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTransport.java:115)
        at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:56)
        at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:167)
        at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:137)
        at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:126)
        at avanti.adc.test.Test.main(Test.java:55)

        Show
        Jagadeesh Uppala added a comment - Jochen Wiedmann , Thanks for the pain which you are taking in helping me... I have written some test client which tries to push the arguments to the service.. code is as follows ******************** XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl(); config.setServerURL(new URL("http://192.168.110.72/services/xmlrpc")); XmlRpcClient client = new XmlRpcClient(); client.setTransportFactory(new XmlRpcCommonsTransportFactory(client)); client.setConfig(config); File source = new File("Testing1.JPG"); byte[] readfromjpgfile = new byte [(int) source.length()] ; FileInputStream jpgfileInputStream = new FileInputStream(source); jpgfileInputStream.read(readfromjpgfile); byte[] storetoafile = Base64.encode(readfromjpgfile); Object[] params = new Object[] { new String("d5ad8872afe4ded7893ef1fb5853451e"),new String("01-00915"), new String("installation"),new String("caption2"),storetoafile} ; Object result = (Object) client.execute("device.storePhoto", params); System.out.println("Result is "+result); ******************************************** when i tried to run this , i am getting the below exception.. could you please advice me what is the best data type which i can take inorder to send Base64 data? org.apache.xmlrpc.XmlRpcException: Parse error. Request not well formed. at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(XmlRpcStreamTransport.java:197) at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:156) at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTransport.java:115) at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:56) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:167) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:137) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:126) at avanti.adc.test.Test.main(Test.java:55)
        Hide
        Jochen Wiedmann added a comment -

        Extracting from failure.pcap, I find the following conversation between client and server: That's odd, because there is no Base64 data i the request and the severs response contains no indication of any error.

        POST /services/xmlrpc HTTP/1.1

        Content-Type: text/xml

        User-Agent: Apache XML RPC 3.0 (Sun HTTP Transport)

        Content-Length: 234

        Cache-Control: no-cache

        Pragma: no-cache

        Host: 192.168.110.72

        Accept: text/html, image/gif, image/jpeg, ; q=.2, */; q=.2

        Connection: keep-alive

        <?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>user.login</methodName><params><param><value>noSessionIdYet</value></param><param><value>juppala</value></param><param><value>May@2009</value></param></params></methodCall>HTTP/1.1 200 OK

        Date: Thu, 14 May 2009 13:59:32 GMT

        Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch

        X-Powered-By: PHP/5.2.4-2ubuntu5.3

        Set-Cookie: SESS55a18b68ea846f044e66f52f419c3322=a70ae46d86fa5c8928bc7ea2e75dc0fa; expires=Sat, 06 Jun 2009 17:32:52 GMT; path=/

        Expires: Sun, 19 Nov 1978 05:00:00 GMT

        Last-Modified: Thu, 14 May 2009 13:59:32 GMT

        Cache-Control: store, no-cache, must-revalidate

        Cache-Control: post-check=0, pre-check=0

        Connection: close

        Content-Length: 463

        Content-Type: text/xml

        <?xml version="1.0"?>

        <methodResponse>
        <params>
        <param>
        <value><struct>
        <member><name>sessid</name><value><string>a70ae46d86fa5c8928bc7ea2e75dc0fa</string></value></member>
        <member><name>user</name><value><struct>
        <member><name>name</name><value><string>juppala</string></value></member>
        <member><name>fullName</name><value><string></string></value></member>
        </struct></value></member>
        </struct></value>
        </param>
        </params>
        </methodResponse>

        Show
        Jochen Wiedmann added a comment - Extracting from failure.pcap, I find the following conversation between client and server: That's odd, because there is no Base64 data i the request and the severs response contains no indication of any error. POST /services/xmlrpc HTTP/1.1 Content-Type: text/xml User-Agent: Apache XML RPC 3.0 (Sun HTTP Transport) Content-Length: 234 Cache-Control: no-cache Pragma: no-cache Host: 192.168.110.72 Accept: text/html, image/gif, image/jpeg, ; q=.2, */ ; q=.2 Connection: keep-alive <?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>user.login</methodName><params><param><value>noSessionIdYet</value></param><param><value>juppala</value></param><param><value>May@2009</value></param></params></methodCall>HTTP/1.1 200 OK Date: Thu, 14 May 2009 13:59:32 GMT Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch X-Powered-By: PHP/5.2.4-2ubuntu5.3 Set-Cookie: SESS55a18b68ea846f044e66f52f419c3322=a70ae46d86fa5c8928bc7ea2e75dc0fa; expires=Sat, 06 Jun 2009 17:32:52 GMT; path=/ Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Thu, 14 May 2009 13:59:32 GMT Cache-Control: store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Connection: close Content-Length: 463 Content-Type: text/xml <?xml version="1.0"?> <methodResponse> <params> <param> <value><struct> <member><name>sessid</name><value><string>a70ae46d86fa5c8928bc7ea2e75dc0fa</string></value></member> <member><name>user</name><value><struct> <member><name>name</name><value><string>juppala</string></value></member> <member><name>fullName</name><value><string></string></value></member> </struct></value></member> </struct></value> </param> </params> </methodResponse>
        Hide
        Jochen Wiedmann added a comment -

        A theory: The clients request contains the following:

        Content-Length: 234

        As Base64 data is slightly larger than the unencoded data, your limit of 60Kb might very welll mean that it triggers a limit like 65Kb in the server when handling the reauest. OTOH, I'd again like to blame the server in that case.

        Show
        Jochen Wiedmann added a comment - A theory: The clients request contains the following: Content-Length: 234 As Base64 data is slightly larger than the unencoded data, your limit of 60Kb might very welll mean that it triggers a limit like 65Kb in the server when handling the reauest. OTOH, I'd again like to blame the server in that case.

          People

          • Assignee:
            Jochen Wiedmann
            Reporter:
            Jagadeesh Uppala
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 24h
              24h
              Remaining:
              Remaining Estimate - 24h
              24h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development