Re: issue 731 - please have a look
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* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: issue 731 - please have a look
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 [EMAIL PROTECTED] 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 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
Re: issue 731 - please have a look
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 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. -Kau Thanks, Samisa... mfg derMark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://kaushalye.blogspot.com/ http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: issue 731 - please have a look
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 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 signature.asc Description: OpenPGP digital signature
Re: issue 731 - please have a look
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 I think Rampart folks uses base64 encoding. Can someone using rampart please verify that the proposed code it correct. Thanks, Samisa... mfg derMark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Samisa Abeysinghe : WSO2 WSF/PHP http://wso2.org/projects/wsf/php?WSO2nbsp;Webnbsp;Servicesnbsp;Framework%2FPHPnbsp;-nbsp;Opennbsp;sourcenbsp;PHPnbsp;extentionnbsp;fornbsp;providingnbsp;andnbsp;consumingnbsp;Webnbsp;servicesnbsp;innbsp;PHP; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
