axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nadir amra (JIRA)" <>
Subject [jira] Closed: (AXISCPP-930) Chunked encoding is not implemented correctly
Date Sun, 18 Feb 2007 20:20:05 GMT


nadir amra closed AXISCPP-930.

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

I believe this has finally be resolved. 


=== 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:


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:
>             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:
For additional commands, e-mail:

View raw message