[
http://issues.apache.org/jira/browse/AXISCPP-930?page=comments#action_12367376
]
Michael Dufel commented on AXISCPP-930:
---------------------------------------
*******************Code Block: HTTPTransport::getBytes************
if (0 <= m_iBytesLeft)
{
int iIterationCountdown;
try
{
m_pszRxBuffer [0] = '\0';
*m_pActiveChannel >> m_pszRxBuffer;
m_strReceived = m_pszRxBuffer;
************************************************************************
You see here that any prior contents of m_strReceived are erased in favor of
new data from the channel. A simple examination of the code that handles the
case of continued chunk data does not loop to consume all the data in
m_strReceived. Thus there is leftover data that gets dropped the next time the
getBytes function is called. The only way this code works is if the content of
m_strReceived is of the form:
<continued data>CRLF
<content length>CRLF
<content data <= content length>
You might do something like m_strReceived += m_pszRxBuffer, but that is not a
complete fix - if it was that simple I would have done it instead of
restructuring the code.
> 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
