Quantcast

WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Pavel-3
Hello,

I'm facing an issue with CXF + WSS4JOutInterceptor.
Seems like it is unable to hadle strings that contain characters with hex
code <0x20; Client fails to send request with the following stacktrace

javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to stream
    at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
    *at $Proxy125.isStayQualified(Unknown Source)*  << that is my client
    ...
Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space character
(0x1) in text to output*
    at
com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:511)
    at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
    at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
    at
org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
    at
org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
    at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
    at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
    at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
    ... 30 more
Caused by: java.io.IOException: Invalid white space character (0x1) in text
to output
    at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
    at
com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.java:531)
    at
com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:509)
    ... 40 more


Requests work fine though if I don't use WSS4JOutInterceptor. Problematic
chars get escaped as &#XX.

I tried that with both CXF 2.2.0-fuse and 2.2.5.
Is there some sort of configuration required to avoid that issue?


Thanks,
Pavel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Benson Margulies
XML prohibits that character. you cannot sent it in an xsd:string.

On Dec 7, 2009, at 6:10 AM, Pavel <[hidden email]> wrote:

> Hello,
>
> I'm facing an issue with CXF + WSS4JOutInterceptor.
> Seems like it is unable to hadle strings that contain characters  
> with hex
> code <0x20; Client fails to send request with the following stacktrace
>
> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to  
> stream
>    at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
> 146)
>    *at $Proxy125.isStayQualified(Unknown Source)*  << that is my  
> client
>    ...
> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space  
> character
> (0x1) in text to output*
>    at
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
> (BaseStreamWriter.java:511)
>    at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>    at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>    at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>    at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>    at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
> (PhaseInterceptorChain.java:236)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>    at org.apache.cxf.frontend.ClientProxy.invokeSync
> (ClientProxy.java:73)
>    at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
> 124)
>    ... 30 more
> Caused by: java.io.IOException: Invalid white space character (0x1)  
> in text
> to output
>    at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>    at
> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters
> (BufferingXmlWriter.java:531)
>    at
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
> (BaseStreamWriter.java:509)
>    ... 40 more
>
>
> Requests work fine though if I don't use WSS4JOutInterceptor.  
> Problematic
> chars get escaped as &#XX.
>
> I tried that with both CXF 2.2.0-fuse and 2.2.5.
> Is there some sort of configuration required to avoid that issue?
>
>
> Thanks,
> Pavel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Pavel-3
But that's not me, it is CXF that produces XML representation of that
character. I expect CXF to take care of marshalling specifics, including
proper escaping of special characters.

Moreover, as I mentioned, CXF does that work well unless/until security
interceptor comes into play.

So obviously there is an XML representation for the data I want to send, and
I'm back to may question - what is/whether there is a way to make security
interceptor handle 0x1 properly?

Thanks,
Pavel

On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <[hidden email]>wrote:

> XML prohibits that character. you cannot sent it in an xsd:string.
>
>
> On Dec 7, 2009, at 6:10 AM, Pavel <[hidden email]> wrote:
>
>  Hello,
>>
>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>> Seems like it is unable to hadle strings that contain characters with hex
>> code <0x20; Client fails to send request with the following stacktrace
>>
>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to stream
>>   at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
>>   *at $Proxy125.isStayQualified(Unknown Source)*  << that is my client
>>   ...
>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>> character
>> (0x1) in text to output*
>>   at
>>
>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:511)
>>   at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>>   at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>>   at
>>
>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>>   at
>>
>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>>   at
>>
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>>   at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>>   at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>>   at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>>   at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>   at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
>>   ... 30 more
>> Caused by: java.io.IOException: Invalid white space character (0x1) in
>> text
>> to output
>>   at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>>   at
>>
>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.java:531)
>>   at
>>
>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:509)
>>   ... 40 more
>>
>>
>> Requests work fine though if I don't use WSS4JOutInterceptor. Problematic
>> chars get escaped as &#XX.
>>
>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>> Is there some sort of configuration required to avoid that issue?
>>
>>
>> Thanks,
>> Pavel
>>
>


--
Best regards,
Pavel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Benson Margulies
cxf cannot marshall u+0001 in a string.  the best it could do is throw  
sooner. it is up to the app. it is a strange feature of jax-whatever  
that string values are constrained to XML 1.0 valid chars, but there  
you are. if you have to ship chars like this, you need to push them  
around as bytes.

On Dec 7, 2009, at 7:08 AM, Pavel <[hidden email]> wrote:

> But that's not me, it is CXF that produces XML representation of that
> character. I expect CXF to take care of marshalling specifics,  
> including
> proper escaping of special characters.
>
> Moreover, as I mentioned, CXF does that work well unless/until  
> security
> interceptor comes into play.
>
> So obviously there is an XML representation for the data I want to  
> send, and
> I'm back to may question - what is/whether there is a way to make  
> security
> interceptor handle 0x1 properly?
>
> Thanks,
> Pavel
>
> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <[hidden email]
> >wrote:
>
>> XML prohibits that character. you cannot sent it in an xsd:string.
>>
>>
>> On Dec 7, 2009, at 6:10 AM, Pavel <[hidden email]> wrote:
>>
>> Hello,
>>>
>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>>> Seems like it is unable to hadle strings that contain characters  
>>> with hex
>>> code <0x20; Client fails to send request with the following  
>>> stacktrace
>>>
>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model  
>>> to stream
>>>  at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 146)
>>>  *at $Proxy125.isStayQualified(Unknown Source)*  << that is my  
>>> client
>>>  ...
>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>>> character
>>> (0x1) in text to output*
>>>  at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:511)
>>>  at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>>>  at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>>>  at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>>>  at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>>>  at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
>>> (PhaseInterceptorChain.java:236)
>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>>>  at org.apache.cxf.frontend.ClientProxy.invokeSync
>>> (ClientProxy.java:73)
>>>  at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 124)
>>>  ... 30 more
>>> Caused by: java.io.IOException: Invalid white space character  
>>> (0x1) in
>>> text
>>> to output
>>>  at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>>>  at
>>>
>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters
>>> (BufferingXmlWriter.java:531)
>>>  at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:509)
>>>  ... 40 more
>>>
>>>
>>> Requests work fine though if I don't use WSS4JOutInterceptor.  
>>> Problematic
>>> chars get escaped as &#XX.
>>>
>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>>> Is there some sort of configuration required to avoid that issue?
>>>
>>>
>>> Thanks,
>>> Pavel
>>>
>>
>
>
> --
> Best regards,
> Pavel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Benson Margulies
In reply to this post by Pavel-3
not all paths notice this. however, if your data dosen't have this  
char in it, we have some other problem.

On Dec 7, 2009, at 7:08 AM, Pavel <[hidden email]> wrote:

> But that's not me, it is CXF that produces XML representation of that
> character. I expect CXF to take care of marshalling specifics,  
> including
> proper escaping of special characters.
>
> Moreover, as I mentioned, CXF does that work well unless/until  
> security
> interceptor comes into play.
>
> So obviously there is an XML representation for the data I want to  
> send, and
> I'm back to may question - what is/whether there is a way to make  
> security
> interceptor handle 0x1 properly?
>
> Thanks,
> Pavel
>
> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <[hidden email]
> >wrote:
>
>> XML prohibits that character. you cannot sent it in an xsd:string.
>>
>>
>> On Dec 7, 2009, at 6:10 AM, Pavel <[hidden email]> wrote:
>>
>> Hello,
>>>
>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>>> Seems like it is unable to hadle strings that contain characters  
>>> with hex
>>> code <0x20; Client fails to send request with the following  
>>> stacktrace
>>>
>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model  
>>> to stream
>>>  at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 146)
>>>  *at $Proxy125.isStayQualified(Unknown Source)*  << that is my  
>>> client
>>>  ...
>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>>> character
>>> (0x1) in text to output*
>>>  at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:511)
>>>  at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>>>  at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>>>  at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>>>  at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>>>  at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
>>> (PhaseInterceptorChain.java:236)
>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>>>  at org.apache.cxf.frontend.ClientProxy.invokeSync
>>> (ClientProxy.java:73)
>>>  at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 124)
>>>  ... 30 more
>>> Caused by: java.io.IOException: Invalid white space character  
>>> (0x1) in
>>> text
>>> to output
>>>  at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>>>  at
>>>
>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters
>>> (BufferingXmlWriter.java:531)
>>>  at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:509)
>>>  ... 40 more
>>>
>>>
>>> Requests work fine though if I don't use WSS4JOutInterceptor.  
>>> Problematic
>>> chars get escaped as &#XX.
>>>
>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>>> Is there some sort of configuration required to avoid that issue?
>>>
>>>
>>> Thanks,
>>> Pavel
>>>
>>
>
>
> --
> Best regards,
> Pavel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Pavel-3
In reply to this post by Benson Margulies
Ok, I'm a bit lost then, so I'll just state once again what I observed
before and read in your responses.

A. Input
1. There are whitespace characters with code <0x20, that may come in bean
string properties, that are used.
2. By default CXF handles them by quoting into output stream. &#XX. Client
able to send out the request
3. With WSS4JOutInterceptor enabled CXF behaivour changes, exception is
thrown (stacktrace available in previous posts)

B. Comments
1. XML 1.0 prohibits these characters.
2. CXF cannot marshall u+0001 in a string. (Although it does in A2).
3. It is up to the app to fix the content somehow.
4. if you have to ship chars like this, you need to push them around as
bytes.

C. My additional observations.
1. The validation itself comes from the woodstox used by SAAJOutInterceptor.
2. It is WSS4JOutInterceptor that adds SAAJOutInterceptor into the
interceptor chain.
3. http://jira.codehaus.org/browse/WSTX-223 asks for the ability to turn
that validation off, but this issue is "open"/not implemented.
4. Woodstox 4 has an option to replace illegal characters with e.g. spaces;
see http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html
5. CXF uses Woodstox 3.x.x

Are there any plans for CXF to update to Woodstox 4.x? And then expose
option to replace/handle these whitespace characters?

Or otherwise, could you recommend a way to plug into request/response
processing and replace these chars via CXF API?

Thanks,
Pavel

On Mon, Dec 7, 2009 at 3:19 PM, Benson Margulies <[hidden email]>wrote:

> cxf cannot marshall u+0001 in a string.  the best it could do is throw
> sooner. it is up to the app. it is a strange feature of jax-whatever that
> string values are constrained to XML 1.0 valid chars, but there you are. if
> you have to ship chars like this, you need to push them around as bytes.
>
>
> On Dec 7, 2009, at 7:08 AM, Pavel <[hidden email]> wrote:
>
>  But that's not me, it is CXF that produces XML representation of that
>> character. I expect CXF to take care of marshalling specifics, including
>> proper escaping of special characters.
>>
>> Moreover, as I mentioned, CXF does that work well unless/until security
>> interceptor comes into play.
>>
>> So obviously there is an XML representation for the data I want to send,
>> and
>> I'm back to may question - what is/whether there is a way to make security
>> interceptor handle 0x1 properly?
>>
>> Thanks,
>> Pavel
>>
>> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <[hidden email]
>> >wrote:
>>
>>  XML prohibits that character. you cannot sent it in an xsd:string.
>>>
>>>
>>> On Dec 7, 2009, at 6:10 AM, Pavel <[hidden email]> wrote:
>>>
>>> Hello,
>>>
>>>>
>>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>>>> Seems like it is unable to hadle strings that contain characters with
>>>> hex
>>>> code <0x20; Client fails to send request with the following stacktrace
>>>>
>>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to
>>>> stream
>>>>  at
>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
>>>>  *at $Proxy125.isStayQualified(Unknown Source)*  << that is my client
>>>>  ...
>>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>>>> character
>>>> (0x1) in text to output*
>>>>  at
>>>>
>>>>
>>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:511)
>>>>  at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>>>>  at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>>>>  at
>>>>
>>>>
>>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>>>>  at
>>>>
>>>>
>>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>>>>  at
>>>>
>>>>
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>>>>  at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>>>>  at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>>>  at
>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
>>>>  ... 30 more
>>>> Caused by: java.io.IOException: Invalid white space character (0x1) in
>>>> text
>>>> to output
>>>>  at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>>>>  at
>>>>
>>>>
>>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.java:531)
>>>>  at
>>>>
>>>>
>>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:509)
>>>>  ... 40 more
>>>>
>>>>
>>>> Requests work fine though if I don't use WSS4JOutInterceptor.
>>>> Problematic
>>>> chars get escaped as &#XX.
>>>>
>>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>>>> Is there some sort of configuration required to avoid that issue?
>>>>
>>>>
>>>> Thanks,
>>>> Pavel
>>>>
>>>>
>>>
>>
>> --
>> Best regards,
>> Pavel
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Daniel Kulp
Administrator
On Mon December 7 2009 9:27:36 am Pavel wrote:
> Ok, I'm a bit lost then, so I'll just state once again what I observed
> before and read in your responses.
>
> A. Input
> 1. There are whitespace characters with code <0x20, that may come in bean
> string properties, that are used.
> 2. By default CXF handles them by quoting into output stream. &#XX. Client
> able to send out the request

This is technically a bug in JAXB, it shouldn't be doing that.  It SHOULD be
throwing an exception, but not something I would normally worry about.

> 3. With WSS4JOutInterceptor enabled CXF behaivour changes, exception is
> thrown (stacktrace available in previous posts)

Actually, it would also change with Aegis or XMLBeans.    For JAXB, we
normally use an optimization to bypass the XMLStreamWriter which is much
faster, but allows JAXB to encode this case in an invalid way.   If we turn
off the optimization (there is a flag for that) and go through the
XMLStreamWriter, it would throw the same exception.    Again, bug in JAXB.


> B. Comments
> 1. XML 1.0 prohibits these characters.
> 2. CXF cannot marshall u+0001 in a string. (Although it does in A2).
> 3. It is up to the app to fix the content somehow.
> 4. if you have to ship chars like this, you need to push them around as
> bytes.
>
> C. My additional observations.
> 1. The validation itself comes from the woodstox used by
>  SAAJOutInterceptor.
> 2. It is WSS4JOutInterceptor that adds
>  SAAJOutInterceptor into the interceptor chain.

There are other use cases as well.   Example: having a JAXWS SOAPHandler on
the chain would also trigger adding it.

> 3. http://jira.codehaus.org/browse/WSTX-223 asks for the ability to turn
> that validation off, but this issue is "open"/not implemented.
> 4. Woodstox 4 has an option to replace illegal characters with e.g. spaces;
> see http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html
> 5. CXF uses Woodstox 3.x.x
>
> Are there any plans for CXF to update to Woodstox 4.x?

CXF trunk (targetting 2.3) is using woodstox 4.   The branches SHOULD work
fine with 4 as well if you want to use 4 instead of 3.x.

> And then expose
> option to replace/handle these whitespace characters?
>
> Or otherwise, could you recommend a way to plug into request/response
> processing and replace these chars via CXF API?

Well, one option is to write a XMLStreamWriter wrapper that forwards all the
calls to a the original writer except for the writeCharacter methods (and
probably writeAttribute).   Those methods would escape or replace any invalid
content and then call the original.   An interceptor running immediately after
the StaxOutInterceptor would take the original XMLStreamWriter and wrapper it
with yours and replace it.  

You could also configure in your own XMLOutputFactory that does it as well
that wouldn't require an interceptor, but you would need to override/wrapper
more methods there as well.

Dan


>
> Thanks,
> Pavel
>
> On Mon, Dec 7, 2009 at 3:19 PM, Benson Margulies
<[hidden email]>wrote:

> > cxf cannot marshall u+0001 in a string.  the best it could do is throw
> > sooner. it is up to the app. it is a strange feature of jax-whatever that
> > string values are constrained to XML 1.0 valid chars, but there you are.
> > if you have to ship chars like this, you need to push them around as
> > bytes.
> >
> >
> > On Dec 7, 2009, at 7:08 AM, Pavel <[hidden email]> wrote:
> >
> >  But that's not me, it is CXF that produces XML representation of that
> >
> >> character. I expect CXF to take care of marshalling specifics, including
> >> proper escaping of special characters.
> >>
> >> Moreover, as I mentioned, CXF does that work well unless/until security
> >> interceptor comes into play.
> >>
> >> So obviously there is an XML representation for the data I want to send,
> >> and
> >> I'm back to may question - what is/whether there is a way to make
> >> security interceptor handle 0x1 properly?
> >>
> >> Thanks,
> >> Pavel
> >>
> >> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <[hidden email]
> >>
> >> >wrote:
> >>
> >>  XML prohibits that character. you cannot sent it in an xsd:string.
> >>
> >>> On Dec 7, 2009, at 6:10 AM, Pavel <[hidden email]> wrote:
> >>>
> >>> Hello,
> >>>
> >>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
> >>>> Seems like it is unable to hadle strings that contain characters with
> >>>> hex
> >>>> code <0x20; Client fails to send request with the following stacktrace
> >>>>
> >>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to
> >>>> stream
> >>>>  at
> >>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146
> >>>>) *at $Proxy125.isStayQualified(Unknown Source)*  << that is my client
> >>>> ...
> >>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
> >>>> character
> >>>> (0x1) in text to output*
> >>>>  at
> >>>>
> >>>>
> >>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> >>>>:511) at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434) at
> >>>> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412) at
> >>>>
> >>>>
> >>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> >>>>ceptor.handleMessage(SAAJOutInterceptor.java:197) at
> >>>>
> >>>>
> >>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> >>>>ceptor.handleMessage(SAAJOutInterceptor.java:158) at
> >>>>
> >>>>
> >>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >>>>rChain.java:236) at
> >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483) at
> >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309) at
> >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261) at
> >>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at
> >>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124
> >>>>) ... 30 more
> >>>> Caused by: java.io.IOException: Invalid white space character (0x1) in
> >>>> text
> >>>> to output
> >>>>  at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
> >>>>  at
> >>>>
> >>>>
> >>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.
> >>>>java:531) at
> >>>>
> >>>>
> >>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> >>>>:509) ... 40 more
> >>>>
> >>>>
> >>>> Requests work fine though if I don't use WSS4JOutInterceptor.
> >>>> Problematic
> >>>> chars get escaped as &#XX.
> >>>>
> >>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
> >>>> Is there some sort of configuration required to avoid that issue?
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Pavel
> >>
> >> --
> >> Best regards,
> >> Pavel
>

--
Daniel Kulp
[hidden email]
http://www.dankulp.com/blog
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Pavel-3
I implemented #1 from your suggestions, and it seems to work well. Thanks!

On Mon, Dec 7, 2009 at 7:36 PM, Daniel Kulp <[hidden email]> wrote:

> On Mon December 7 2009 9:27:36 am Pavel wrote:
> > Ok, I'm a bit lost then, so I'll just state once again what I observed
> > before and read in your responses.
> >
> > A. Input
> > 1. There are whitespace characters with code <0x20, that may come in bean
> > string properties, that are used.
> > 2. By default CXF handles them by quoting into output stream. &#XX.
> Client
> > able to send out the request
>
> This is technically a bug in JAXB, it shouldn't be doing that.  It SHOULD
> be
> throwing an exception, but not something I would normally worry about.
>
> > 3. With WSS4JOutInterceptor enabled CXF behaivour changes, exception is
> > thrown (stacktrace available in previous posts)
>
> Actually, it would also change with Aegis or XMLBeans.    For JAXB, we
> normally use an optimization to bypass the XMLStreamWriter which is much
> faster, but allows JAXB to encode this case in an invalid way.   If we turn
> off the optimization (there is a flag for that) and go through the
> XMLStreamWriter, it would throw the same exception.    Again, bug in JAXB.
>
>
> > B. Comments
> > 1. XML 1.0 prohibits these characters.
> > 2. CXF cannot marshall u+0001 in a string. (Although it does in A2).
> > 3. It is up to the app to fix the content somehow.
> > 4. if you have to ship chars like this, you need to push them around as
> > bytes.
> >
> > C. My additional observations.
> > 1. The validation itself comes from the woodstox used by
> >  SAAJOutInterceptor.
> > 2. It is WSS4JOutInterceptor that adds
> >  SAAJOutInterceptor into the interceptor chain.
>
> There are other use cases as well.   Example: having a JAXWS SOAPHandler on
> the chain would also trigger adding it.
>
> > 3. http://jira.codehaus.org/browse/WSTX-223 asks for the ability to turn
> > that validation off, but this issue is "open"/not implemented.
> > 4. Woodstox 4 has an option to replace illegal characters with e.g.
> spaces;
> > see http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html
> > 5. CXF uses Woodstox 3.x.x
> >
> > Are there any plans for CXF to update to Woodstox 4.x?
>
> CXF trunk (targetting 2.3) is using woodstox 4.   The branches SHOULD work
> fine with 4 as well if you want to use 4 instead of 3.x.
>
> > And then expose
> > option to replace/handle these whitespace characters?
> >
> > Or otherwise, could you recommend a way to plug into request/response
> > processing and replace these chars via CXF API?
>
> Well, one option is to write a XMLStreamWriter wrapper that forwards all
> the
> calls to a the original writer except for the writeCharacter methods (and
> probably writeAttribute).   Those methods would escape or replace any
> invalid
> content and then call the original.   An interceptor running immediately
> after
> the StaxOutInterceptor would take the original XMLStreamWriter and wrapper
> it
> with yours and replace it.
>
> You could also configure in your own XMLOutputFactory that does it as well
> that wouldn't require an interceptor, but you would need to
> override/wrapper
> more methods there as well.
>
> Dan
>
>
> >
> > Thanks,
> > Pavel
> >
> > On Mon, Dec 7, 2009 at 3:19 PM, Benson Margulies
> <[hidden email]>wrote:
> > > cxf cannot marshall u+0001 in a string.  the best it could do is throw
> > > sooner. it is up to the app. it is a strange feature of jax-whatever
> that
> > > string values are constrained to XML 1.0 valid chars, but there you
> are.
> > > if you have to ship chars like this, you need to push them around as
> > > bytes.
> > >
> > >
> > > On Dec 7, 2009, at 7:08 AM, Pavel <[hidden email]> wrote:
> > >
> > >  But that's not me, it is CXF that produces XML representation of that
> > >
> > >> character. I expect CXF to take care of marshalling specifics,
> including
> > >> proper escaping of special characters.
> > >>
> > >> Moreover, as I mentioned, CXF does that work well unless/until
> security
> > >> interceptor comes into play.
> > >>
> > >> So obviously there is an XML representation for the data I want to
> send,
> > >> and
> > >> I'm back to may question - what is/whether there is a way to make
> > >> security interceptor handle 0x1 properly?
> > >>
> > >> Thanks,
> > >> Pavel
> > >>
> > >> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <
> [hidden email]
> > >>
> > >> >wrote:
> > >>
> > >>  XML prohibits that character. you cannot sent it in an xsd:string.
> > >>
> > >>> On Dec 7, 2009, at 6:10 AM, Pavel <[hidden email]> wrote:
> > >>>
> > >>> Hello,
> > >>>
> > >>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
> > >>>> Seems like it is unable to hadle strings that contain characters
> with
> > >>>> hex
> > >>>> code <0x20; Client fails to send request with the following
> stacktrace
> > >>>>
> > >>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to
> > >>>> stream
> > >>>>  at
> > >>>>
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146
> > >>>>) *at $Proxy125.isStayQualified(Unknown Source)*  << that is my
> client
> > >>>> ...
> > >>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
> > >>>> character
> > >>>> (0x1) in text to output*
> > >>>>  at
> > >>>>
> > >>>>
> > >>>>
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> > >>>>:511) at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
> at
> > >>>> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412) at
> > >>>>
> > >>>>
> > >>>>
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> > >>>>ceptor.handleMessage(SAAJOutInterceptor.java:197) at
> > >>>>
> > >>>>
> > >>>>
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> > >>>>ceptor.handleMessage(SAAJOutInterceptor.java:158) at
> > >>>>
> > >>>>
> > >>>>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> > >>>>rChain.java:236) at
> > >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483) at
> > >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309) at
> > >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261) at
> > >>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> > >>>>
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124
> > >>>>) ... 30 more
> > >>>> Caused by: java.io.IOException: Invalid white space character (0x1)
> in
> > >>>> text
> > >>>> to output
> > >>>>  at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
> > >>>>  at
> > >>>>
> > >>>>
> > >>>>
> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.
> > >>>>java:531) at
> > >>>>
> > >>>>
> > >>>>
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> > >>>>:509) ... 40 more
> > >>>>
> > >>>>
> > >>>> Requests work fine though if I don't use WSS4JOutInterceptor.
> > >>>> Problematic
> > >>>> chars get escaped as &#XX.
> > >>>>
> > >>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
> > >>>> Is there some sort of configuration required to avoid that issue?
> > >>>>
> > >>>>
> > >>>> Thanks,
> > >>>> Pavel
> > >>
> > >> --
> > >> Best regards,
> > >> Pavel
> >
>
> --
> Daniel Kulp
> [hidden email]
> http://www.dankulp.com/blog
>



--
Best regards,
Pavel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Pavel-3
Hi,

I'd like now to spread this behaviour to all endpoints, not just secured
ones. Basically, hook that interceptor to CXF bus.

And this is because certain consumers use woodstox, or generally speaking,
validate content.

My understanding is that I need woodstox to kick in for every single
request. And the way to do that is to add "SAAJOutInterceptor" explicitly as
well. Do you see issues with that approach?

Thanks!
Pavel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Pavel-3
I did implement this approach and have not noticed issues so far. I'll write
back if I notice any.

Pavel

On Tue, Dec 29, 2009 at 1:04 PM, Pavel <[hidden email]> wrote:

> Hi,
>
> I'd like now to spread this behaviour to all endpoints, not just secured
> ones. Basically, hook that interceptor to CXF bus.
>
> And this is because certain consumers use woodstox, or generally speaking,
> validate content.
>
> My understanding is that I need woodstox to kick in for every single
> request. And the way to do that is to add "SAAJOutInterceptor" explicitly as
> well. Do you see issues with that approach?
>
> Thanks!
> Pavel
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"

Daniel Kulp
Administrator
On Tue December 29 2009 5:44:36 pm Pavel wrote:
> I did implement this approach and have not noticed issues so far. I'll
>  write back if I notice any.

You can also set a "disable.outputstream.optimization" property on the
endpoint/bus to true to have it disable the direct writing to the outputstream
and always go through the XMLStreamWriter.  Should accomplish the same thing
without the overhead of having the SAAJModel created.

Dan



> Pavel
>
> On Tue, Dec 29, 2009 at 1:04 PM, Pavel <[hidden email]> wrote:
> > Hi,
> >
> > I'd like now to spread this behaviour to all endpoints, not just secured
> > ones. Basically, hook that interceptor to CXF bus.
> >
> > And this is because certain consumers use woodstox, or generally
> > speaking, validate content.
> >
> > My understanding is that I need woodstox to kick in for every single
> > request. And the way to do that is to add "SAAJOutInterceptor" explicitly
> > as well. Do you see issues with that approach?
> >
> > Thanks!
> > Pavel
>

--
Daniel Kulp
[hidden email]
http://www.dankulp.com/blog
Loading...