[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
