axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manjula Peiris <manj...@wso2.com>
Subject Re: issue 731 - please have a look
Date Thu, 01 Nov 2007 09:17:42 GMT
On Thu, 2007-11-01 at 12:10 +0530, Kaushalye Kapuruge wrote:
> 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.

Yes I have successfully interoped the security samples (encryption and
signature) which use this function with WCF.

-Manjula.


> 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"
> >
> >
> >
> 
> 


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