This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

MIND


GEEK

Robert Hess

GEEK Recently, the drive where all of my Web log files are written to went down. Luckily, I had another server available in the same domain (at least, I thought so). I quickly mapped a network drive to the same drive letter (F:) as the old drive, made sure the same directory (weblogz) existed, and happily went about my business. Days later, I found that the event log was completely overwritten with IISLog errors: "Cannot create directory X." Every hit on the site was generating this error, and I had lost log activity for that time period. Can't Microsoft® Internet Information Server (IIS) write logs to a network drive? What is the problem?
GEEK You are correct. IIS doesn't write log files to networked drives. Log files are so active that the performance penalty for hitting them across a network connection would be very great. While to the casual user a network drive behaves exactly as a physically connected drive, there are underlying services and processes that are performing this transparent interaction. These extra steps will add a slight overhead to data accesses to a networked drive. In most cases, this overhead is negligible to the point of being unimportant. But applications that do significant data I/O often resort to performing lower-level access, which can only be done to local drives.
      
      
 GEEK Why does the following form give me an access denied error when I'm using Microsoft Internet Explorer 5.0? 

 <html>
 
 <BODY>
 
 <FORM id="theForm" enctype="multipart/form-data" method="post">
 
 <INPUT TYPE="FILE" name="f0" style="visibility:hidden"/>
 <p>
 <div onmousedown="theForm.tags('input')[0].click()">
 <center>click here and select a file</center>
 </div>
 <p>
 <div onmousedown="theForm.submit()">
 <center>click here to submit the file (causes "Access is Denied"
 error)</center>
 </div>
 
 </FORM>
 
 </BODY>
 </html>
GEEK The file upload feature on Web browsers is one that starts moving into very shaky territory. Consider that this capability allows a user to upload a file from their system to a foreign server. While there are many ways of using and interacting with this capability that pose no risk of transferring a file without the user's explicit permission, there are also a number of scenarios in which an immoral individual could attempt to circumvent these security capabilities.
      Thus, it appears as though almost any attempt to interact with a File Upload object programmatically will result in a security warning. While on the face of it I can't see a scenario in which your proposed implementation could result in a security concern, I expect that "safety first" was the motto emblazoned upon the minds of the Internet Explorer developers when they implemented this feature.
      Unfortunately, with the increasing number of crazy folks in the world trying to scam up any way they can of breaking through the security measures on browsers, it is prudent to first disable any feature that could potentially result in a security violation, then gradually enable some of those features in later versions as the possibilities for abuse lessen.
      
      
 GEEK Is there any way to force the update of more than one frame from inside a Visual Basic® 6.0 WebClass when it traps a SUBMIT event? I was hoping to trigger a WebClass event by placing a WebItem reference in the HTML code: 

 <BODY onload="StatusBar='wclMain.asp&WCI=WriteStatus' ">
StatusBar is the name of a frame and WriteStatus is a WebItem with its corresponding WriteStatus_Respond procedure.
GEEK A WebClass is a recent creation that allows you to take a slightly different approach to building up server-side processing on your Web site. It is important to remember that it adds functionality to the server, not the client. This can be both good and bad. The good part is that it doesn't place any additional expectations or requirements on the browser that folks might be using to navigate your site. The bad part is that you still remain limited to the same level of functionality that you expose to the client.
      The client limits your options for which frames are updated based upon what the user clicks on. There currently aren't any HTTP or HTML specifications that allow for retargeting the incoming response from the server to a different window, or for allowing multiple windows to be updated based on where the user clicks. For this sort of functionality, you need to rely on client-side script code.
      A WebClass just provides middleman support for consuming and disgorging content. Getting the content pumped into a separate frame from the one that initiated the request will require client-side script code that will participate in the dance. It doesn't really matter if you are running a WebClass, ASP, or CGI on the server; in the end, they are all simply pumping HTML back to the client.
      If the server knows the names of the frames on the client, then the HTML coming back to the client window can include script code that can attach to a second frame and either modify the content directly or simply force it to navigate to a different view.
      There are several ways of doing this, but I can give you one example here (see Figures 1 and 2). In this particular code, I am using ASP on the server and VBScript on the client.
      
      
 GEEK I realize that asking this question may disqualify me as a true geek, but it's a risk I must take. The following code works when dropped into an HTML page, but fails when dropped into an ASP page. 

 <script LANGUAGE="JavaScript1.2" 
     TYPE="text/javascript">
 <!--
     if (isMenu) {
     document.write("<SCRIPT LANGUAGE='JavaScript1.2'
                    SRC='JSFile1.js'><\/SCRIPT>");
     document.write("<SCRIPT LANGUAGE='JavaScript1.2'
                    SRC='JSFile2.js'><\/SCRIPT>");
     }
 //-->
 </script>
Here's the error I get back from ASP: 

 Active Server Pages error 'ASP 0138'
 Nested Script Block
 /<DirectoryName>/<ASPfilename>.asp, line 77
 A script block cannot be placed inside another script block.
GEEK The problem is that the server-side ASP parser/interpreter is designed to be extremely lightweight and as fast as possible. Unfortunately, this means that as it parses an ASP file on the server to identify where and when it needs to process code on the page, it isn't able to use as much muscle as it could if speed weren't an issue.
      To make a long story short, the ASP interpreter doesn't realize that the document.write line should be ignored, and in its first pass thinks this is something that it needs to parse. The problem is further complicated because in order for you to get the closing </SCRIPT> tag out, you have to escape the slash, thus essentially producing text that the ASP interpreter isn't able to see as the closing tag for the script. Fortunately, the solution is equally simple. All you have to do is disguise the opening <SCRIPT> tag in a similar fashion. Probably the easiest way to do this is to use 

 document.write("<" + "SCRIPT LANGUAGE='JavaScript1.2'
                SRC='JSFile1.js'><\/SCRIPT>");
which will prevent the ASP interpreter from thinking you are talking to it.
      
      
 GEEK Last week I was surfing the Microsoft Web site and I ran into an article on compatibility differences between Internet Explorer 4.5 for the Macintosh and Internet Explorer 4.0 for Windows®. Unfortunately, I didn't save the page as a Favorite, and now I can't find it. Could you help me find it?
GEEK It's hard to say exactly which page you were on. I wasn't able to locate a page that specifically dealt with compatibility issues between Internet Explorer 4.0 for Windows and Internet Explorer 4.5 for the Macintosh, but I was able to find a page on MSDN™ (http://msdn.microsoft.com/workshop/essentials/versions/xplatie4.asp) that discusses the availability of Internet Explorer 4.0 features on all supported platforms.
      You can also refer to the online DHTML references for this sort of information. For each property, method, and event supported by DHTML, there is an "Applies To" table at the bottom of the page that identifies which platforms and versions for which this option is available, as well as which elements it applies to. While it might be a little more time-consuming than a one-page end-all- be-all compatibility table, it should help you identify the appropriate HTML usage for your needs.
      The MSDN Online site hosts the Dynamic HTML references at http://msdn.microsoft.com/workshop/author.
      You might also want to check your browser's History pane, where all the pages you've visited in the last week appear. If you look under the listing for msdn.microsoft.com, you'll find all the MSDN pages you visited last week, and you might be able to identify the precise page where you found the compatibility information.

From the November 1999 issue of Microsoft Internet Developer.