axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Preston <PREST...@uk.ibm.com>
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 
happen.

Regards,

Fred Preston.





"Michael Dufel (JIRA)" <axis-c-dev@ws.apache.org>
23/02/2006 17:07
Please respond to "Apache AXIS C Developers List"
 
        To:     axis-c-dev@ws.apache.org
        cc: 
        Subject:        [jira] Commented: (AXISCPP-930) Chunked encoding 
is not implemented correctly

 

    [ 
http://issues.apache.org/jira/browse/AXISCPP-930?page=comments#action_12367536 
] 

Michael Dufel commented on AXISCPP-930:
---------------------------------------

Fred,

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:
5678
0008
12345678
0009
123456789
000A
1234

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:
12345678
0009
123456789
000A
1234

3. strTemp and m_strReceived are spliced together yielding:
567812345678
0009
123456789
000A
1234

4. branch B ends.

5. The following string gets sent to the xml parser:
567812345678
0009
123456789
000A
1234

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: http://issues.apache.org/jira/browse/AXISCPP-930
>      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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



Mime
View raw message