axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Preston <>
Subject Re: [jira] Commented: (AXISCPP-930) Chunked encoding is not implemented correctly
Date Fri, 24 Feb 2006 13:49:24 GMT
Hi Mike,
        I think I understand your problem, but you need to upgrade to the 
latest transport code (1.5 is now so out-of-date that the errors you are 
seeing may well have been fixed) as what you are describing can no longer 


Fred Preston.

"Michael Dufel (JIRA)" <>
23/02/2006 17:07
Please respond to "Apache AXIS C Developers List"
        Subject:        [jira] Commented: (AXISCPP-930) Chunked encoding 
is not implemented correctly



Michael Dufel commented on AXISCPP-930:


Thanks for the 'in english' description of the getBytes method. It's too 
bad I didn't have it handy when I first started debugging the function.

There is a branch of particular importance:
if( m_strReceived.length () > 0) {
     /*Expects <chunk-length>CRLF<chunk-data>.... */
    //Call this Branch A
}else if( m_bChunked){
   /*Expects <partial data>CRLF<chunk-length>....*/
  //call this Branch B

Consider that the contents of m_strReceived are:

And now consider that m_iContentLength = 4 signifying that there are 4 
more bytes to read before reading the next chunk.

1. strTemp is set to 5678
2. m_strRecieved is substring'd to be:

3. strTemp and m_strReceived are spliced together yielding:

4. branch B ends.

5. The following string gets sent to the xml parser:

This is obviously incorrect because now the XML parser is reading in parts 
of the http protocol. Furthermore, the next time that getBytes is called 
you will have a big problem because the m_iContentLength variable will be 
set to 0 and the axtoi method will not be passed something that is NOT the 
chunk-length field.

The WSDL won't help you and neither would a response message if I sent one 
to you. This issue was first discovered while attempting to contact a web 
service running on a Weblogic application server. It also appeared when I 
instrumented the code to print out the contents of the XML that was 
passing over the wire. I theorize that the time taken to print out the XML 
contents allowed the channel to buffer more data from the server resulting 
in the case I have just described. This is funamentally a timing issue 
more than anything else. 

The joys of protocol programming.... :)

> Chunked encoding is not implemented correctly
> ---------------------------------------------
>          Key: AXISCPP-930
>          URL:
>      Project: Axis-C++
>         Type: Bug
>   Components: Transport (axis2), Transport (axis3)
>     Versions: 1.5 Final
>  Environment: Solaris 8
>     Reporter: Michael Dufel

> <Rant>The chunked transfer encoding is broken and results in a 
'peekNextChar' error  similar to the one described in AXISCPP-555. I was 
forced to re-write HTTPTransport::getBytes() from almost the ground up 
because of the unreadableness of the code. Nested do/while loops??? Come 
on ... Yes I know, I am a code snob. </Rant> 
> I believe the problem in the original code was reflected in the case 
that the buffer from the channel contains data in the following form:
> <some continued data>CRLF
> <chunk length 1>CRLF
> <some data 1><CRLF>
> <chunk length 2>CRLF
> <some data 2>CRLF
> .
> .
> .
> <chunk length n>CRLF
> <some data n>
> everything after <chunk length 2> was being dropped by the transport 
library. The transport library sends a 'TRANSPORT FINISHED' response and 
the xml parser is only given a partial message to deal with. This causes 
the 'peekNextChar' error. 
> Yes, I know that solaris 8 is not supported in Axis 1.5, but this is a 
protocol issue, not a platform related issue. Again, since I had to 
re-write the getBytes method, I can't offer a code snippet which will 
'magically' fix this problem. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message