[jira] Closed: (AXISCPP-930) Chunked encoding is not implemented correctly

["nadir amra (JIRA)" <ax...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/AXISCPP-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

nadir amra closed AXISCPP-930.
------------------------------

       Resolution: Fixed
    Fix Version/s: current (nightly)

I believe this has finally be resolved. 

Problems:

==============================================
=== 1 === Chunked processing
The transport did not keep track of how many bytes of the chunk had been consumed, and thus if not all of the chunk was consumed the next time through it would assume that the remaining partial chunk was part of the chunk size, resulting in the transport to be in a weird state, to say the least.
=== 2 === Chunk processing
The transport did not remove CRLF's from the input buffers correctly or completely, again resulting in possible weird states.
=== 3 === Chunk processing
Chunk size processing returned 0 when passed an invalid chunk size. This caused me headaches to no end. Again, causing transport to not be in a valid state. 
=== 4 === Non-chunked process, no Content-Length
Non-chunked processing where there is no content-length may occasionally result in AxisGenException with no message detailing what is wrong.  This was a result on the reliance of an uninitialized m_iContentLength class variable.  This was an intermittent error. 
==============================================

To fix the problems above, I created a new state, eSOAPMessageHasContentLength, and seperated the logic for state processing so that getBytes() now calls:

getBytes_MessageIsChunked()
getBytes_MessageIsNotChunked()
getBytes_MessageHasContentLength()

I also create resetInputStateMachine() so that it will properly initialize the state variables from whereever it is called.

In addition, the transport did not recover from connections that had been closed by the Channel when reopen was false.  I added code so that a Channel's reopenRequired() is invoked to determine if an open should be done. More information on this will be in AXISCPP-481.

I also ensure that when evaluating a chunk-size string, it is valid - i.e. all hexadecimal characters.  Otherwise, an exception is thrown.  Before, it would simple return some value.  This caused me headaches to no end.  Once I added this, it revealed that the mockserver did not handle CRLF correctly, so I had to fix that and now it does so properly as long as chunk sizes as set to ### (except the last, which must be 0). 

On the performance side, there is a lot less substring'ing.  I make heavy use of the string erase() function, and there is now no reason to seperate chunked messages when copying data to parser buffer.  In addition, the channel use to read from socket in own buffer and then copy it to transport buffer, that is no longer the case.  I have also added some minor infrastructure that in the future will let us read the data into the parser buffer directly.  However, I still have some work to do on this.

I also added support for new SoapTransport.h method isThereResponseData() that will be used for one-way requests. More on this will be in  AXISCPP-925.  

Finally, and probably more important of all, I added lots of comments so that at least it will be easy next time to understand what is going on and the intricacies of the logic.  Prior to this there was a lot of "hidden" assumptions, to put it kindly, that caused me much pain when moving code around.  No comments is a bad thing, people! :-)

So have at it and let me know if there are any problems.

> Chunked encoding is not implemented correctly
> ---------------------------------------------
>
>                 Key: AXISCPP-930
>                 URL: https://issues.apache.org/jira/browse/AXISCPP-930
>             Project: Axis-C++
>          Issue Type: Bug
>          Components: Transport (axis3)
>    Affects Versions: 1.5 Final
>         Environment: Solaris 8
>            Reporter: Michael Dufel
>         Assigned To: nadir amra
>             Fix For: current (nightly)
>
>
> <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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org