This view allows you to map a certain web document type to a desired script processor that can handle the corresponding script type.
You can set the web document extension to be mapped to this script processor.
You can configure wildcard script maps by setting the extension field to: * .
In this field you can specify the module handler for your application mapping. This field is of Formatted Type.
When this field is empty, the Application Mapping will be deployed on all IIS versions. However, when a module value is present, deployment of that Application Mapping will be done only on IIS 7.0 and newer.
For ISAPI/CGI Script Maps, IIS 7 requires CgiModule/IsapiModule to be set as the ScriptMap's module. The user can do this from our UI but, because of the rule described above, will have the Application Mapping deployed only to IIS 7.0 and newer. However, if the script processor path ends with '.exe'/'.cgi'/'.dll' then the correspondent module will be added automatically to the mapping on IIS7 and newer. Thus leaving the module field empty for such ISAPI/CGI Script Maps guarantees that the script will be deployed on all IIS versions.
You can set the script processor file for the new web application mapping. The file can be from the installation package or external. This field is of Formatted Type and can be edited with the Smart Edit Control.
Add ISAPI/CGI Restriction
Allows dynamic content to execute on the target IIS server.
On IIS 6 the feature is called Web Service Extensions.
Select this option when you want the application to run in a directory without Execute permissions. This setting is intended primarily for script-based applications such as ASP and IDC that are mapped to an interpreter.
Check that file exists
Select this option to instruct the Web server to verify the existence of the requested script file and to ensure that the requesting user has access permission for that script file.
If the script does not exist or the user does not have permission, the appropriate warning message is returned to the browser and the script engine is not invoked. This option can be useful for scripts mapped to non-CGI executables like the Perl interpreter that do not send a CGI response if the script is not accessible.
Because the script will be opened twice, once by the server and once by the script engine, there is some performance cost to enabling this option.
Allows you to set the HTTP verbs that should be passed to an application.
These verbs are: GET, POST, HEAD, TRACE, PUT, DELETE, OPTIONS.
For a detailed explanation of these HTTP/1.1 methods please see: HTTP Methods article.