[
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
