You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Mark Nüßler <ma...@9elements.com> on 2007/10/20 15:48:25 UTC
issue 731 - please have a look
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
mfg derMark
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: issue 731 - please have a look
Posted by Manjula Peiris <ma...@wso2.com>.
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
> > <ma...@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
Re: issue 731 - please have a look
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
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
> <ma...@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
Re: issue 731 - please have a look
Posted by Subra A Narayanan <as...@gmail.com>.
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 <du...@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
> >> 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
Posted by Dumindu Pallewela <du...@wso2.com>.
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
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
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: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>
>>
>
>
--
http://kaushalye.blogspot.com/
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
Re: issue 731 - please have a look
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
--
Samisa Abeysinghe : WSO2 WSF/PHP
"http://wso2.org/projects/wsf/php?WSO2 Web Services Framework%2FPHP - Open source PHP extention for providing and consuming Web services in PHP"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org