Wednesday, September 17, 2014
Friday, February 14, 2014
The default DataContractSerializer used in WCF will serialize ‘strings containing control characters with a hexadecimal value below 20 as XML entities.’ This is obviously going to produce invalid XML 1.0.
But it was interesting to find that XML 1.1 spec makes valid ‘the use of character references to the control characters #x1 through #x1F, most of which are forbidden in XML 1.0.’ In fact, it makes all Unicode characters valid.
[#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
I wonder then if we can make WCF use XML 1.1 only? I don’t know – but as per Whats New in SOAP 1.2 SOAP 1.1 uses XML 1.0, and for SOAP 1.2 ‘it is left to the specification of a binding to an underlying protocol to specify the XML serialisation used in underlying protocol data units. The HTTP binding specified in [SOAP 1.2 - Part 2] uses XML 1.0 as the serialisation of the SOAP message infoset.’ So it may not be readily possible to make WCF use XML 1.1, even if ones decides to support only SOAP 1.2. It’ll require more research
Tuesday, January 21, 2014
org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 24; Character reference "&# at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
Although the character that caused the exception was not shown here, one of my colleagues used the WCFTestClient to get at the actual SOAP message (see below) and it showed some interesting looking characters like  and  in the message field.
Thanks to a post on stackexchange these did, in fact, turn out to be invalid XML characters. As per the Characters section of XML spec from W3C only these characters are valid<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1">.../GetErrorsResponse</a:Action> <a:RelatesTo>urn:uuid:96e19d12-29c6-4e62-9f97-3f69bed539c6</a:RelatesTo> </s:Header> <s:Body> <GetErrorsResponse xmlns="AppSecInc.Checks.Service"> <GetErrorsResult xmlns:b="http://schemas.datacontract.org/2004/07/.." xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> ... <b:Error i:type="b:ScanError"> <b:Message>..: Exception Information Exception type=WeOnlyDo.Exceptions.SSH.TimeoutException Message=Timeout occurred due to inactivity. Source=WeOnlyDo.Client.SSH Data=System.Collections.ListDictionaryInternal StackTrace= at  .(String , String& , Int32 , Int32& , String& ) at WeOnlyDo.Client.SSH.Execute(String Command, String Prompt, Int16 Timeout) ... </b:Message> <b:Severity>Error</b:Severity> <b:Timestamp>2013-12-10T03:22:29</b:Timestamp> </b:Error> ... </GetErrorsResult> </GetErrorsResponse> </s:Body> </s:Envelope>
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
At least, by default, WCF does not seem to do anything special about them. I do not know if anything could be done at the WCF level, but I want to explore if an extension to WCF can be implemented that will filter such invalid characters.
Monday, January 20, 2014
I was a bit surprised that one can’t revoke access to any of the functions under the system defined SYSIBM and SYSFUN schemas. Although these are system defined, it seems strange that DB2 does not allow revoking access to any of them. For example, there is a function called ‘GET_DBM_CONFIG’ in 8.2 which gives a lot of configuration related information to PUBLIC and you can’t revoke access to it.
db2 => revoke execute on sysfun.get_dbm_config from test
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0204N "SYSFUN.GET_DBM_CONFIG" is an undefined name. SQLSTATE=42704