You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Steven McDowall <sj...@aptest.com> on 2000/07/14 16:14:03 UTC
Marshalling error? CRITICAL
I sent out an email 2 days ago about what I think is a severe error with the
current
implementation (at least with SOAP marshalling) that I think needs to be
addressed..
Addressed may mean that I am totally crazy :-)
When I send method parameters as strings, and those strings HAPPEN to
contain
"<" or worse "<..>" than horrible things happen because they are not being
escaped so the SAX / DOM parser on the other end thinks they are invalid
DOM parts (which they ARE) and dies.. or NULL Exception Faults, etc.
The marshalling routine for strings must encode them first in the "proper"
XML
way (I think they are supposed to be converted to Unicode escapes like
?)
or < ??
Am I missing something here? This is a major fault I think if I am correct..
-Steve
---
Steven J. McDowall phone: +1 763 780-8814
ApTest fax: +1 763 786-8180
e-mail: sjm@aptest.com
Re: Marshalling error? CRITICAL
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
I just talked to Matt and he said he has the code for this already..
apparently we just didn't get around to using it. Sorry .. :-)
Matt's going to commit the fix in a little bit.
Sanjiva.
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
To: <so...@xml.apache.org>
Sent: Friday, July 14, 2000 10:58 AM
Subject: Re: Marshalling error? CRITICAL
> This is definitely a critical problem. I believe the fix is farely
> simple; just encode "<" characters in string values (">" are legal
> within XML AFAIK). The simplest fix may be to wrapper string values
> within a CDATA block.
>
> Would anyone care to do it? The string encoding / decoding case is
> pretty much special-cased in the SOAPMappingRegistry and so the fix
> would go there.
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Steven McDowall" <sj...@aptest.com>
> To: <so...@xml.apache.org>
> Sent: Friday, July 14, 2000 10:14 AM
> Subject: Marshalling error? CRITICAL
>
>
> >
> > I sent out an email 2 days ago about what I think is a severe error with
the
> > current
> > implementation (at least with SOAP marshalling) that I think needs to be
> > addressed..
> > Addressed may mean that I am totally crazy :-)
> >
> > When I send method parameters as strings, and those strings HAPPEN to
> > contain
> > "<" or worse "<..>" than horrible things happen because they are not being
> > escaped so the SAX / DOM parser on the other end thinks they are invalid
> > DOM parts (which they ARE) and dies.. or NULL Exception Faults, etc.
> >
> > The marshalling routine for strings must encode them first in the "proper"
> > XML
> > way (I think they are supposed to be converted to Unicode escapes like
> > ?)
> > or < ??
> >
> > Am I missing something here? This is a major fault I think if I am
correct..
> >
> > -Steve
> >
> >
> > ---
> > Steven J. McDowall phone: +1 763 780-8814
> > ApTest fax: +1 763 786-8180
> > e-mail: sjm@aptest.com
> >
>
Re: Marshalling error? CRITICAL
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
I just talked to Matt and he said he has the code for this already..
apparently we just didn't get around to using it. Sorry .. :-)
Matt's going to commit the fix in a little bit.
Sanjiva.
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
To: <so...@xml.apache.org>
Sent: Friday, July 14, 2000 10:58 AM
Subject: Re: Marshalling error? CRITICAL
> This is definitely a critical problem. I believe the fix is farely
> simple; just encode "<" characters in string values (">" are legal
> within XML AFAIK). The simplest fix may be to wrapper string values
> within a CDATA block.
>
> Would anyone care to do it? The string encoding / decoding case is
> pretty much special-cased in the SOAPMappingRegistry and so the fix
> would go there.
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Steven McDowall" <sj...@aptest.com>
> To: <so...@xml.apache.org>
> Sent: Friday, July 14, 2000 10:14 AM
> Subject: Marshalling error? CRITICAL
>
>
> >
> > I sent out an email 2 days ago about what I think is a severe error with
the
> > current
> > implementation (at least with SOAP marshalling) that I think needs to be
> > addressed..
> > Addressed may mean that I am totally crazy :-)
> >
> > When I send method parameters as strings, and those strings HAPPEN to
> > contain
> > "<" or worse "<..>" than horrible things happen because they are not being
> > escaped so the SAX / DOM parser on the other end thinks they are invalid
> > DOM parts (which they ARE) and dies.. or NULL Exception Faults, etc.
> >
> > The marshalling routine for strings must encode them first in the "proper"
> > XML
> > way (I think they are supposed to be converted to Unicode escapes like
> > ?)
> > or < ??
> >
> > Am I missing something here? This is a major fault I think if I am
correct..
> >
> > -Steve
> >
> >
> > ---
> > Steven J. McDowall phone: +1 763 780-8814
> > ApTest fax: +1 763 786-8180
> > e-mail: sjm@aptest.com
> >
>
Re: Marshalling error? CRITICAL
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
This is definitely a critical problem. I believe the fix is farely
simple; just encode "<" characters in string values (">" are legal
within XML AFAIK). The simplest fix may be to wrapper string values
within a CDATA block.
Would anyone care to do it? The string encoding / decoding case is
pretty much special-cased in the SOAPMappingRegistry and so the fix
would go there.
Sanjiva.
----- Original Message -----
From: "Steven McDowall" <sj...@aptest.com>
To: <so...@xml.apache.org>
Sent: Friday, July 14, 2000 10:14 AM
Subject: Marshalling error? CRITICAL
>
> I sent out an email 2 days ago about what I think is a severe error with the
> current
> implementation (at least with SOAP marshalling) that I think needs to be
> addressed..
> Addressed may mean that I am totally crazy :-)
>
> When I send method parameters as strings, and those strings HAPPEN to
> contain
> "<" or worse "<..>" than horrible things happen because they are not being
> escaped so the SAX / DOM parser on the other end thinks they are invalid
> DOM parts (which they ARE) and dies.. or NULL Exception Faults, etc.
>
> The marshalling routine for strings must encode them first in the "proper"
> XML
> way (I think they are supposed to be converted to Unicode escapes like
> ?)
> or < ??
>
> Am I missing something here? This is a major fault I think if I am correct..
>
> -Steve
>
>
> ---
> Steven J. McDowall phone: +1 763 780-8814
> ApTest fax: +1 763 786-8180
> e-mail: sjm@aptest.com
>
Re: Marshalling error? CRITICAL
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
This is definitely a critical problem. I believe the fix is farely
simple; just encode "<" characters in string values (">" are legal
within XML AFAIK). The simplest fix may be to wrapper string values
within a CDATA block.
Would anyone care to do it? The string encoding / decoding case is
pretty much special-cased in the SOAPMappingRegistry and so the fix
would go there.
Sanjiva.
----- Original Message -----
From: "Steven McDowall" <sj...@aptest.com>
To: <so...@xml.apache.org>
Sent: Friday, July 14, 2000 10:14 AM
Subject: Marshalling error? CRITICAL
>
> I sent out an email 2 days ago about what I think is a severe error with the
> current
> implementation (at least with SOAP marshalling) that I think needs to be
> addressed..
> Addressed may mean that I am totally crazy :-)
>
> When I send method parameters as strings, and those strings HAPPEN to
> contain
> "<" or worse "<..>" than horrible things happen because they are not being
> escaped so the SAX / DOM parser on the other end thinks they are invalid
> DOM parts (which they ARE) and dies.. or NULL Exception Faults, etc.
>
> The marshalling routine for strings must encode them first in the "proper"
> XML
> way (I think they are supposed to be converted to Unicode escapes like
> ?)
> or < ??
>
> Am I missing something here? This is a major fault I think if I am correct..
>
> -Steve
>
>
> ---
> Steven J. McDowall phone: +1 763 780-8814
> ApTest fax: +1 763 786-8180
> e-mail: sjm@aptest.com
>