ASP 3.0
for ASP 2.0
the Improvement
Some of the following features are improved or upgraded from version 2.0.
1,
buffering defaults to open
The ASP provides an optional output buffer. Starting with IIS 4.0, this allows the script to execute faster and provides control over the output flowing to the browser. In ASP 3.0 This improved performance is reflected by changing the default setting of the Reponse.buffer property to True. The default state buffer is open, which means that the final output is sent to the client only when the process completes, or when the script calls the Response.Flush or Response.End method.
Note that you can turn off buffering by setting the Response.Buffer property to False. Only in this way can the XML formatted output be sent to the client, allowing the XML parser to start working after receiving the output. You can also use Response.Flush to send part of a large page so that users can see some of the output quickly.
2,
response.isclientconnected
the Change
The Response.IsClientConnected property can be read without any content being sent to the client. In ASP 2.0, this returns accurate information only when at least a portion of the content is sent. This improvement addresses the problem that IIS must respond to each customer's request, even if the customer may have been transferred to another page or site. At the same time, if the customer does not reconnect within 3 seconds, the complete output information created on the server will be discarded.
3,
query string with default document
If a user accesses a site without providing the name of the requested page, the default document (if any) will be sent to the client. However, if they provide a query string appended to the URL, this is ignored in earlier versions of ASP, and the query string is sent to the default page in IIS 5.0 and ASP 3.0. For example, if the default page is default.asp in a directory with a URL: http://www.wrox.com/store/, both of the following cases send the name/value pair code=1274 to the Default.asp page:
http://www.wrox.com/store/?code=1274
http://www.wrox.com/store/default.asp?code=1274
4,
security for server-side include files
Server-side include files are often used for sensitive information, such as database connection strings or other access details. A virtual path (that is, a URL rather than a complete physical Disk file path) can be used to specify these files. In this case, the previous ASP version does not check the security settings of the file and the user's certificate, in other words, the authorized (authenticated) user and the anonymous Web server account are not compared to the file's access control list. In IIS 5.0 and ASP 3.0, these certificates will be checked to prevent unauthorized access.
5,
Configurable items are moved to the metabase
Registry entries for ProcessorThreadMax and Errorstontlog in IIS 5.0 are moved to the metabase, and all ASP configurable parameters are available through Active Directory and active Directory Service Interface (ADSI) is modified in the metabase.
6,
performance of two-thread objects in an application
For optimal performance in ASP with multiple concurrent requests, the component should be a two-threaded (both-threaded)-One-line apartment (single threaded Apartment,sta) and multithreaded unit (multi-threaded APARTMENT,MTA), and supports COM free-thread Marshaller (FTM). A two-thread COM object that does not support FTM, if stored in an ASP application state object, will cause the run to fail.
7,
release COM earlier
Object
In IIS 5.0, instantiated objects or components can be released earlier. In IIS 4.0, a COM object can be freed only when the ASP has finished processing one page. In IIS 5.0, if a COM object does not use the OnEndPage method and the object's reference count reaches 0, the object is freed before processing completes.
8,
by Default, ASP
Allow out-of-process Components
Custom local server components can now be instantiated from IIS without having to change the database settings. The metabase properties that control the local server instantiation aspallowoutofproccomponents The default value is 1, and the earlier version of IIS is 0.
9,
COM
Security of Objects
IIS uses a new cloaking feature provided by COM +, so a local server application instantiated from ASP can run in the security context of the original customer. In earlier versions, the security environment was assigned to the local server COM object and depended on the identity of the calling process.
10,
components run outside the process by default
In earlier versions of the ASP, all components created in the ASP page environment were run in the process by default.
To compromise between the performance of the component and the security of the Web server, for a virtual application, you can choose from the three options application protection in the Properties dialog box:
·
Low
(IIS Process
)
ASP virtual application executables and components of this setup run in the process (that is, memory space) of the Web server executable file (Inetinfo.exe). As a result, the Web server risks being affected by the failure of an executable file or component, yet this provides the fastest and least-resource application execution options.
·
Medium
(Pooled
)--This is the default setting
All application executables and components of this set of ASP virtual applications run in the process (that is, memory space) of a single shared DLLHost.exe instance. This protects the Web server executable (Inetinfo.exe) from the risk of failure of any one executable file or component. However, failure of an executable file or component can cause the DLLHost.exe process to fail, and all other executable files and components that reside there will fail.
·
High
(Isolated
)
All application executables and components of the ASP virtual application for this setting run in the process (that is, memory space) of a single DLLHost.exe instance, but each ASP application has its own DLLHost.exe instance. DLLHost.exe is unique to the application, which protects the Web server executable from any failure of an executable file or component. Microsoft recommends hosting up to 10 isolated virtual applications on any Web server.
The recommended configuration is to run a mission-critical application in their own process, high (Isolated), and all remaining applications running in a shared process, medium (Pooled). You can also set execute permissions for scripts and components that compose each virtual application (execute Permission), and three options are:
1)
None
:You cannot run a script or executable file in this virtual application. In practical terms, this provides a way to quickly and easily block an application if necessary.
2)
Scripts only
:Only script files, such as ASP, IDC, or others, are allowed to run in this virtual application and the executable file cannot run.
3)
Scripts and Executables
:Allow any script and executable file to run in this virtual application.
