Quick test for ActiveX?
in [ASP]
|
From: Evertjan. on 2 Sep 2009 11:01 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. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: Bob Barrows on 2 Sep 2009 11:27 Neil Gould wrote: > Bob, > > Bob Barrows wrote: >> Neil Gould wrote: >>> Bob, >>> >>> Bob Barrows wrote: >>>> Neil Gould wrote: >>>>> 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)? >>>>> >>>> Really? I thought we had established that you were not using ADO in >>>> client-side code? The issues Mark wrote about pertain solely to the >>>> use of ADO objects in client-side code ("Client-side use of Stream >>>> is totally impractical"), and should have no bearing at all on the >>>> problem you described to me. >>>> >>> The problem that I am trying to solve is directly addressed by >>> Mark's information; the IE8 behavior is exactly as he describes, >>> e.g. Recordset operations work properly without activex and some >>> other >> >> No, no ... you're totally missing the point. He was saying that >> _client-side_ recordset operations can fail >> > 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. > >> (he was still confused by >> your original question - as I initially was - and had come to the >> conclusion that you were using ADO 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. > >>> operations fail. Since all of these operations are implemented >>> server-side, hence my original confusion about which ADOs require >>> activex to be available client-side, as that is the single >>> repeatable aspect of the problem behavior. 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? >> >> Nowhere did he say that server-side ADO operations could be affected >> by browser settings. Please, read it again. >> > 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. >> Let's attack the symptom again: I think we've established that the >> file name is certainly present in the Request. >> > Yes. > >> What is actually >> failing in the clsUpload code? An attempt to use ADO to write the >> file to a database? An attempt to store it in the server's file >> system? >> > 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. -- HTH, Bob Barrows
From: Bob Barrows on 2 Sep 2009 13:34 Neil Gould wrote: > 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> -- HTH, Bob Barrows
From: Neil Gould on 2 Sep 2009 14:37 Bob Barrows wrote: Neil Gould wrote: >> 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. > 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. >> 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. > 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. >>> What is actually >>> failing in the clsUpload code? An attempt to use ADO to write the >>> file to a database? An attempt to store it in the server's file >>> system? >>> >> Well, those certainly are the questions. ;-) > > 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
From: Neil Gould on 2 Sep 2009 14:41
Bob Barrows wrote: > Neil Gould wrote: >> 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> > Thanks, Bob... I'll look into it and let you know. Neil |