axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaushalye Kapuruge <kausha...@wso2.com>
Subject Re: issue 731 - please have a look
Date Thu, 01 Nov 2007 06:40:47 GMT
Hi Subra and others,
I've committed the new code to calculate the base64_decode_len. Please 
find the JIRA here[1]
The code works fine. And Manjula has done successful interop tests using 
the new code.
You can use following to calculate the decoded length of a char buff. 
Let us know if you are still experiencing the problem.
int axutil_base64_decode_len( const char *bufcoded)
Cheers,
Kaushalye
[1]https://issues.apache.org/jira/browse/AXIS2C-731

Subra A Narayanan wrote:
> Hello,
>
> So what is the proposed solution to this problem? Is the code going to 
> be changed so that apr_base64_decode_len() always returns the correct 
> length or should developers use [axutil/apr]_base64_decode() to get 
> the exact length?
>
> I use the apr_base64_decode_len() function to allocate memory for 
> attachment recvd via the webservice and that introduces garbage 
> characters in the end as the len function always returns a value 
> greates than the actual length.
>
> Subra
>
> On 10/23/07, *Dumindu Pallewela* <dumindu@wso2.com 
> <mailto:dumindu@wso2.com>> wrote:
>
>     Kaushalye Kapuruge wrote:
>     > Samisa Abeysinghe wrote:
>     >> Mark Nüßler wrote:
>     >>> hello users,
>     >>>
>     >>> on 26.09.2007 Royston Day found an issue,
>     >>> i just correct my svn-code localy.
>     >>>
>     >>> Can someone have a look - 4 me Royston is
>     >>> right.
>     >>>
>     >>> https://issues.apache.org/jira/browse/AXIS2C-731
>     <https://issues.apache.org/jira/browse/AXIS2C-731>
>     >> I think Rampart folks uses base64 encoding. Can someone using
>     rampart
>     >> please verify that the proposed code it correct.
>     >>
>     > I tried with the new code and it worked fine for all the
>     scenarios in
>     > Rampart/C. But I'm concerned about the interoperability. So it's too
>     > early to say that new implementation is correct unless it is
>     > inter-operable with other implementations. I'll update on that
>     later.
>
>     axutil_base64_decode_len() is the same implementation as that of the
>     apr_base64_decode_len() found in libapr. AFAIK, this does not
>     returns the exact decoded length of the encoded string, but returns
>       at least as many number of bytes that is necessary. Exact length
>     is anyway returned by the [axutil/apr]_base64_decode().
>
>     Thus, if the length returned from the proposed code is correct,
>     there should be no problems with interoperability.
>
>     -Dumindu.
>
>     --
>     Dumindu Pallewela
>     http://blog.dumindu.com
>     GPG ID: 0x9E131672
>
>     WSO2 | http://wso2.com | "Oxygenating the Web Service Platform"
>
>
>


-- 
http://blog.kaushalye.org/
http://wso2.org/


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


Mime
View raw message