Quick test for ActiveX?
in [ASP]
|
From: Bob Barrows on 1 Sep 2009 17:14 Mark McGinty wrote: > > Luckilly you can use DOMDocument to do most of what was done with > Stream -- handling of binary data being the notable exception. But > since you can POST binary file data to the server without even > needing any client-side script at all, if you absolutely need a > Stream, post the data to the server and create a Stream there. > > You mentioned file upload as a problem... if you're loading-up a > varbinary field in a recordset and sending the recordset to the > server, to do this you should know that encoding doubles the size of > the data in XML, and if the XML is Unicode, it doubles it again. > Post it in a form and read it from the request instead, it's > significantly more efficient and not that hard to do... imho, of > course. > Hi Mark, Good to see you back here - it's been a while. Good information which I've filed for future reference. Unfortunately, you've gone to a lot of trouble to answer a question that it turns out the OP wasn't really asking, since we've finally established that ADO (and in particular, client-side ADO) was a red herring and the issue he really is having is where disabling activex prevents the selected file in the <input type="file"> box from being submitted to the server. I have failed to reproduce this behavior, but perhaps you could add some substance. -- HTH, Bob Barrows
From: Bob Barrows on 1 Sep 2009 17:20 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. I really believe we will not get to the bottom of this until we can see a small repro to allow us to see the behavior you are talking about. Your earlier suggestion about providing a url would be useless to us since we would not be able to see the server-side code. My suggestion is that you create a repro page (or two) that contains only the code and elements needed for us to see the behavior and post the code here so we can try to recreate the behavior ourselves. -- HTH, Bob Barrows
From: Neil Gould on 2 Sep 2009 06:59 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 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. It seems that a solution will most likely come from a couple of directions; tell IE8 users how to set their browsers to enable activex (again, Mark's comment about specific bit settings was enlightening), but that is not an ASP matter; or find an ASP file transfer method that doesn't require client-side activex, ergo my pursuit of such information here. Given our dialogue, I'm sure that my questioning has been awkward, and for that I apologize. > I really believe we will not get to the bottom of this until we can > see a small repro to allow us to see the behavior you are talking > about. Your earlier suggestion about providing a url would be useless > to us since we would not be able to see the server-side code. > My comment was that giving a url isn't _practical_ at this point. The reason is that the particular ASP code is in an administrative portion of the site that is not generally accessible, and providing access to it via usenet is, well, "unwise" comes to mind. Even then, you could observe the behavior with no more insights into the code, as you've pointed out above. > My > suggestion is that you create a repro page (or two) that contains > only the code and elements needed for us to see the behavior and post > the code here so we can try to recreate the behavior ourselves. > The "ASP upload" code amounts to about 1,000 lines, which is why I tried to describe the problem behavior and pointed to examples of clsUpload. I did look into your code example in a previous reply. I'm looking into the differences between your example and the clsUpload code, as both initially utilize Request.BinaryRead, so the actual problem may lie somewhere beyond pulling the file info from the HTML form. But, it all comes back to the clsUpload code failing if activex is not available client-side. Thanks for your continued efforts, Bob! Neil
From: Bob Barrows on 2 Sep 2009 07:22 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 (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). The standard html file selecter does not use ADO on the client side to transfer files. If it did, users that did not have MDAC installed would not be able to upload files, now would they? > 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. Nowhere did he say that server-side ADO operations could be affected by browser settings. Please, read it again. > > It seems that a solution will most likely come from a couple of > directions; tell IE8 users how to set their browsers to enable > activex (again, Mark's comment about specific bit settings was > enlightening), That's fine, if they want to go through that, but since it might not be addressing the actual problem, you might find it coming back to haunt you in the future. Also, some users may not be as inclined to lower their security shields as you may be hoping. > > I did look into your code example in a previous reply. I'm looking > into the differences between your example and the clsUpload code, as > both initially utilize Request.BinaryRead, so the actual problem may > lie somewhere beyond pulling the file info from the HTML form. But, > it all comes back to the clsUpload code failing if activex is not > available client-side. > But I haven't seen that behavior, yet. The code to retrieve the file name works fine regardless of my browser settings. Let's attack the symptom again: I think we've established that the file name is certainly present in the Request. 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? -- Microsoft MVP - ASP/ASP.NET - 2004-2007 Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM"
From: Neil Gould on 2 Sep 2009 09:48
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, but some operations behave differently dependent upon activex settings. 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? If so, is that somehow different from my initial observation and resultant line of questioning? 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, 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? 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 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. > (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. >> 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. > > 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? Since that isn't what happens, and success or failure can be determined by ActiveX settings on the browser, what am I missing? >> It seems that a solution will most likely come from a couple of >> directions; tell IE8 users how to set their browsers to enable >> activex (again, Mark's comment about specific bit settings was >> enlightening), > > That's fine, if they want to go through that, but since it might not > be addressing the actual problem, you might find it coming back to > haunt you in the future. Also, some users may not be as inclined to > lower their security shields as you may be hoping. > Exactly my concern. This is why I'm searching out details about the nature of ADO. >> I did look into your code example in a previous reply. I'm looking >> into the differences between your example and the clsUpload code, as >> both initially utilize Request.BinaryRead, so the actual problem may >> lie somewhere beyond pulling the file info from the HTML form. But, >> it all comes back to the clsUpload code failing if activex is not >> available client-side. >> > > But I haven't seen that behavior, yet. The code to retrieve the file > name works fine regardless of my browser settings. > Well, actually, your code appears to copy the file into the SafeArray and writes a subset of that information to the browser. Although the filename is included in that information, so far I haven't been able to extract the filename alone, though this may be due to the limited time I've had to explore the possibilities. It may be that the additional code in clsUpload requires client-side activex, but I can't see where that might be yet. > 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. ;-) The other question being, why does it succeed when ActiveX is available in the client-side browser? Thanks again, Neil |