Changes in ASP Features in IIS 5.1
ASP has undergone several important changes and enhancements. If you are updating your application from a previous version of ASP, you should be aware of these changes.
Changes in ASP Features
Buffering On by Default
In IIS 4.0, response buffering was off by default. In IIS 5.1, unless a script specifically turns off buffering, its output is always buffered. This means that the final output is sent to the client at the completion of processing or when the script calls the Response.Flush method. When upgrading from IIS 4.0 to IIS 5.1, the IIS 4.0 settings are maintained. Therefore, response buffering remains off until it is turned on. For more information, see the Buffering Content section in the Sending Content to the Browser topic.
Response.IsClientConnected
In IIS 4.0, Response.IsClientConnected returned the correct information only if an ASP file sent content to the browser. In IIS 5.1, an ASP file can use the IsClientConnected property prior to sending content to the browser.
Improved Include File Security
In IIS 4.0, when an include file resided in a virtual root mapped to a physical path, ASP did not use the security credentials of the physical path to process the file. In IIS 5.1, ASP applies the credentials of the physical path when processing include files. For more information, see Including Files.
Default Document Query String Behavior
In IIS 5.1, if an .asp (or .cdx) file is configured as the default document, it can now receive a query string from a URL that does not specify the default document. For example, the URLs https://www.microsoft.com/default.asp?newuser=true and https://www.microsoft.com/?newuser=true will both send a query string value to the default .asp file.
Transaction Flags
IIS 4.0 used the required, requires new, and not supported transaction parameters to indicate that ASP was starting a new transaction. In IIS 5.1, this behavior is unchanged. However, if an .asp file executes a transacted .asp file using the new Server.Execute or Server.Transfer methods, then the transaction flag state is maintained for the second .asp file. If the second .asp file's transaction flags indicate that transactions are supported or required, then the existing transaction will be used and a new transaction will not be started.
Behavior of Both-Modeled Objects
A Both-Modeled COM object which does not support the Free-Threaded Marshaller will fail if it is stored in Application state. Both-Modeled components must aggregate the Free-Threaded Marshaller to be stored in Application state.
Configurable Entries Moved to the Metabase
The following IIS 4.0 registry entries are now in the metabase:
ProcessorThreadMax
ErrorsToNTLog
For IIS 5.1, all configurable parameters for ASP can be modified from the metabase.
Security for Local Server COM Objects
IIS uses a new Windows COM feature called cloaking to enable local server applications instantiated from an .asp file to have the security context of the originating client. In previous versions, the identity assigned to the local server COM object depended on the identity of the user who created the object instance.
Objects Released Earlier
In IIS 4.0, COM objects were only released when ASP finished processing a page. In IIS 5.1, if a COM object does not use the OnEndPage method and the reference count for the object is zero, then the object is released prior to the completion of processing.
New ASP Features
New Flow Control Capabilities
The ASP Server object now has two new methods that you can use to control program flow: Server.Transfer and Server.Execute. Rather than redirecting requests, which requires an expensive round-trip to the client, you can use these methods to transfer requests directly to anASP file, without leaving the server. For more information, see Sending Content to the Browser.
Error Handling
ASP now has a new error-handling capability, so that you can trap errors in a custom error messageASP file. You can use the new Server.GetLastError method to display useful information, such as an error description or the line number where the error occurred. For more information, see ASPError Object.
Scriptless ASP
Because static content is usually processed more quickly than server-side content, it was previously better to assign anASP file extension only to files that contained ASP functionality. Whenever you needed to add ASP functionality to your static .html files, you had to manually addASP file extensions to correct related hyperlinks. With this latest release of ASP, however,ASP files that do not contain server-side functionality are now processed more quickly than ever before. So, if you are creating an evolving Web application in which files may eventually require ASP functionality, you can now conveniently assign those filesASP file extensions, regardless of whether they contain static or server-side content. For more information, see Creating ASP Pages.
Performance-Enhanced Objects
ASP now provides performance-enhanced versions of its popular installable components. These objects will scale reliably in a wide range of Web publishing environments. For more information, see Rotating Advertisements.
XML Integration
Extensible Markup Language (XML) enables you to semantically describe the complex structure of data or documents, which can then be shared across a variety of applications, clients, and servers. Using the Microsoft? XML Parser, included with Microsoft? Internet Explorer version 4.0, or later, you can create server-side applications enabling your Web server to exchange XML-formatted data with Internet Explorer version 4.0 or later, or with other servers having XML parsing capabilities. For more information, see the Microsoft XML Web site.
Windows Script Components
ASP supports Microsoft's powerful new scripting technology, Windows Script Components. Now you can turn your business logic script procedures into reusable Component Object Model (COM) components that you can use in your Web applications, as well as in other COM-compliant programs. For more information, see Using Components in ASP Pages.
ASP Self-Tuning
ASP now detects when executing requests are blocked by external resources. It automatically provides more threads to simultaneously execute additional requests and to continue normal processing. If the CPU becomes overburdened, ASP curtails the number of threads. This reduces the constant switching that occurs when too many nonblocking requests are executing simultaneously. For more information, see the metabase property reference for AspThreadGateEnabled.
Server-Side Include with SRC Attribute
You can now use the HTML <SCRIPT></SCRIPT> tag's SRC attribute to do server-side includes. When you use the SRC attribute to specify a virtual or relative path, and use the RUNAT=SERVER attribute to denote server-side execution, you can achieve the same functionality as the #Include directive. For more information, see Including Files.
Encoded ASP Scripts
Traditionally, Web developers have been unable to prevent others from viewing the logic behind their scripts. ASP now supports a new script-encoding utility provided with Microsoft? Visual Basic Scripting Edition (VBScript) and Microsoft? JScript 5.0. Web developers can apply an encoding scheme to both client and server-side scripts that makes the programmatic logic appear as unreadable ASCII characters. Encoded scripts are decoded at run time by the script engine, so there's no need for a separate utility. Although this feature is not intended as a secure, encrypted solution, it can prevent most casual users from browsing or copying scripts. For more information, visit the Windows Script Technologies Web site.
International ASP Development
Two new properties were added to the Response object: Response.CodePage and Response.LCID. These properties provide page level control over code page and locale settings for dynamic strings, without having to enable sessions. Session.CodePage and Session.LCID still provide session level control over code page and locale settings for dynamic strings; however, they no longer can be inadvertently overwritten by @CodePage and @LCID. @CodePage and @LCID still affect static strings in Web pages. By default, all of these values are implicitly set by the default system ANSI code page (CP_ACP) and the default system locale (LOCALE_SYSTEM_DEFAULT). However, if the metabase properties AspCodePage or AspLCID are set for any Web site or virtual directory, these become the default values. The metabase properties allow for global.asa files that need different code pages than the system default. Improved UTF-8 support includes support for surrogate characters and support for localized characters in the intrinsic objects, like form data and server variables.