Quick test for ActiveX?

[Evertjan.]

Neil Gould wrote on 02 sep 2009 in
microsoft.public.inetserver.asp.general:

Sorry for the confusion, but no, I'm not talking about any client-side
code, if by that you mean some custom ASP code installed on a user's
machine to interact with the site.

It seems you still do not understand what ASP is, Neil.

ASP prepares the server for sending a stream to the client.
ASP reads part of the serverside file code [in vbscript or jscript]
to do this and to do things on the server, like data base manipulation..
The client usually is a browser in the clientside machine.

So there CANNOT be "some custom ASP code installed on a user's
machine to interact with the site."

ASP is not interested in what browser or other programme on the client it
sends its rendered stream to.

Ony the ASP code can sniff the request header, it is a server afterall, and
change the rendered steam depending on that header's content.

So better not only not talk about that, but also not and never think about
that. You are confusing the neighbours.

 

[Bob Barrows]

Bob,


Please help me to understand your perspective. As I understand it,
the ASP code in question is _all_ server-side,

exactly ... which makes Mark's information irrelevant. He was talking
about the effect of browser settings on the use of recordets in
_cleint-side_ code.

but some operations
behave differently dependent upon activex settings.

And that's what has me baffled. There is no way that client-side
settings could interfere with server operations, unless the client-side
setting was interfering with the transfer of data from the client to the
server.I've yet to see this behavior reproduced.

Mark wrote:
"There are several ActiveX-related settings, many of which only
affect a subset of ActiveX objects. There is a single setting to
disable them all, but the more selective settings still apply even
when ActiveX in general is enabled."

Does this not imply that some ADO functions will be affected by
activex settings, others not?

YES!! _client-side_ script that uses ADO objects will certainly be
affected by client browser settings. Specifically, this:
<script type="text/javascript">
var rs;
rs=new ActiveXObject("ADODB.Recordset")
</script>
will break if browser security settings don't allow activex objects to
be created in client-side script.

If so, is that somehow different from
my initial observation and resultant line of questioning?

Again, yes. Mark was answering a different question: he was talking
about client-side operations being effected by browser security
settings. You're talking about server-side code being effected by client
security settings. This is not possible.

Again:
"ADODB.Recordset is "marked safe for scripting" but is not included
in IE8's stock "PreApproved" list. The bad news is it may seem
awfully hit-and-miss; the good news is that usually you're only one
or two settings changes away from working. "

As I read it, this says that settings in IE8 can cause adodb.recordset
operations to fail,

.... in client-side code, not in server-side code. Server-side code does
not run in a browser!

but it is possible that some (if not all will

succeed) because the default setting for IE8 will not interrupt the
process. Is this an incorrect interpretation of Mark's message?

Yes, finally.

And, finally:
"ADODB.Stream, otoh, is not only "not marked as safe for scripting,"
there is also a kill bit for it, published via Windows Update (and
re-published every time a new kill bit is added, so you can count on
it getting broken again every time you fix it.)"

This would be relevant if it affected the server's ability to run the
code. But such an update would not be affected by activex being allowed
or not allowed in the browser.

This seems consistent with the above, in that ADODB.stream operations
are likely to fail by default due to ActiveX settings, and is
consistent with my observations of the problem.

It would certainly be consistent if you were using these ADODB objects
in client-side code.

Sorry for the confusion, but no, I'm not talking about any
client-side code, if by that you mean some custom ASP code installed
on a user's machine to interact with the site.

No. ASP is not the code. ASP is the server-side "platform" in which
server-side script is executed.

Client-side script is code that runs in the browser. In IE, it can be
either vbscript, jscript or javascript. In other browsers it is pretty
exclusively javascript. If you can see the script when you view a page's
source in the browser, you are looking at client-side script.

What are the exact settings that need to be made to cause the behavior
to occur, please. As Mark said, there are many activex settings in the
browser configuration. And which browsers are we talking about please?

If I follow you, your interpretation of Mark's quotes above suggests
that all of these ASP operations should succeed regardless of ActiveX
settings on the user's machine because they are server-side
operations?

Yes, some browsers don't even support activex - would file transfers
work if activex was required?

Since that isn't what happens, and success or failure can
be determined by ActiveX settings on the browser, what am I missing?

You're missing what the root symptom actually is: what is actually
missing from the Request that is causing the server-side code to fail.

Well, those certainly are the questions. ;-)

So what is the answer? At what point in the process do you see the
failure?

The other question being, why does it succeed when ActiveX is
available in the client-side browser?

I can't tell that without seeing the behavior.

 

[Bob Barrows]

Hi all,

One of our sites use classic ASP, and has been running without major
problems. However, some users are getting errors with some ADO
functions after "upgrading" to IE8, and I suspect that the issue is
related to ActiveX not being enabled on their system, as I can
generate the same error by disabling ActiveX or using a browser that
doesn't support ActiveX. Anyone know of a quick-and-not-so-dirty way
to test for ActiveX using classic ASP?

Here is another repro using clsupload. Exactly what do I have to disable
in my browser to make this stop working?

<%@ Language=VBScript %>
<!--#INCLUDE FILE="clsupload.asp"-->


<%

set o = new clsUpload
if o.Exists("cmdSubmit") then

'get client file name without path
sFileSplit = split(o.FileNameOf("txtFile"), "\")
sFile = sFileSplit(Ubound(sFileSplit))

o.FileInputName = "txtFile"
o.FileFullPath = Server.MapPath(".") & "\" & sFile

o.save

if o.Error = "" then
response.write "Success. File save Thank You for the file."
else
response.write "Failed due to the following error: " & o.Error
end if

end if
set o = nothing
%>


<HTML>
<HEAD>
</HEAD>
<BODY>

<FORM action="" method=POST id=form1 name=form1
ENCTYPE="multipart/form-data">
<INPUT type="file" id=text1 name=txtFile>
<INPUT type="submit" value="Submit" id=submit1 name=cmdSubmit>
</FORM>
</BODY>
</HTML>

 

[Neil Gould]

Bob Barrows wrote:

... in client-side code, not in server-side code. Server-side code
does not run in a browser!

but it is possible that some (if not all will

Yes, finally.

As in... "Yes, we have no bananas"?

Client-side script is code that runs in the browser. In IE, it can be
either vbscript, jscript or javascript. In other browsers it is pretty
exclusively javascript. If you can see the script when you view a
page's source in the browser, you are looking at client-side script.

Just to be clear, I'm not talking about any code that can be seen when
viewing the page's source.

What are the exact settings that need to be made to cause the behavior
to occur, please. As Mark said, there are many activex settings in the
browser configuration. And which browsers are we talking about please?

I'm talking about IE (it would be sufficient to limit users to IE for this
purpose if the problem remains indeterminate and no other solution can be
found). The upload operation reliably fails with IE >= 6 if ActiveX is
globally disabled and fails with any browser that doesn't support ActiveX,
e.g. FireFox (don't know about the various ActiveX emulators for FF). That's
where I started with all this, and what drove me here.

You're missing what the root symptom actually is: what is actually
missing from the Request that is causing the server-side code to fail.

It's quite likely that I'm missing what the root cause of the problem
actually is, as this discussion would be unnecessary. If you think my focus
should be on the Request object, please explain your thinking and I'll
explore it further.

So what is the answer? At what point in the process do you see the
failure?

As best I can determine, it is after Request.BinaryRead and before the file
transfer takes place. There is no error given ("ON ERROR RESUME NEXT" ... is
disabled), the process just aborts.

Believe it or not, this discussion has been helpful, and again thanks. At
least I have some things to look into.

Neil

 

[Neil Gould]

Here is another repro using clsupload. Exactly what do I have to
disable in my browser to make this stop working?

<%@ Language=VBScript %>
<!--#INCLUDE FILE="clsupload.asp"-->


<%

set o = new clsUpload
if o.Exists("cmdSubmit") then

'get client file name without path
sFileSplit = split(o.FileNameOf("txtFile"), "\")
sFile = sFileSplit(Ubound(sFileSplit))

o.FileInputName = "txtFile"
o.FileFullPath = Server.MapPath(".") & "\" & sFile

o.save

if o.Error = "" then
response.write "Success. File save Thank You for the file."
else
response.write "Failed due to the following error: " & o.Error
end if

end if
set o = nothing
%>


<HTML>
<HEAD>
</HEAD>
<BODY>

<FORM action="" method=POST id=form1 name=form1
ENCTYPE="multipart/form-data">
<INPUT type="file" id=text1 name=txtFile>
<INPUT type="submit" value="Submit" id=submit1 name=cmdSubmit>
</FORM>
</BODY>
</HTML>

Thanks, Bob...

I'll look into it and let you know.

Neil

 

[Bob Barrows]

I'm talking about IE (it would be sufficient to limit users to IE for
this purpose if the problem remains indeterminate and no other
solution can be found). The upload operation reliably fails with IE
doesn't support ActiveX, e.g. FireFox (don't know about the various
ActiveX emulators for FF). That's where I started with all this, and
what drove me here.

So all I would need to do is run my repro in FF and it should fail? I'll
do that when I get home tonight.

 

[Mark McGinty]

Mark!


Thanks very much for this response! It hits the issue I'm wrestling with
squarely on the head. Now, I'll try to absorb your comments to see if
there
is a way to address this matter. Could you tell me more about fixing
issues
with IE8 and ADODB.Stream (These users do need to transfer binary files to
the site via ASP)?

The direct answer to your question is, you must clear the kill bit in the
registry on the client system. I can never remember the exact key, so this
is how I find it:

Search the registry for "ADODB.Stream";
Copy its CLSID into the clipboard;
Select the key after HKLM\Software\Classes in regedit;
Search for the CLSID from there (paste from clipboard into search);

This will take you to the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{00000566-0000-0010-8000-00AA006D2EA4}

Under that is a DWORD item named Compatibility flags. The value 0x0400 is
the imfamous kill bit; set it to 0, kill bit is clear, ADODB.Stream rides
again. (You must close all open instances of IE before it takes affect.)

But be advised that every single time a new kill bit is added to the list of
patches, Windows Update will break ADODB.Stream again.


Now as for the rest of the thread (that has been posted since I was last
here)... wow, a storm of confusion! My comments pertained exclusively to
use of ADO in client side script (assumed to be running in the context of an
HTML document, rendered by IE.) If you create an ADO object in code in a
SCRIPT tag (that does not set the runat=server attribute) then that object
is created on the client. Whether or not ASP was used to emit that script
is of no consequence.

I think the lines get blurred when we fail to consider what's being rendered
to the response (which may well include some script code) as opposed to
what's running on the server. A conscious effort must be made to clearly
understand which side everything is running on. (A debugger can be of great
assistance, when trying to visualize this.)

Bob, I assumed that he has some client-side ADO usage based on the way he
described the problem, and how/when it manifested. If the problem was\is
affected by changes to browser ActiveX settings, and the operative object is
ADODB, then by definition he must be using client-side ADO (whether he
realizes it or not.)

Also, the scenario he described was familiar, I have had occasion to use
client-side ADO, and I've even used the Stream [with a Recordset] to upload
binary content to SQL image fields. (I realize storing files in the db is
not considered a 'best practice', but assert that it can be the best
solution in some scenarios.)

With binary data Recordset.Field(x).SetChunk cannot be used in a script,
because there is no reliable way to read the binary data from file to a
variable. ADODB.Stream.LoadFromFile, otoh, does load binary data, and the
return of the Read method can be assigned to a long-binary field's value
property. The Recordset can then be persisted to XML and sent to the
server; the persistance provider encodes the binary data as hex-text. (A
server-side Stream could be used to write the binary data to file.)

This combination of client-side and server-side ADO makes some sense when
the data is going directly into a db, but as we've established, using a
stream on the client is impractical for all but a very obscure niche (that
can tolerate ongoing random breakage that requires user intervention to
fix.)

Otoh, it does not make sense when uploading to the server's file system,
posting the file in a form, and calling BinaryRead to get it from the
request is entirely more practical, and more efficient as well. The only
trick is stripping the MIME header off of the data. A server-side
ADODB.Stream comes in damn handy when performing this task, but as Bob has
said [in an extreme number of different ways] that is not affected in any
way by client browser settings (it merely adds yet another layer of
semantics confusion.)


Hope this clears it up at least to some degree. (Apologies for not watching
this thread a little more closely.)


-Mark

 

[Neil Gould]

Mark,

Mark!


Thanks very much for this response! It hits the issue I'm wrestling
with squarely on the head. Now, I'll try to absorb your comments to
see if there
is a way to address this matter. Could you tell me more about fixing
issues
with IE8 and ADODB.Stream (These users do need to transfer binary
files to the site via ASP)?

The direct answer to your question is, you must clear the kill bit in
the registry on the client system. I can never remember the exact
key, so this is how I find it:

Search the registry for "ADODB.Stream";
Copy its CLSID into the clipboard;
Select the key after HKLM\Software\Classes in regedit;
Search for the CLSID from there (paste from clipboard into search);

This will take you to the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{00000566-0000-0010-8000-00AA006D2EA4}

Under that is a DWORD item named Compatibility flags. The value
0x0400 is the imfamous kill bit; set it to 0, kill bit is clear,
ADODB.Stream rides again. (You must close all open instances of IE
before it takes affect.)

But be advised that every single time a new kill bit is added to the
list of patches, Windows Update will break ADODB.Stream again.


Now as for the rest of the thread (that has been posted since I was
last here)... wow, a storm of confusion! My comments pertained
exclusively to use of ADO in client side script (assumed to be
running in the context of an HTML document, rendered by IE.) If you
create an ADO object in code in a SCRIPT tag (that does not set the
runat=server attribute) then that object is created on the client.
Whether or not ASP was used to emit that script is of no consequence.

I think the lines get blurred when we fail to consider what's being
rendered to the response (which may well include some script code) as
opposed to what's running on the server. A conscious effort must be
made to clearly understand which side everything is running on. (A
debugger can be of great assistance, when trying to visualize this.)

Bob, I assumed that he has some client-side ADO usage based on the
way he described the problem, and how/when it manifested. If the
problem was\is affected by changes to browser ActiveX settings, and
the operative object is ADODB, then by definition he must be using
client-side ADO (whether he realizes it or not.)

Also, the scenario he described was familiar, I have had occasion to
use client-side ADO, and I've even used the Stream [with a Recordset]
to upload binary content to SQL image fields. (I realize storing
files in the db is not considered a 'best practice', but assert that
it can be the best solution in some scenarios.)

With binary data Recordset.Field(x).SetChunk cannot be used in a
script, because there is no reliable way to read the binary data from
file to a variable. ADODB.Stream.LoadFromFile, otoh, does load
binary data, and the return of the Read method can be assigned to a
long-binary field's value property. The Recordset can then be
persisted to XML and sent to the server; the persistance provider
encodes the binary data as hex-text. (A server-side Stream could be
used to write the binary data to file.)

This combination of client-side and server-side ADO makes some sense
when the data is going directly into a db, but as we've established,
using a stream on the client is impractical for all but a very
obscure niche (that can tolerate ongoing random breakage that
requires user intervention to fix.)

Otoh, it does not make sense when uploading to the server's file
system, posting the file in a form, and calling BinaryRead to get it
from the request is entirely more practical, and more efficient as
well. The only trick is stripping the MIME header off of the data.
A server-side ADODB.Stream comes in damn handy when performing this
task, but as Bob has said [in an extreme number of different ways]
that is not affected in any way by client browser settings (it merely
adds yet another layer of semantics confusion.)

Hope this clears it up at least to some degree. (Apologies for not
watching this thread a little more closely.)


-Mark

Thanks, once again for a thorough explanation. This is the exact method
employed by the upload script, so I believe you have a solid grip on what
I've been experiencing. I obviously haven't been clear in my presentation,
and that lead to much confusion about the server-side vs. client-side
matters. I thought that all ASP was server-side only, and couldn't be
affected by browser settings, but the odd instance of what I've observed
with non-ActiveX enabled browsers threw me for a loop.

I will look to see whether "runat=server" is explicitly set in the script,
and keep my fingers crossed that this will clear up the problem, as it makes
little sense to try to fix it on the client side, and it would be nice to
get beyond IE in our environment anyway.

 

[Neil Gould]

Thanks, Bob...

I'll look into it and let you know.

To follow up:

The variant of clsUpload associated with this approach does work with
FireFox and non ActiveX enabled browsers.

In comparing this variant with the one currently in use (that creates a BLOB
object), one functional difference aside from the ActiveX issue is that the
ASP processing code in this one doesn't work if separated from the form. For
example, having a form action = "someASPfile" that uses the above ASP code
and includes clsupload.asp results in the process failing due to the
"object" being closed.

So, to go this route, I have to replicate the processing and error trapping
code within each form page instead of using a common ASP-only (e.g. no HTML
content) file to execute the tasks. But, this is an acceptable trade-off.

Thanks, again to you and Mark for your help as I at least have a possible
solution at hand.

Neil

 

[Bob Barrows]

In comparing this variant with the one currently in use (that creates
a BLOB object), one functional difference aside from the ActiveX
issue is that the ASP processing code in this one doesn't work if
separated from the form. For example, having a form action =
"someASPfile" that uses the above ASP code and includes clsupload.asp
results in the process failing due to the "object" being closed.

This does not sound good either. I have several pages working that use this
approach (a file-processing page that handles requests from several form
pages). Could you show me exactly what I have to do in this ASP code to
reproduce your symptoms? Here it is again (I'm leaving out the form because
it should not be relevant):

<%@ Language=VBScript %>
<!--#INCLUDE FILE="clsupload.asp"-->
<%
set o = new clsUpload
if o.Exists("cmdSubmit") then

'get client file name without path
sFileSplit = split(o.FileNameOf("txtFile"), "\")
sFile = sFileSplit(Ubound(sFileSplit))

o.FileInputName = "txtFile"
o.FileFullPath = Server.MapPath(".") & "\" & sFile

o.save

if o.Error = "" then
response.write "Success. File save Thank You for the file."
else
response.write "Failed due to the following error: " & o.Error
end if

end if
set o = nothing
%>

 

[Neil Gould]

This does not sound good either. I have several pages working that
use this approach (a file-processing page that handles requests from
several form pages). Could you show me exactly what I have to do in
this ASP code to reproduce your symptoms? Here it is again (I'm
leaving out the form because it should not be relevant):

<%@ Language=VBScript %>
<!--#INCLUDE FILE="clsupload.asp"-->
<%
set o = new clsUpload
if o.Exists("cmdSubmit") then

'get client file name without path
sFileSplit = split(o.FileNameOf("txtFile"), "\")
sFile = sFileSplit(Ubound(sFileSplit))

o.FileInputName = "txtFile"
o.FileFullPath = Server.MapPath(".") & "\" & sFile

o.save

if o.Error = "" then
response.write "Success. File save Thank You for the file."
else
response.write "Failed due to the following error: " & o.Error
end if

end if
set o = nothing
%>

All that was necessary was to use the above code in a separate ASP file
called by the form.

If it works for you, perhaps the problem lies on the ISP's side of things.
I'm still sticking with using IIS 6, since there are so many odd reports of
issues regarding classic ASP and IIS 7.

 

[Bob Barrows]

All that was necessary was to use the above code in a separate ASP
file called by the form.

If it works for you, perhaps the problem lies on the ISP's side of
things. I'm still sticking with using IIS 6, since there are so many
odd reports of issues regarding classic ASP and IIS 7

As expected, separating the html form from the asp processing page had no
effect, so there is something else going on. Perhaps you have a parent-paths
issue? Is your html form in a separate folder from the asp page?

 

[Neil Gould]

As expected, separating the html form from the asp processing page
had no effect, so there is something else going on. Perhaps you have
a parent-paths issue? Is your html form in a separate folder from the
asp page?

Both HTML and ASP files were in the same directory, and I tried a number of
variants with the same result. The _only_ thing that worked on the ISP is
having the ASP code as part of the HTML form, and that makes no sense to me,
either, since no other functions are dependent on that arrangement. I'm not
even sure what the "object" was, other than the HTML form itself.

At least I have a non-ActiveX, browser-independent set of replacement files
running until this quirk can be sorted out, and it is encouraging to know
that it works somewhere in the world under some configuration or other. ;-)

Thanks again for your help.

 

[Neil Gould]

Bingo!

Thanks to your encouragement, I went back and tried another approach to
separating the HTML form from the ASP page, and managed to get it working.
At this point, I'm not sure what I was doing wrong before to get the error.
The good news is that I don't have to do much more than extract the code
from the page and "genericize" it a bit.

Thanks again, Bob!

Neil