Heads up, Update 955069 breaks transformNodeToObject in ASP

[Anthony Jones]

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.
--
Anthony Jones - MVP ASP/ASP.NET

[=?Utf-8?B?THVpcyBWYXJnYXM=?=]

"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.
--
Anthony Jones - MVP ASP/ASP.NET

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.

Luis Vargas

[Anthony Jones]

"Luis Vargas" <Luis Va****@discussions.microsoft.comwrote in message
news:AB**********************************@microsof t.com...

"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

[=?Utf-8?B?THVpcyBWYXJnYXM=?=]

"Anthony Jones" wrote:

>
"Luis Vargas" <Luis Va****@discussions.microsoft.comwrote in message
news:AB**********************************@microsof t.com...

"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

Hi Anthony,

Thanks for that. Changing the code page did it. Now characters like © or
the spanish Ñ show up correctly. I had the Response.charset set to UTF-8
already.

Now I just have to change all the pages.

Thanks

Luis Vargas