Altova Mailing List Archives


Re: Heads up, Update 955069 breaks transformNodeToObject in ASP

From: "Anthony Jones" <AnthonyWJones@------------.--->
To: NULL
Date: 11/15/2008 6:10:00 PM
"Luis Vargas" <Luis Vargas@d...> wrote in message 
news:AB0F7A56-440C-428E-8240-E7F08B300A01@m......
> "Anthony Jones" wrote:
>
>> This info is for those of you who are using the transformNodeToObject 
>> method
>> in an ASP page to send the results of the transform directly to the ASP
>> Response object.
>>
>> The security update 955069 includes a change in behaviour where the 
>> IStream
>> passed in the output parameter has its Commit method called where in 
>> older
>> version this never called.  The IStream implemention in on ASP Response
>> object will through an error if its Commit method is called.
>>
>> Workarounds:
>>
>>     1.  Don't install 955069 (not recommend its a security update).
>>     2.  Create an IStream wrapper object that delegates to an inner 
>> IStream
>> except the Commit method.
>>     3.  Don't use transfomNodeToObject just transformNode and 
>> Response.Write
>>     4.  Send XML and get your client to do the transform
>>
>> Option 2 only really an option if you the tools and the control over the
>> server to implement it.
>>
>> Option 3 if you were generating large content with buffering turned off
>> transformNodeToObject is pretty effecient, with transformNode and
>> Response.Write you are going to use more memory and will need a buffer 
>> size
>> big enough to handle the result (or slice up the result).  You will also
>> need to consider encoding, where ToObject would have encoded to CharSet
>> transformNode always returns unicode.  Hence the best approach would be 
>> to
>> set Response.CharSet = "UTF-8" (you were doing that already right?) and
>> Response.CodePage = 65001.  On 2000 SP4 with IIS5 this gets trickier 
>> still
>> because the Response object doesn't have a CodePage property, you would 
>> need
>> to do it on the session then set the codepage back to its original value
>> after the Write.
>>
>> Option 4 is well worthwhile if you can stand the upheaval but for new 
>> code
>> its worth considering.
>>
>>
>>
>
> Hi Anthony,
>
> Thanks for your help on all this. All the pages in my web site show the
> error that was not there before. Check it out. www.markallenonline.com
>
> I have a classic ASP web site and most of the pages use something like 
> this
>
> Dim objXML1
> Dim objXSL
> Set objXML1 = Server.CreateObject("Microsoft.XMLDOM")
> Set objXSL = getXMLDoc("default.xsl")
> call objXML1.transformNodetoobject(objXSL, Response)
>
> I am tempted to uninstall the security update (Workaround 1) if I can.
> However I would be willing to implement the wrapper you mentioned 
> (workaround
> 2). If it worked. I would do the coding. Every page unfortunately. Could 
> help
> me with some sample code for this. It would be appreciated.
>
> Workaround 3 I tried however, my web site works in three languages and 
> when
> I do the transform to an intermediate object document and then do
> Response.Write   I then loose all special foreign characters somehow. If I
> transform right to the response object the special characters in German 
> and
> Spanish show correctly   and works great.
>
> Workaround 4 is not an option for me.
>
> Again thanks for the help. I was waiting for something like this to happen
> with all the automatic updates.
>

Response.CodePage = 65001
Response.CharSet = "UTF-8"
Response.Write objXML1.transformNode(objXSL)

This code should work for all characters.

Does the above not work for you?
Can you provide an example characters you are having trouble with?

-- 
Anthony Jones - MVP ASP/ASP.NET

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.