[
https://issues.apache.org/jira/browse/CXF-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552083
]
bmargulies edited comment on CXF-1289 at 12/15/07 7:47 AM:
-----------------------------------------------------------------
These characters are not valid XML 1.0 characters at all. To send them around,
you need XML 1.1 (supported by nearly nothing) or to use base64 or an
attachment. It would be reasonable to open a JIRA asking for CXF to diagnose
it. Since CXF depends on other toolkits to serialize to XML, and since
perfomance is a big issue, we would probably stick to inviting you to implement
an interceptor object for this purpose. Or to add the escapes if it makes your
application work.
You will, I think, find exactly the same behavior from a wide spectrum of Java
XML/Web Service kits.
Escaping it, however, doesn't make any difference in it's legitimacy. The XML
1.0 standard is quite clear. Unicode characters excluded from the Char
production are not permitted. Representing them as entities doesn't change them
or make them valid.
Your report doesn't tell me enough to understand what Firefox has to do with
all of this. I certainly suffer from many firefox defects every day, so I'm
afraid that I can't assent to the statement that 'Firefox is absolutely not
defective.' It may be defective in this particular aspect, or it may not be.
However, you haven't supplied much information. If Firefox likes these
characters better as entities in XML1.0 than not, then I'm absolutely going
down with the ship that Firefox is wrong. If, on the other hand, we are talking
HTML, then this is a different story.
What, precisely, are you doing? Exactly how are you talking to CXF with
Firefox? What goes wrong?
See http://www.w3.org/TR/REC-xml/#charsets for more information here.
was (Author: bmargulies):
First, I realize that I lumped two disparate phenomena. 0x1b is not a valid
XML 1.0 character at all. To send it around, you need XML 1.1 (supported by
nearly nothing) or to use base64. It would be reasonable to open a JIRA asking
for CXF to diagnose it. Since CXF depends on other toolkits to serialize to
XML, and since perfomance is a big issue, we would probably stick to inviting
you to implement an interceptor object to to diagnose these.
Escaping it, however, doesn't make any difference in it's legitimacy. The XML
1.0 standard is quite clear. Unicode characters excluded from the Char
production are not permitted. Representing them as entities doesn't change them
or make them valid.
0x27, on the other hand, is just a character, and any standard-conforming XML
parser has to accept it as-is in pc-data. If Firefox does not, I'd like to see
the implementor's justification as a reference to a standard.
Your report doesn't tell me enough to understand what Firefox has to do with
all of this. I certainly suffer from many firefox defects every day, so I'm
afraid that I can't assent to the statement that 'Firefox is absolutely not
defective.' It may be defective in this particular aspect, or it may not be.
However, you haven't supplied much information.
What, precisely, are you doing? Exactly how are you talking to CXF with
Firefox? What goes wrong?
> XML contains binary data (ASCII 27, ^[, ESC)
> --------------------------------------------
>
> Key: CXF-1289
> URL: https://issues.apache.org/jira/browse/CXF-1289
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0.2, 2.0.3
> Reporter: Scott Anderson
>
> I've got a SOAP request that results in a string with an ESCAPE code (ASCII
> 27, ^[, ESC), and it isn't being transformed in to XML properly. CXF leaves
> it as its binary value, instead of converting to  or 
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
