[jira] Created: (AXIS-2822) Content-Length calculation issue.

["Vasili Bledar (JIRA)" <ax...@ws.apache.org>]

Content-Length calculation issue.
---------------------------------

                 Key: AXIS-2822
                 URL: https://issues.apache.org/jira/browse/AXIS-2822
             Project: Axis
          Issue Type: Bug
          Components: Basic Architecture
    Affects Versions: 1.4
         Environment: This is the clients environment:

Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
With kernel: Linux 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux
Java Env: 
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)
            Reporter: Vasili Bledar


While 99.99999% the axis is working perfectly, when trying to send a request of 1.500.000 bytes approximately, the server fails to acknowledge it. While trying to send the same request a few times in a row, it is always sent with different content-length.

The element's indexes in the xml file we sent may differ each time, but the actual data are always the same. For example:

1st time we transmit:

<a>
 <name>blabla</name>
</a>
<a>
 <name>gluglu</name>
</a>

The 2nd time we transmit may be found like this:

<a>
 <name>gluglu</name>
</a>
<a>
 <name>blabla</name>
</a>

By using a packet sniffer on the server side we can see that our request is successfully transmitted. The soap request is reassembled through the packets recieved and the request body is checked against an xml parser which reveals that everything is ok with the xml data pasted in it.

This xml body is different each time, but the length of the body should be the same (I'm not 100% sure on this and I may be missing something essential here).

Another fact is that, the content-length parameter could say for example that the content-length is 1.456.321 bytes, but the number of packets size summed together for the specific communication is 1.255.456 or it could be slightly above the content-length which is not correct since there are definetely more data in communication which should increase the bytes sent in the communication much above the content-length.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.