ISAPI_Rewrite 2.11 documentation

介绍

ISAPI_Rewrite 是一个强大规则基于url转发的操作引擎. 它很类似于Apache中的mod_Rewrite, 但它是专门为Microsoft IIS . 如果你要改变你的网站的URL转发规则,这个产品是正是你所需要的!

主要功能.

重写 将导致服务器继续请求处理与新URI 好象它由客户最初请求了。新URI 包括询问串部分(随后而来的问号) 并且也许指向所有简单的文件(象图象), 剧本(象ASP), 节目(象EXE), 等。

Proxiing 导致收效的URI 内部对待一个目标在其它服务器和(即规则处理中止这里) 立刻通过对ISAPI 引伸处理代理人请求。您必须确信, 收效的串是合法的URL 包括协议、主人, 等。否则您将得到错误从代理人。

改变方向 导致送一个直接反应以改方向指示(HTTP 反应代码302 或301) 有收效的URI 作为一个新地点。您能使用绝对资源定址器(和那由RFC 2616 要求) 在改变方向指示改请求方向对一个另外主人、口岸和协议。总改指示起因方向重写引擎停止规则序列处理。

规则被处理按出现的顺序在配置文件。ISAPI_Rewrite 运用服务器宽(全球性) 规则首先。然后它运用规则具体为IIS 网站处理请求(如果站点级规则是存在) 。没有递归请求或随后反转在处理次序(除了明确地引起的圈) 。如此, 请求处理从未将分成一个死循环。

在任一URI 修改ISAPI_Rewrite 保存原始之前请求URI 入HTTP 倒栽跳水被命名 X 重写Url。然后它可能被检索在ASP 使用Request.ServerVariables("HTTP_X_REWRITE_URL") 别名。

多个 RewiteCond 方针被RewriteRule 的 RewriteRule ( 或RewriteProxy) 方向性影响随后了而来 唯一。如此, 那些情况应该被考虑作为一个复杂规则的部份。

配置文件格式

有二类型配置文件- 全局性(服务器级) 和单独(站点级) 文件。全局性配置文件应该被命名 httpd.ini , 应该出现在ISAPI_Rewrite 安装根目录。单独配置文件应该被命名 httpd.ini , 能出现在真正站点物理根目录下。所有配置文件有同样格式。并且这是设置是按照窗口INI 文件的格式。 唯如果声明为ISAPI_Rewrite的规则，则必须在参考[ ISAPI_Rewrite ]的规则。所有规则应该被安置在这个部分并且每个规则应由换行符分开。任一文字在这个之外将被忽略。

httpd.ini 文件例子:

[ ISAPI_Rewrite ] # 这是评论 # 300 = 5 minutes CacheClockRate 300 RepeatLimit 20 # 对httpd.ini 和httpd.parse.errors 文件的块外在通入 RewriteRule /httpd(?:/.ini|/.parse/.errors) / [F,I,O] # 对帮手ISAPI 引伸 RewriteRule .*/.isrwhlp / [F,I,O] # 一些常见规 RewriteCond Host: (.+) RewriteRule (.*) /$1$2 [I]

当ISAPI_Rewrite 解析配置文件它创造误差记录文件名为 httpd.parse.error 在被解析的文件寻找的同样目录。 唯一明显的句法错误能被查出在解析期间。复杂句法错误和逻辑错误能被发现只在规则施行期间。如此, 他们不会被采伐入httpd.ini 。它是推荐检查一个新规则与 正则表达式测试工具 在投入规则之前入配置文件。

There are two types of configuration files - global (server-level) and individual (site-level) files. The global configuration file should be named httpd.ini and should appear in the ISAPI_Rewrite installation directory. The shortcut of this file is provided through the start menu. The individual configuration files should be named httpd.ini and could appear in physical root directories of virtual sites. All configuration files have the same format. And it is the format of a standard Windows INI file where settings are broken by sections. The only section allowed in this version of ISAPI_Rewrite is [ISAPI_Rewrite]. All directives should be placed in this section and each directive should be placed on a separate line. Any text outside this section will be ignored.

httpd.ini file example:

[ISAPI_Rewrite] # This is a comment # 300 = 5 minutes CacheClockRate 300 RepeatLimit 20 # Block external access to the httpd.ini and httpd.parse.errors files RewriteRule /httpd(?:/.ini|/.parse/.errors) / [F,I,O] # Block external access to the Helper ISAPI Extension RewriteRule .*/.isrwhlp / [F,I,O] # Some custom rules RewriteCond Host: (.+) RewriteRule (.*) /$1$2 [I]

When ISAPI_Rewrite parses configuration file it creates error log file named httpd.parse.error in the same directory where parsed file is located. Only obvious syntax errors could be detected during parsing. Complex syntax errors and logic errors could be found only during rules execution. So, they will not be logged into the httpd.ini. It is recommend to check a new rule with the Regular Expressions Testing Tool before putting a rule into a configuration file.

UriMatchPrefix directive

Syntax: UriMatchPrefix PrefixString

The UriMatchPrefix directive defines a string that will be prepended to TestVerbs of all subsequent RewriteRule, RewriteProxy, RewriteCond URL and RewriteHeader URL directives (i.e. to all test conditions on URI). This directive is a partial analog of Apache's RewriteBase directive. Default value for the UriMatchPrefix is empty string.

UriFormatPrefix directive

Syntax: UriFormatPrefix PrefixString

The UriFormatPrefix directive defines a string that will be prepended to FormatStrings of all subsequent RewriteRule and RewriteHeader URL directives (i.e. to all URI format strings). Default value for the UriFormatPrefix is empty string.

RewriteCond directive

Syntax: RewriteCond TestVerb CondPattern [Flags]

The RewriteCond directive defines a rule condition. Precede a RewriteRule or RewriteHeader or RewriteProxy directive with one or more RewriteCond directives. Conditions affect only the next immediately following rule (RewriteRule, RewriteHeader or RewriteProxy). Thus they are effectively bound to this rule. A rule with conditions will be applied only if it will match a test string and all its bound conditions will match theirs test strings.

• TestVerb

  Specifies verb that will be matched against regular expression.

  TestVerb=(URL | METHOD | VERSION | HTTPHeaderName: | %ServerVariable) where:

  • URL - returns Request-URI of client request as described in RFC 2068 (HTTP 1.1);
  • METHOD - returns HTTP method of client request (OPTIONS, GET, HEAD, POST, PUT, DELETE or TRACE);
  • VERSION - returns HTTP version;
  • HTTPHeaderName - returns value of the specified HTTP header. HTTPHeaderName can be any valid HTTP header name. Header names should include the trailing colon ":". If specified header does not exists in a client's request  TestVerb is treated as empty string.

    HTTPHeaderName = Accept: Accept-Charset: Accept-Encoding: Accept-Language: Authorization: Cookie: From: Host: If-Modified-Since: If-Match: If-None-Match: If-Range: If-Unmodified-Since: Max-Forwards: Proxy-Authorization: Range: Referer: User-Agent: Any-Custom-Header:

    For more information about HTTP headers and their values refer to RFC 2068.

  • ServerVariable - returns value of the specified Server Variable. For examlpe, SERVER_PORT. Complete list of the server variables could be found in the IIS documentation. Variable name should be prefixed with % sign. Note that server variable names are case sensitive. So, using %https instead of %HTTPS, for example, will always result in an empty value.

• CondPattern

  The regular expression to match TestVerb.

• [Flags]

  Flags is a comma-separated list of the following flags:
  
  

  • O (nOrmalize)

    Normalizes string before processing. Normalization includes removing of an URL-encoding, illegal characters, etc. Also, IIS normalization of an URI completely removes query string. So, normalization should not be used if query string is needed. This flag may be useful with URLs and URL-encoded headers.

Technical note:

Internally all regular expressions of a rule with conditions are being joined into a single regular expression of a kind:

(?:Condition1RegExp)/n(?:Condition2RegExp)/n.../n(?:ruleRegExp)

Then this single expression is being matched against a text string of combined headers. Missing headers and variables are considered as empty strings. Because special characters ^ and $ correspond to the beginning and the end of the combined text string (and not to the beginning and the end of an individual header string) theirs usage in a rule with conditions may result in a behavior completely different from the expected one. So, it is highly recommended to avoid usage of ^ and $ markers in rules with conditions.

RewriteRule directive

Syntax: RewriteRule Pattern FormatString [Flags]

The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once. Each directive defines one single rewriting rule. The definition order of these rules is important, because this order is used when applying the rules at run-time.

• Pattern

  Specifies regular expression that will be matched against Request-URI. See regular expression syntax section for more information.

• FormatString

  Specifies format string that will generate new URI. See format string syntax section for more information.

• [Flags]

  Flags is a comma-separated list of the following flags:

  • I (ignore case)

    Indicates that characters are matched regardless of a case. This flag affects RewriteRule directive and all corresponding RewriteCond directives.

  • F (Forbidden)

    Stops the rewriting process and sends 404 Not Found response (Not 403 Forbidden!. And this behaviour corresponds to the IIS 6 behaviour) to a client. Note that FormatString is useless in this case and could be set to any non-empty string.

  • L (last rule)

    Stop the rewriting process here and don't apply any more rewriting rules. Use this flag to prevent the currently rewritten URI from being rewritten further by following rules.

  • N (Next iteration)

    Forces rewriting engine to modify rule's target and restart rules checking from the beginning (all modifications are saved). Number of restarts is limited by the value specified in the RepeatLimit directive. If this number is exceeded N flag will be simply ignored.

  • NS (Next iteration of the same rule)

    Works like the N flag but restarts rules processing from the same rule (i.e. forces repeat of the rule application). Maximum number of single rule iterations is given by the RepeatLimit directive. But a number of single rule repeats does not count for the global number of repeats (i.e. repeats limit for a number of iterations caused by N flag is independent of a number of repeats caused by NS).

  • P (force proxy)

    Forces the result URI to be internally forced as a proxy request and immediately (i.e., rewriting rule processing stops here) put through the ISAPI extension that handles proxy requests. You have to make sure that the substitution string is a valid URI including protocol, host etc. or proxy will return an error.

  • R (explicit redirect)

    Force server to send immediate response to client with redirect instruction, providing result URI as a new location. Redirect rule is always the last rule.

  • RP (permanent redirect)

    Almost the same as the [R] flag but issues 301 (moved permanently) HTTP status code instead of 302 (moved temporary).

  • U (Unmangle Log)

    Log the URL as it was originally requested and not as the URL was rewritten.

  • O (nOrmalize)

    Normalizes string before processing. Normalization includes removing of an URL-encoding, illegal characters, etc. Also, IIS normalization of an URI completely removes query string. So, normalization should not be used if query string is needed. This flag is useful with URLs and URL-encoded headers.

  • CL (Case Lower)

    Changes case of a format result to lower.

  • CU (Case Upper)

    Changes case of a format result to upper.

RewriteHeader directive

Syntax: RewriteHeader  HeaderName  Pattern  FormatString  [Flags]

The RewriteHeader directive is more general variant of RewriteRule directive and it is designed to rewrite not only the URL part of client request, but any HTTP header. This directive can be used to rewrite, create or delete any HTTP headers, or even change method of the client request.

• HeaderName 

  Specifies a HTTP header that will be rewritten. Possible values are the same as for the TestVerb parameter in the RewriteCond directive. Thus, RewriteRule directive is a synonym to the RewriteHeader URL Pattern Format [Flags]

• Pattern

  Specifies regular expression that will be matched against specified header. See regular expression syntax section for more information.

• FormatString

  Specifies format string that will generate new header value. See format string syntax section for more information.

• [Flags]

  Flags is a comma-separated list of the following flags:

  • I (ignore case)

    Indicates that characters are matched regardless of a case. This flag affects RewriteHeader directive and all corresponding RewriteCond directives.

  • F (Forbidden)

    Stops the rewriting process and sends 404 Not Found response (Not 403 Forbidden!. And this behaviour corresponds to the IIS 6 behaviour) to a client. Note that FormatString is useless in this case and could be set to any non-empty string.

  • L (last rule)

    Stop the rewriting process here and don't apply any more rewriting rules.

  • N (Next iteration)

    Forces rewriting engine to modify rule's target and restart rule checking from the beginning (all modifications are saved). Number of restarts is limited by the value specified in the RepeatLimit directive. If this number is exceeded N flag will be simply ignored.

  • NS (Next iteration of the same rule)

    Works like the N flag but restarts rules processing from the same rule (i.e. forces repeat of the rule application). Maximum number of single rule iterations is given by the RepeatLimit directive. But a number of single rule repeats does not count for the global number of repeats (i.e. repeats limit for a number of iterations caused by N flag is independent of a number of repeats caused by NS).

  • R (explicit redirect)

    Force server to send immediate response to client with redirect instruction, providing new URI as a new location. Redirect rule is always the last rule.

  • RP (permanent redirect)

    Almost the same as the [R] flag but issues 301 (moved permanently) HTTP status code instead of 302 (moved temporary).

  • U (Unmangle Log)

    Log the URL as it was originally requested and not as the URL was rewritten.

  • O (nOrmalize)

    Normalizes string before processing. Normalization includes removing of an URL-encoding, illegal characters, etc. Also, IIS normalization of an URI completely removes query string. So, normalization should not be used if query string is needed. This flag is useful with URLs and URL-encoded headers.

  • CL (Case Lower)

    Changes case of a format result to lower.

  • CU (Case Upper)

    Changes case of a format result to upper.

To remove header, format string pattern should generate an empty string. For example this rule will remove user agent information from the client request:

RewriteHeader User-Agent: .* $1

And this rule will add Old-URL header to the request, providing a Request-URL as a header value:

RewriteCond URL (.*) RewriteHeader Old-URL: ^$ $1

This last example will direct all WebDAV requests to the /webdav.asp script by changing request method:

RewriteCond METHOD OPTIONS RewriteRule (.*) /webdav.asp?$1 RewriteHeader METHOD OPTIONS GET

 

RewriteProxy directive

Syntax: RewriteProxy Pattern FormatString [Flags]

Forces the result URI to be internally forced as a proxy request and immediately (i.e., rewriting rule processing stops here) put through the ISAPI extension that handles proxy requests. This allows IIS to act as a proxy server and reroute requests to other sites and servers.

• Pattern

  Specifies regular expression that will be matched against Request-URI. See regular expression syntax section for more information.

• FormatString

  Specifies format string that will generate new URI. See format string syntax section for more information. For this directive FormatString should generate a valid URL (including protocol, host, etc.) or ISAPI_Rewrite proxy module will return an error.

• [Flags]

  Flags is a comma-separated list of the following flags:

  • D (Delegate security)

    Proxy module will try to login on the remote server with the credentials of currently impersonated user. In case of built-in IIS authentication it will be credentials of the user that sends original request. Read the following chapter for details.

  • C (use Credentials)

    Proxy module will try to login on a remote server with the credentials specified in the URL or basic authentication headers. With this flag you can use http://user:password@host.com/path/ syntax for the URLs. Read the following chapter for details.

  • F (Follow redirects)

    By default ISAPI_Rewrite will try to map redirect instructions (301, 302, etc.) returned by a remote server into the local server namespace. If remote server returns a redirect pointing to the location somewhere on that server, ISAPI_Rewrite will modify this redirect instruction to point to the local server name. This will hide the real (internal) server name from a user.

    F flag could be used to force the proxy module to internally follow redirect instructions returned from a remote server. Use this flag if you don't need to receive redirects from remote server at all. Use this flag cautiously. It could break some server applications. For example, .NET WinForms authentication sets client cookie during a redirect. If proxy will be instructed to handle this redirect cookie will be lost and user will never be authenticated.

  • I (ignore case)

    Indicates that characters are matched regardless of a case. This flag affects RewriteProxy directive and all corresponding RewriteCond directives.

  • U (Unmangle Log)

    Log the URL as it was originally requested and not as the URL was rewritten.

  • O (nOrmalize)

    Normalizes string before processing. Normalization includes removing of an URL-encoding, illegal characters, etc. Also, IIS normalization of an URI completely removes query string. So, normalization should not be used if query string is needed. This flag is useful with URLs and URL-encoded headers.

  • H (preserve Host)

    Proxy module will use current Host header for a request to a remote server. Without this flag proxy will compose Host header from a host name and a port of a remote server.

  • A (Add authentication headers)

    Allows passing of an authentication information from proxy to an internal server when client authentication against a proxy server is used. Proxy module will append headers

    X-ISRW-Proxy-AUTH-TYPE, X-ISRW-Proxy-AUTH-USER, X-ISRW-Proxy-LOGON-USER, X-ISRW-Proxy-REMOTE-USER

    corresponding to server variables

    AUTH_TYPE, AUTH_USER, LOGON_USER, REMOTE_USER

    to a request sent to a proxied server.

Authentication schemes available for proxy.

IIS architecture and proxy module implementation imposes definite restrictions on authentication schemes that could be used with the proxy. Available schemes are described below:

• Anonymous - Anonymous - no authentication both between a client and a proxy and between a proxy and a remote server. Both servers (proxy and remote) should be configured to allow anonymous authentication. Neither C nor D proxy options should be specified.
• Anonymous - Basic - no authentication between a client and a proxy. But a remote server requires basic authentication. Two possibilities exist there:
  • User authenticates directly against a remote server. Proxy server should be configured for anonymous authentication ONLY. Having any other authentication enabled will cause authentication failure. Remote server should allow basic authentication. Neither C nor D proxy options should be specified.
  • User does not authenticate against a remote server. But a proxy authenticates against a remote server with explicit credentials. Login credentials should be explicitly specified in a proxied URL. C flag should be specified, D flag should not be set.
• Anonymous - Windows Integrated - user does not authenticate against a remote server. But a proxy authenticates against a remote server with a credentials of IIS worker process. IIS worker process on the proxy server should run under an account whose credentials will be used for authentication. Account should have network access. Remote server should allow Windows Integrated Authentication. C flag should not be specified. D flag should be specified if a remote server is not in an intranet.
• Basic - Basic - user authenticates against a proxy server and proxy server authenticates against a remote server with user's credentials. Both servers should allow basic authentication. C flag should be specified. D flag should not be specified.
• Basic - Windows Integrated - user authenticates against a proxy server and proxy server authenticates against a remote server with user's credentials. Proxy server should allow basic authentication. Remote server should allow Integrated authentication. Either C or D flag should be specified (C is recommended).
• NTLM - NTLM - user authenticates against a proxy application on a server and proxy application authenticates against another application on the same server (there is no way to delegate NTLM authentication to another server). C flag should not be specified. D flag should be specified.
• Kerberos - Kerberos - user authenticates against proxy server and proxy server in turn authenticates against remote server using user-supplied credentials. To implement this configuration the following requirements have to be satisfied:
  1. Client computer, Proxy server and Proxied server should belong to the same Active directory domain or trusted AD domains (This requirement makes this scheme almost useless for internet applications. Although MS Article Kerberos Interoperability points to a possibility of configuring Kerberos authentication for a non-domain-member client computer, configuration steps needed for that seem to be too complex for an internet applications).
  2. Probably you will have to change Application Pool identity for the proxy web application to a domain user (You could read article Configuring a Worker Process Identity Using a Configurable Account (IIS 6.0) to understand steps required to create a custom account). Although it looks like Network Service identity should work according to the MSDN articles, we were unable to make Kerberos working between a proxy and a proxied server with this identity. If you will set a custom identity, you will need to configure SPNs for it. SPNs configuration is described in the MS KB Article 871179.
  3. Application pool account should be marked as "Trusted for delegation". Otherwise, if the Local System account is used as an Application pool identity, proxy server should be marked as "Trusted for delegation". At the same time client account should not be marked as "Sensitive to delegation". Detailed information on accounts configuration could be found in the article How To: Implement Kerberos Delegation for Windows 2000.
  4. If you are going to access proxy server by name, which is different from its NetBIOS and AD domain names, you will have to register SPN for that name. You could read how to configure additional SPNs in the article HOW TO: Troubleshoot Kerberos-Related Issues in IIS
  5. C flag should not be specified in the ISAPI_Rewrite rule. D flag should be specified.
  If you have problems with this configuration, please, read HOW TO: Troubleshoot Kerberos-Related Issues in IIS article before contacting support.
• NTLM - Kerberos - user authenticates against a proxy server with NTLM authentication and proxy server in turn authenticates against remote server with Kerberos. This scheme has almost the same requirements as Kerberos - Kerberos scheme. However, it allows any internet client capable to perform NTLM authentication to access internal server through a proxy. This scheme could be implemented only in the AD domain running in the Windows 2003 native mode. And Application pool account should be configured to allow delegation of all authentication protocols to http service on the proxied server.

 

CacheClockRate directive

Syntax: CacheClockRate Interval

This directive can appear only in global configuration context. If this directive is found in a site-level context it will be ignored and an error message will be written to the httpd.parse.errors file.

ISAPI_Rewrite caches every configuration file at first time it is loaded. Using this directive you can specify period of inactivity of particular site when its configuration will be purged from cache. By setting this parameter big enough you can force ISAPI_Rewrite to never recycle its cache. Remember that any changes to configuration files update cache immediately after the next request regardless of this interval.

• Interval

  Specifies time of inactivity (in seconds) when particular configuration will be purged from cache. The default value is 3600 (1 hour).

EnableConfig and DisableConfig directives

Syntax: EnableConfig [SiteID|"Site name"] DisableConfig [SiteID|"Site name"]

Enables or disables site-level configurations for a selected site or changes the defaults. By default site-level configurations are enabled. This directive can appear only in global configuration context. If found in a site-level context it will be ignored and an error message will be written to the httpd.parse.errors file.

• SiteID

  Numeric metabase identifier of a site

• Site name

  Name of the site as it appears in the IIS console.

If used without parameter this directives turn default settings to enable/disable configuration processing.

Example:

The following will enable configuration only for the site with ID=1 (typically it is Default Web Site) and a site named "My site":

DisableConfig EnableConfig 1 EnableConfig "My site"

In the following example configurations are enabled for the site named "Some site" because explicit settings override the default settings.

EnableConfig "Some site" DisableConfig

EnableRewrite and DisableRewrite directives

Syntax: EnableRewrite [SiteID|"Site name"] DisableRewrite [SiteID|"Site name"]

Enables or disables rewriting for a selected site or changes the defaults. By default rewriting is enabled. This directive can appear only in global configuration context. If found in a site-level context it will be ignored and an error message will be written to the httpd.parse.errors file.

• SiteID

  Numeric metabase identifier of a site

• Site name

  Name of the site as it appears in the IIS console.

If used without parameter this directives enable or disable rewriting at all.

RepeatLimit directive

Syntax: RepeatLimit Limit

This directive could appear both in global and in site-level configuration files. If it will appear in the global configuration file it will change the global limit for all sites. If this directive will appear in a site-level configuration file it will change a limit for this site only and this limit could not exceed the global limit.

ISAPI_Rewrite allows loops while processing rules (see the description of the N flag of the RewriteRule and RewriteHeader directives). This directive allows limiting the maximum number of possible loops. It could be set to zero or one to disable looping.

• Limit

  Specifies a maximum number of allowed loops. The default value is 32.

RFStyle directive

Syntax: RFStyle  Old | New

The RFStyle directive allows control over redirect and forbidden responses style in a Full version of ISAPI_Rewrite. The default Old style is to issue those responses directly from the filter. This method is fast and requires no additional configuration. But in this case original requests could not be logged by IIS. New style forces filter to issue redirect and forbidden responses through a proxy module. This technique makes possible to log redirected and forbidden requests. But this method would require manual configuration in many cases. Details of the proxy module configuration could be found in the following chapter.

Configuration Utility

ISAPI_Rewrite Full includes configuration utility (which could be launched from the ISAPI_Rewrite program group). It allows you to view trial status and enter a registration code (if the product was not registered during the installation) and modify some product options related to the proxy module operation. Utility is organized as a property sheet with three property pages:

• Trial page.

  This page will be shown only if you have installed ISAPI_Rewrite in a trial mode. It allows you to view product's trial status and to enter a registration code.

• Settings page.

  This page contains edit boxes and checkboxes for the following parameters:

  • Helper URL

    This parameter affects a way of communication between the filter and the proxy module. This could be either a file extension prefixed with a dot (like .isrwhlp) or an absolute URI (like /isrwhlp/rwhelper.dll).

    In the first case that extension will be appended to the original request URI and proxy module will be invoked via a script map. The default extension ".isrwhlp" is added to the global script map during the installation process. If you have changed this extension or if your application does not inherit global script map settings you should manually add a required entry to the script map. It should have the following parameters:

    Executable:	An absolute path to the rwhelper.dll in the short form
    Extension:	Desired extension (.isrwhlp is default)
    Verbs radio button:	All Verbs
    Script engine checkbox:	Checked
    Check that file exists checkbox:	Unchecked

    We have created a WSH script proxycfg.vbs which could simplify helper extension registration in a script maps. It's located in the ISAPI_Rewrite installation folder and could be run from command line in this way:

    cscript proxycfg.vbs [-r] [MetabasePath]

    • Optional -r parameter forces script to register extension in the metabase recursively.
    • Optional MetabasePath parameter allows specification of the first metabase key to process. By default it is "/localhost/W3SVC".

     

    To register extension in all existing script maps you could invoke script with the following command string:
    

    cscript proxycfg.vbs -r

    In the second case (absolute URI) you should provide an URI like /vfolder/rwhelper.dll for a value of the 'Helper URL'. You should also map an ISAPI_Rewrite's installation folder as a chosen virtual folder (/vfolder) to an each site which would use proxying and enable executables launching for these virtual folders.

    Note: As it was reported by our customers, IIS 5 (and may be IIS 4) has a problem with a long directory names in the Helper URL. So, it is strongly recommended to use short directory names.

    Both methods have advantages and drawbacks. The second one allows you to isolate proxy application from other applications but this method could fail under IIS6. The first one should work fine under IIS6 but the proxy module will be invoked in a context of an application targeted by an original request URL.

  • Worker threads limit

    This parameter limits maximum number of the worker threads in the proxy extension threads pool. Default value 0 means that this limit will be equal to the number of processors multiplied by 2.

  • Active threads limit

    This parameter limits maximum number of the concurrently running worker threads. This value could not be greater than "Worker threads limit". Default value 0 means that this limit will be equal to the number of processors.

  • Queue size

    This parameter defines the maximum number of request which could be queued for processing by the single instance of the proxy module. You could increase this parameter if you will ever see "Queue timeout expired" message in the Application event log.

  • Queue timeout

    This parameter defines the maximum wait time for placing new request into the internal request queue. It becomes actual when the number of queued request reaches its maximum defined by the "Queue size" parameter. You could increase this parameter if you will ever see "Queue timeout expired" message in the Application event log.

  • Connect timeout

    Specifies connect timeout for the proxy module in milliseconds. Default value is 60000 (60 sec).

  • Send timeout

    Specifies send timeout for the proxy module in milliseconds. Default value is 30000 (30 sec).

  • Receive timeout

    Specifies receive timeout for the proxy module in milliseconds. Default value is 30000 (30 sec).

  • Suppress error details

    Specifies that proxy module should not send detailed error message to a client. Default value is true.

• About page.

  It contains copyright information and a link to the ISAPI_Rewrite's web site.

 

Regular expression syntax

This section gives the brief description of the regular expression syntax used by ISAPI_Rewrite. Complete description of the syntax could be found in the Boost.Regex documentation.

Literals

All characters are literals except: ".", "*", "?", "+", "(", ")", "{", "}", "[", "]", "^" and "$". These characters are literals when preceded by a "/". A literal is a character that matches itself.

Wildcard

The dot character "." matches any single character except null character and newline character. 

Repeats

A repeat is an expression that is repeated an arbitrary number of times. An expression followed by "*" can be repeated any number of times including zero. An expression followed by "+" can be repeated any number of times, but at least once. An expression followed by "?" may be repeated zero or one times only. When it is necessary to specify the minimum and maximum number of repeats explicitly, the bounds operator "{}" may be used, thus "a{2}" is the letter "a" repeated exactly twice, "a{2,4}" represents the letter "a" repeated between 2 and 4 times, and "a{2,}" represents the letter "a" repeated at least twice with no upper limit. Note that there must be no white-space inside the {}, and there is no upper limit on the values of the lower and upper bounds. All repeat expressions refer to the shortest possible previous sub-expression: a single character; a character set, or a sub-expression grouped with "()" for example.

Examples:

• "ba*" will match all of "b", "ba", "baaa" etc.
• "ba+" will match "ba" or "baaaa" for example but not "b".
• "ba?" will match "b" or "ba".
• "ba{2,4}" will match "baa", "baaa" and "baaaa".

Non-greedy repeats

Non-greedy repeats are possible by appending a '?' after the repeat; a non-greedy repeat is one which will match the shortest possible string.

For example to match html tag pairs one could use something like:

"</s*tagname[^>]*>(.*?)</s*/tagname/s*>"

In this case $1 will contain the text between the tag pairs, and will be the shortest possible matching string. 

Parenthesis

Parentheses serve two purposes, to group items together into a sub-expression, and to mark what generated the match. For example the expression "(ab)*" would match all of the string "ababab". All sub matches marked by parenthesis can be back referenced using /N or $N syntax. It is permissible for sub-expressions to match null strings. Sub-expressions are indexed from left to right starting from 1, sub-expression 0 is the whole expression.

Non-Marking Parenthesis

Sometimes you need to group sub-expressions with parenthesis, but don't want the parenthesis to spit out another marked sub-expression, in this case a non-marking parenthesis (?:expression) can be used. For example the following expression creates no sub-expressions:

"(?:abc)*" 

Alternatives

Alternatives occur when the expression can match either one sub-expression or another, each alternative is separated by a "|". Each alternative is the largest possible previous sub-expression; this is the opposite behavior from repetition operators.

Examples:

• "a(b|c)" could match "ab" or "ac".
• "abc|def" could match "abc" or "def". 

Sets

A set is a set of characters that can match any single character that is a member of the set. Sets are delimited by "[" and "]" and can contain literals, character ranges, character classes, collating elements and equivalence classes. Set declarations that start with "^" contain the compliment of the elements that follow.

Examples:

Character literals:

• "[abc]" will match either of "a", "b", or "c".
• "[^abc] will match any character other than "a", "b", or "c".

Character ranges:

• "[a-z]" will match any character in the range "a" to "z".
• "[^A-Z]" will match any character other than those in the range "A" to "Z".

Character classes

Character classes are denoted using the syntax "[:classname:]" within a set declaration, for example "[[:space:]]" is the set of all whitespace characters. The available character classes are: 

alnum	Any alpha numeric character.
alpha	Any alphabetical character a-z and A-Z. Other characters may also be included depending upon the locale.
blank	Any blank character, either a space or a tab.
cntrl	Any control character.
digit	Any digit 0-9.
graph	Any graphical character.
lower	Any lower case character a-z. Other characters may also be included depending upon the locale.
print	Any printable character.
punct	Any punctuation character.
space	Any whitespace character.
upper	Any upper case character A-Z. Other characters may also be included depending upon the locale.
xdigit	Any hexadecimal digit character, 0-9, a-f and A-F.
word	Any word character - all alphanumeric characters plus the underscore.
unicode	Any character whose code is greater than 255, this applies to the wide character traits classes only.

There are some shortcuts that can be used in place of the character classes:

• /w in place of [:word:]
• /s in place of [:space:]
• /d in place of [:digit:]
• /l in place of [:lower:]
• /u in place of [:upper:] 

Collating elements

Collating elements take the general form [.tagname.] inside a set declaration, where tagname is either a single character, or a name of a collating element, for example [[.a.]] is equivalent to [a], and [[.comma.]] is equivalent to [,]. ISAPI_Rewrite supports all the standard POSIX collating element names, and in addition the following digraphs: "ae", "ch", "ll", "ss", "nj", "dz", "lj", each in lower, upper and title case variations. Multi-character collating elements can result in the set matching more than one character, for example [[.ae.]] would match two characters, but note that [^[.ae.]] would only match one character. 

Equivalence classes

Equivalence classes take the general form [=tagname=] inside a set declaration, where tagname is either a single character, or a name of a collating element, and matches any character that is a member of the same primary equivalence class as the collating element [.tagname.]. An equivalence class is a set of characters that collate the same, a primary equivalence class is a set of characters whose primary sort key are all the same (for example strings are typically collated by character, then by accent, and then by case; the primary sort key then relates to the character, the secondary to the accentation, and the tertiary to the case). If there is no equivalence class corresponding to tagname, then [=tagname=] is exactly the same as [.tagname.].

To include a literal "-" in a set declaration then: make it the first character after the opening "[" or "[^", the endpoint of a range, a collating element, or precede it with an escape character as in "[/-]". To include a literal "[" or "]" or "^" in a set then make them the endpoint of a range, a collating element, or precede with an escape character. 

Line anchors

An anchor is something that matches the null string at the start or end of a line: "^" matches the null string at the start of a line, "$" matches the null string at the end of a line. 

Back references

A back reference is a reference to a previous sub-expression that has already been matched, the reference is to what the sub-expression matched, not to the expression itself. A back reference consists of the escape character "/" followed by a digit "1" to "9", "/1" refers to the first sub-expression, "/2" to the second etc. For example the expression "(.*)/1" matches any string that is repeated about its mid-point for example "abcabc" or "xyzxyz". A back reference to a sub-expression that did not participate in any match, matches the null string. In ISAPI_Rewrite all back references are global for entire RewriteRule and corresponding RewriteCond directives. Sub matches are numbered up to down and left to right beginning from the first RewriteCond directive of the corresponding RewriteRule directive, if there is one.

Forward Lookahead Asserts

There are two forms of these; one for positive forward lookahead asserts, and one for negative lookahead asserts:

• "(?=abc)" matches zero characters only if they are followed by the expression "abc".
• "(?!abc)" matches zero characters only if they are not followed by the expression "abc".

 

Word operators

The following operators are provided for compatibility with the GNU regular expression library.

• "/w" matches any single character that is a member of the "word" character class, this is identical to the expression "[[:word:]]".
• "/W" matches any single character that is not a member of the "word" character class, this is identical to the expression "[^[:word:]]".
• "/<" matches the null string at the start of a word.
• "/>" matches the null string at the end of the word.
• "/b" matches the null string at either the start or the end of a word.
• "/B" matches a null string within a word.

Escape operator

The escape character "/" has several meanings.

• The escape operator may introduce an operator for example: back references, or a word operator.
• The escape operator may make the following character normal, for example "/*" represents a literal "*" rather than the repeat operator.

Single character escape sequences:

The following escape sequences are aliases for single characters:
 

Escape sequence	Character code	Meaning
/a	0x07	Bell character.
/t	0x09	Tab character.
/v	0x0B	Vertical tab.
/e	0x1B	ASCII Escape character.
/0dd	0dd	An octal character code, where dd is one or more octal digits.
/xXX	0xXX	A hexadecimal character code, where XX is one or more hexadecimal digits.
/x{XX}	0xXX	A hexadecimal character code, where XX is one or more hexadecimal digits, optionally a unicode character.
/cZ	z-@	An ASCII escape sequence control-Z, where Z is any ASCII character greater than or equal to the character code for '@'.

 

Miscellaneous escape sequences:

The following are provided mostly for perl compatibility, but note that there are some differences in the meanings of /l /L /u and /U: 

Escape sequence	Meaning
/w	Equivalent to [[:word:]].
/W	Equivalent to [^[:word:]].
/s	Equivalent to [[:space:]].
/S	Equivalent to [^[:space:]].
/d	Equivalent to [[:digit:]].
/D	Equivalent to [^[:digit:]].
/l	Equivalent to [[:lower:]].
/L	Equivalent to [^[:lower:]].
/u	Equivalent to [[:upper:]].
/U	Equivalent to [^[:upper:]].
/C	Any single character, equivalent to '.'.
/X	Match any Unicode combining character sequence, for example "a/x 0301" (a letter a with an acute).
/Q	The begin quote operator, everything that follows is treated as a literal character until a /E end quote operator is found.
/E	The end quote operator, terminates a sequence begun with /Q.

 

What gets matched?

The regular expression will match the first possible matching string, if more than one string starting at a given location can match then it matches the longest possible string. In cases where their are multiple possible matches all starting at the same location, and all of the same length, then the match chosen is the one with the longest first sub-expression, if that is the same for two or more matches, then the second sub-expression will be examined and so on. Note that ISAPI_Rewrite uses MATCH algorithm. The result is matched only if the expression matches the whole input sequence. For example:

• RewriteCond URL ^/somedir/.* #will match any request to somedir directory and subdirectories, while
• RewriteCond URL ^/somedir/ #will match only request to the root of the somedir.

Special note about "pathological" regular expressions

ISAPI_Rewrite uses a very powerful regular expressions engine Regex++ from Boost library. However it has some limitations: There exists some "pathological" expressions which may require exponential time for matching; these all involve nested repetition operators, for example attempting to match the expression "(a*a)*b" against N letter a's requires time proportional to 2^N. These expressions can (almost) always be rewritten in such a way as to avoid the problem, for example "(a*a)*b" could be rewritten as "a*b" which requires only time linearly proportional to N to solve. In the general case, non-nested repeat expressions require time proportional to N², however if the clauses are mutually exclusive then they can be matched in linear time - this is the case with "a*b", for each character the matcher will either match an "a" or a "b" or fail, where as with "a*a" the matcher can't tell which branch to take (the first "a" or the second) and so has to try both.

Regex++ can detect such "pathological" regular expressions and terminate theirs matching. This will cause ISAPI_Rewrite's rule to fail. When a rule fails ISAPI_Rewrite sends "500 Internal Server error - Rule Failed" status to a client to indicate configuration error.

Format string syntax

In format strings, all characters are treated as literals except: "(", ")", "$", "/", "?", ":".

To use any of these as literals you must prefix them with the escape character /

The following special sequences are recognized: 

Grouping:

Use the parenthesis characters ( and ) to group sub-expressions within the format string, use /( and /) to represent literal '(' and ')'. 

Sub-expression expansions:

The following perl like expressions expand to a particular matched sub-expression:

$`	Expands to all the text from the end of the previous match to the start of the current match, if there was no previous match in the current operation, then everything from the start of the input string to the start of the match.
$'	Expands to all the text from the end of the match to the end of the input string.
$&	Expands to all of the current match.
$0	Expands to all of the current match.
$N	Expands to the text that matched sub-expression N.

 

Conditional expressions:

Conditional expressions allow two different format strings to be selected dependent upon whether a sub-expression participated in the match or not:

?Ntrue_expression:false_expression

Executes true_expression if sub-expression N participated in the match, otherwise executes false_expression.

Example: suppose we search for "(while)|(for)" then the format string "?1WHILE:FOR" would output what matched, but in upper case.

Escape sequences:

The following escape sequences are also allowed:
 

/a	The bell character.
/f	The form feed character.
/n	The newline character.
/r	The carriage return character.
/t	The tab character.
/v	A vertical tab character.
/x	A hexadecimal character - for example /x0D.
/x{}	A possible unicode hexadecimal character - for example /x{1A0}
/cx	The ASCII escape character x, for example /c@ is equivalent to escape-@.
/e	The ASCII escape character.
/dd	An octal character constant, for example /10.

Examples

Emulating host-header-based virtual sites on a single site

For example you have registered two domains www.site1.com and www.site2.com.  Now you can create two different sites using single physical site. Add the following rules to your httpd.ini file:

[ISAPI_Rewrite] #Fix missing slash char on folders RewriteCond Host: (.*) RewriteRule ([^.?]+[^.?/]) http/://$1$2/ [I,R] #Emulate site1 RewriteCond Host: (?:www/.)?site1/.com RewriteRule (.*) /site1$1 [I,L] #Emulate site2 RewriteCond Host: (?:www/.)?site2/.com RewriteRule (.*) /site2$1 [I,L]

Now just place your sites in /site1 and /site2 directories.

Or you can use more generic rules:

[ISAPI_Rewrite] #Fix missing slash char on folders RewriteCond Host: (.*) RewriteRule ([^.?]+[^.?/]) http/://$1$2/ [I,R] RewriteCond Host: (www/.)?(.+) RewriteRule (.*) /$2$3

The directory names for sites should be like /somesite1.com, /somesite2.info, etc.

Using different namespaces on development and live servers

Suppose you are developing rules for a website that will be deployed to a /livesite/ folder on a live server. However, on a development machine you need to store files in the /develop/ folder. In this case you could use UriMatchPrefix and UriFormatPrefix directives to minimize a number of changes those will be needed for a namespace change:

[ISAPI_Rewrite] #specify namespaces with UriMatchPrefix and UriFormatPrefix UriMatchPrefix /develop UriFormatPrefix /develop #rules are going here #really we are checking for /develop/sampleN.htm and formatting to /develop/sampleN.asp RewriteRule /sample1.htm /sample1.asp [I,L] RewriteRule /sample2.htm /sample2.asp [I,L] RewriteRule /sample3.htm /sample3.asp [I,L] #reset namespaces to default UriMatchPrefix UriFormatPrefix

The only things you will need to change before a deployment to a live server are values of UriMatchPrefix and UriFormatPrefix.

Using loops (Next flag) to convert request parameters

Suppose you wish to access physical URLs like http://www.myhost.com/foo.asp?a=A&b=B&c=C using requests like http://www.myhost.com/foo.asp/a/A/b/B/c/C and the number of parameters may vary from one request to another.

There exist at least two possible solutions. You could simply add a separate rule for each possible number of parameters or you could use a technique demonstrated by the following example.

[ISAPI_Rewrite] RewriteRule (.*?/.asp)(/?[^/]*)?/([^/]*)/([^/]*)(.*) $1(?2$2&:/?)$3=$4$5 [NS,I]

Note that this rule may break page-relative links to CSSs, images, etc. This is due to a change in the base path (parent folder of the page) that is being used by a browser to calculate complete resource URI. There are three possible solutions:

 

This rule will extract one parameter from request URL, append it to the end of the request string and restart rules processing from the beginning. So it will loop until all parameters will be moved to the right place (or until the RepeatLimit will be exceeded).

There also exist many variations of this rule with different separator characters. For example, to use URLs like http://www.myhost.com/foo.asp~a~A~b~B~c~C the following rule could be implemented:

[ISAPI_Rewrite] RewriteRule (.*?/.asp)(/?[^~]*)?~([^~]*)~([^~]*)(.*) $1(?2$2&:/?)$3=$4$5 [NS,I]

Running servers behind IIS

Assume we have internet server running IIS and several corporate servers running other platform. These servers are not directly accessible from the internet but only from our corporate network. Here is a simple example how to map another server into the IIS site’s namespace using proxy flag:

[ISAPI_Rewrite] RewriteProxy /mappoint(.+) http/://sitedomain$1 [I,U]

Moving sites from UNIX to IIS

This rules can help change the URL from /~username to /username and /file.html to /file.htm. It can be useful if you just moved your site from UNIX to IIS and keep getting hits to the old pages from search engines and other external pages.

[ISAPI_Rewrite] #redirecting to update old links RewriteRule (.*)/.html $1.htm RewriteRule /~(.*) http/://myserver/$1 [R]

Moving site location

Many webmasters asked for a solution to the following problem: They want to redirect all requests to one web server to another web server. Such problems usually arise when you need to establish a newer web server which will replace the old one over time. The solution is to use ISAPI_Rewrite on the old web server:

[ISAPI_Rewrite] #redirecting to update old links RewriteRule (.+) http/://newwebserver$1 [R]

Browser-dependent content

It is sometimes necessary to provide browser-dependent content at least for important top-level pages, i.e. one has to provide a full-featured version for the Internet Explorer, a minimum-featured version for the Lynx browsers and an average-featured version for all others.

We have to act on the HTTP header "User-Agent". The sample code does the following: If the HTTP header "User-Agent" contains "MSIE", the target foo.htm is rewritten to foo.IE.htm. If the browser is "Lynx" or "Mozilla" of version 1 or 2 the URL becomes foo.20.htm. Other browsers receive page foo.32.html. All this is done by the following ruleset:

[ISAPI_Rewrite] RewriteCond User-Agent: .*MSIE.* RewriteRule /foo/.htm /foo.IE.htm [L] RewriteCond User-Agent: (?:Lynx|Mozilla/[12]).* RewriteRule /foo/.htm /foo.20.htm [L] RewriteRule /foo/.htm /foo.32.htm [L]

Dynamically generated robots.txt

robots.txt is a file that search engines use to discover URLs that should or should not be indexed. But creation of this file for large sites with lot of dynamic content is a very complex task. Have you ever dreamed about dynamically generated robots.txt? Let's write robots.asp script:

<%@ Language=JScript EnableSessionState=False%> <% //The script must return plain text Response.ContentType="text/plain"; /* Place generation code here */ %>

Now make it robots.txt using single rule:

[ISAPI_Rewrite] RewriteRule /robots/.txt /robots.asp

Making search engines to index dynamic pages

Content of the site stored in XML files. There is /XMLProcess.asp file that processes XML files on server and returns HTML to end user. URLs to the documents have a form of:
http://www.mysite.com/XMLProcess.asp?xml=/somdir/somedoc.xml
But many popular search engines will not index such documents because URLs contain question mark (document is dynamically generated). ISAPI_Rewrite can competely eliminate this problem.

[ISAPI_Rewrite] RewriteRule /doc(.*)/.htm /XMLProcess.asp/?xml=$1.xml

Now to access documents use URL like http://www.mysite.com/doc/somedir/somedoc.htm. Search engines will never know that physically there is no somedoc.htm file and content is dynamically generated.

Negative expressions (NOT)

Sometimes you need to apply rule when some pattern not matches. In this case you may use so called Forward Lookahead Asserts in regular expressions.

For example you need to move all users not using Internet Explorer to the other location:

[ISAPI_Rewrite] # Redirect all non Internet Explorer users # to another location RewriteCond User-Agent: (?!.*MSIE).* RewriteRule (.*) /nonie$1

Dynamic authentication

For example we have some members area on the site and we need password-protect files in this area but we don't like to use built-in server security. In this case it is possible to create ASP script (call it proxy.asp) that will proxy all requests to the members area and check for required permissions. Here is a simple template for this page where you can put your own authorization code:

<%@ Language=JScript EnableSessionState=False%> <% function Authorize() { //Check if the user is authorized to view a resource here //Return true if user has a required permission, otherwise return false return true; } if(!Authorize()) { //Redirect to the login page Response.Redirect("http://mysite.com/LoginPage.asp?ref="+Request.QueryString.Item); Response.End() } var WinHttpReq = new ActiveXObject("WinHttp.WinHttpRequest.5"); WinHttpReq.Open(Request.ServerVariables("REQUEST_METHOD").Item, Request.QueryString.Item, true); var headers=String(Request.ServerVariables("ALL_RAW")).split("/n"); for(i=0; i<headers.length && headers[i]; i++) { header = headers[i].match(/([/w-/.]+):/s*([ /S]*)/); if(header) WinHttpReq.SetRequestHeader(header[1],header[2]); } if(lngCount = Request.TotalBytes) { var data=Request.BinaryRead(lngCount); WinHttpReq.Send(data); } else { WinHttpReq.Send(); } if(!WinHttpReq.WaitForResponse(15)) { WinHttpReq.Abort(); Response.Status="408 Request Timeout"; } else { Response.Status = "" + WinHttpReq.Status + " " + WinHttpReq.StatusText; headers=String(WinHttpReq.GetAllResponseHeaders()).split("/n"); for(i=0; i<headers.length && headers[i]; i++) { header = headers[i].match(/([/w-/.]+):/s*([ /S]*)/); if(header) Response.AddHeader(header[1],header[2]); } Response.Write(WinHttpReq.ResponseText); } %>

Now we need to configure ISAPI_Rewrite to proxy requests through this page:

[ISAPI_Rewrite] # Proxy all requests through proxy.asp RewriteRule /members(.+) /proxy.asp/?http/://mysite.com/members$1

Blocking inline-images (stop hot linking)

Assume we have some pages with inlined GIF graphics under http://www.mysite.com/. These graphics are nice, so others directly incorporate them via hyperlinks to their pages. We don't like this practice because it adds useless traffic to our server.

While we cannot 100% protect the images from inclusion, we can at least restrict the cases where the browser sends a HTTP Referer header.

[ISAPI_Rewrite] RewriteCond Host: (.+) RewriteCond Referer: (?!http:///1.*).* RewriteRule .*/.(?:gif|jpg|png) /block.gif [I,O]

Regular Expressions Testing Tool

RXTest utility could be used to simulate rule execution. The following examples demonstrate its usage.

1. A simple rule:
   

   RewriteRule (.+) http/://newwebserver$1 [I,R]

   Regular expression textbox will correspond to the pattern part of the rule. Here it will be:
   

   (.+)

   
   Format string textbox will correspond to the format part of the rule. In this case it will be:

   http/://newwebserver$1

   
   Ignore case checkbox will correspond to the I flag of the rule. So, it shall be checked.
   Something like /test could be taken as the Test string. Then you will get http://newwebserver/test as the Format Result.

    

2. A rule with a condition:
   

   RewriteCond Host: (?!www/.)(.+) RewriteRule (.+) http/://www.$1$2 [I,RP]

   To combine two regular expressions into a single one some separator character that will not occur in a real URI could be used. For example, it could be !. Then Regular expression will be:

   (?!www/.)(.+)!(.+)

   
   Format string textbox will be:

   http/://www.$1$2

   
   Ignore case checkbox will be checked.
   If www.host.com!/anything will be taken as the Test string result will be Not matched. But host.com!/anything will produce http://www.host.com/anything.

    

3. A rule with iterations:
   

   RewriteRule (.*?/.asp)(/?[^/]*)?/([^/]*)/([^/]*)(.*) $1(?2$2&:/?)$3=$4$5 [NS,I]

   Such rule (having N or NS flag) could not be simulated in the Regular Expressions Test Tool as a whole. However it could be simulated step by step. Initially rule could be splitted into a pattern and format as in the previous samples. Then on the first step some test string could be provided that will result in some format result. This format result should be taken as a test string on the second step, etc.

 

 

1. Use the rule given below. It does not affect base path.
2. Directly specify correct base path for a page with the help of <base href="/folder/page.asp"> tag.
3. Change all page-relative links to either root-relative or absolute form.

 

• Web Management Tools/IIS 6 Management Compatibility/IIS6 WMI compatibility
• Web Management Tools/IIS 6 Management Compatibility/IIS metabase and IIS6 configuration compatibility
• World Wide Web Services/Application Development Features/ISAPI Filters
• Full version only: World Wide Web Services/Application Development Features/ISAPI Extensions