Content Rules

1 Introduction

The KEMP LoadMaster supports content switching, which is sometimes referred to as URL switching. This allows the LoadMaster to direct specific requests to specific Real Servers based on the contents of the requested URL.

For example, if there are two groups of servers - one to serve images and the other to serve all other content - rules can be created to separate these two types of request. Any URL that includes /images in it, for example http://example.com/images/demo.jpg, would get directed to the image server(s). Anything else gets directed to the other server(s).

Content switching allows the KEMP LoadMaster to break up traffic based on the content of the request. Traffic can be examined by the:

Request URL

HTTP Header

Source IP address

Body of a request

Content rules only apply to HTTP or HTTPS traffic.

The maximum number of content rules that a LoadMaster can have is 1024.

In this document, the term content switching does not refer to the process involved with Layer 2 switching. Instead, content switching refers to the switching of traffic between different servers, depending upon what content was requested. 

1.1 Document Purpose

This document describes various aspects of the Content Rules feature of the KEMP LoadMaster.  It describes in detail how to configure the Content Rules feature using the LoadMaster Web User Interface (WUI).

1.2 Intended Audience

This document is intended to help anyone who wishes to learn about or implement Content Rules within the KEMP LoadMaster.

2 Advantages of Content Rules

035.png

Content switching can be very useful if there are dedicated server types that perform different functions such as image servers, static content servers, mapping servers, specialized content servers, application servers and media servers, that all need to be served from the same general hostname, for example www.mysite.com. Content switching also allows for hostname-specific servers and source IP-specific servers.

Content rules give the ability to:

Strip out server information

Redirect requests for the root of a server

Rewrite redirections from HTTP to HTTPS

Force connections to close

Secure cookies

036.png

The above diagram outlines the order that content rule operations are performed in.

3 Configure a Virtual Service to use Content Rules

There are two parts to configuring content switching:  the content rules, and the Virtual Service configuration.  The content rules are configured globally on the LoadMaster, and various rules are applied to specific Real Servers operating under a Virtual Service.

The sections below describe the steps required to configure a Virtual Service that makes use of content switching.

3.1 Setting up Content Rules

To set up a content rule, follow the steps below on the LoadMaster WUI:

1. In the main menu, select Rules & Checking and then Content Rules

There is a default (catch-all) rule, that matches everything. This rule is not editable and will always be the last one to match if Content Switching is enabled in a Virtual Service.

2. Click the Create New... button.

Setting up Content Rules.png

3. Fill out the form as needed. For details on what each of the options mean, refer to the Content Rules WUI Options section.

4. Click Create Rule.

 The rule will be added, but will not affect any Virtual Service.  Once the rules have been added, they need to be applied to Real Servers within individual Virtual Services.

To create a rule that will send all URL requests that have /images/ as the root path to a group of servers, the Match String value should be images/* (where images/* is an example of a regular expression).

It is possible to perform content switching on URL, HTTP Header, Source IP or the body of a request. The default behavior is to test the URL, however a Header Field may be specified instead. To use Source IP content switching, use the pseudo-header src-ip — the source IP of the client will then be available as a text field. The HTTP method can be matched upon by filling out the Header Field text box and the method. The body can be matched upon by entering body in the Header Field text box.

The Match String can be either a Shell Regular Expression or a Perl Compatible Regular Expression (PCRE) and can be 250 characters in length.

KEMP recommends using PCRE expressions instead of Shell.

3.2  Configuring Virtual Services

To configure a Virtual Service to use content switching, follow the steps below:

1. Log in to the relevant LoadMaster WUI.

2. In the main menu, select Virtual Services and View/Modify Services.

Configuring Virtual Services.png

3. Click Modify on the relevant Virtual Service.

4. Expand the Standard Options section.

Configuring Virtual Services_1.png

5. Select the relevant persistence mode in the Persistence Options drop-down menu.

6. Expand the Advanced Properties section.

Configuring Virtual Services_2.png

7. Click Enable in the Content Switching row.

The enable button will only be available if there is a Real Server set up on this Virtual Service.

If you exit the Virtual Service modify screen without adding a content rule to a Real Server you will need to re-enable Content Switching.

Configuring Virtual Services_3.png

8. Expand the Real Servers section.

 There will be a new column called Rules. Content switching has just been enabled, so no rules are active.

9. Click the None button.

10. Select the relevant rule in the drop-down list and click Add.

The maximum number of content rules that a LoadMaster can have is 1024. There is no limit on a per-Real Server basis regarding how many of these rules can be assigned.

The rule will be added to the Real Server. Multiple rules can be added to each Real Server.

3.3 Content Rules WUI Options

The various fields associated with Content Rules in the LoadMaster WUI are described below.

Content Rules WUI Options.png

The Content Rules screen displays the rules that have been configured and gives the option to Modify or Delete.

To define a new rule, click on Create New.

Content Rules WUI Options_1.png

The rule must be given a unique name. The Rule Name must be alphanumeric, unique and start with an alpha character. They are case sensitive, thus two different rules can exist in the form Rule1 and rule1. It is not possible to name a content rule default.

The options that are available depend on the Rule Type that is selected. The available rules are as follows:

Rule Types:

Content Matching: Matches the content of the header or body of a request

Add Header: Adds a header according to the rule

Del Header: Deletes the header according to the rule

Replace Header: Replaces the header according to the rule

Modify URL: Changes the URL according to the rule

3.3.1 Content Matching

When the Rule Type selected is Content Matching the following describes the options available.

Content Rules WUI Options_1.png

Rule Name

This is the name of the rule.

Match Type:

Regular Expression: A powerful way of creating complex matching and replacement rules. Regular expressions can also be used to reference parts of the original string.

Prefix: Matches from the beginning of the string only

Postfix: Matches from the end of the string only

When Prefix or Postfix is selected, the Match String should be in the form of a pure string, not a regular expressions.

Header Field

The header field name must be matched. If no header field name is set, the default is to match the string within the URL.

Rules can be matched based on the Source IP of the client by entering src-ip within the Header Field input field. The header field will be populated by the source IP of the client.

The Header Field can be set to method in order to match on the HTTP method field.

The body of a request can also be matched by typing body in the Header Field text box. When matching on the body, up to the first 50K of the input stream will be read.

Match String

Input the pattern that is to be matched. Both Shell Regular Expressions and Perl Compatible Regular Expressions (PCRE) are supported. KEMP recommends using the PCRE syntax. Both are the same in terms of performance. Performance will be affected if a highly complex expression is used. The maximum number of characters allowed is 250.

Negation

Negation inverts the sense of the match. Without negation, all requests that include /images/ for example, would match an applicable rule.  With negation, all requests except /images/ would match the rule. 

Ignore Case

If enabled, case is ignored when comparing strings.

Include Host in URL

If selected, this option prepends the hostname, for example for example support.kemptechnologies.com, to the request URL before performing the match.

You may achieve better results by using flagging instead of using the Include Host in URL option. For more information, refer to the Use of Flags to Create Dependent Rules section.

Include Query in URL

Selecting this option includes everything after the ? in a URL. This part of the URL is the URL query.  For example, in the URL http://example.com/images/imagid.jsp?item=1, the query is item=1.

Fail on Match

If this rule is matched, then always fail to connect. If an error code or error URL is set, the code/URL will be sent back to the client.

3.3.1.1 Use of Flags to Create Dependent Rules

By using the Perform If Flag Set and Set Flag If Matched options it is possible to make rules dependent on each other i.e., only execute a particular rule(s) if another rule(s) has been successfully matched.

For example, if a rule called Test2 should execute only if a rule called Test1 was matched successfully, complete follow the following steps:

  1. Log in to the LoadMaster WUI.
  2. In the main menu, select Rules & Checking and Content Rules.

Content Rules WUI Options.png

  1. Click Modify on the Test1 rule.

Content Matching.png

  1. Select Flag 1 from the Set Flag If Matched drop-down list.
  2. Click Modify Rule.
  3. Click Modify on the Test2 rule.

Content Matching_1.png

  1. Select Flag 1 from the Perform If Flag Set drop-down list.
  2. Click Modify Rule.

When the Test1 rule is successfully matched, a flag (Flag 1) is set. The Test2 rule will not execute unless Flag 1 is set. So, Test2 cannot run unless Test1 has been successfully matched.

If a flag is set during the matching of a request, this flag can be queried when processing response header modifications, that is, if the request sets a given flag, when the server responds; any response rules that are dependent on the flag will only execute if it is set.

Up to nine rule dependencies can be set up (as there are nine flags available to set) which can create a chain of dependent rules.

3.3.2 Add Header

This command adds a static header to the request. This can be used on the client header going to the server, or on the server header going to the client.

Add Header.png

Rule Name

Used for identification, should be named to help remember what the rule does in the VS.

Header Field to be Added

The name of the field inserted in the header.

Do not add the trailing colon.

Value of Header Field to be added

This is the value that will be associated with the inserted header.

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.3.3 Delete Header

This option removes a header from the request. This can be used on the client header going to the server, or on the server header going to the client.

The delete header option uses a Regex over the whole header and value of the header. The header will only be deleted if it all matches.

For example, if the header is:

MyHeader: This is good

If /MyHeader.*This/ is matched, the field will be deleted.

If the header is:

MyHeader: bad news

It will not match so it will not be deleted.

Delete Header.png

Rule Name

Used for identification, should be named to help remember what the rule does in the Virtual Service.

Header Field to be Deleted

The LoadMaster will remove this field by this name from the request/response.

Do not add the trailing colon.

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.3.4 Replace Header

Matches a header based on its value, and replaces its value with the one specified. This can be used on the client header going to the server, or on the server header going to the client.

Replace Header.png

Rule Name

Used for identification – the name should help to remind what the purpose of the rule is.

Header Field

This is the name of the field that the substitution will be performed on.

Do not add the trailing colon.

Match String

Enter a pattern here to match against the content of this header. If the content matches the pattern, the header value will be replaced. This follows regular expression rules.

Value of Header Field to be replaced

When the rule is matched, the value of the header will be replaced with this text. Regular expressions and back references can be used here to reuse part of the existing value.

\1 and \2 can be used as back reference marks in PCRE expressions. For example, if the expression is /Fred (w.*s) here/ is replaced by /Mike is \1 and \1 as well/ will result in the following:

Input: Fred wears here

Output: Mike is wears and wears as well

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.3.5 Modify URL

A specialized header replacement that only matches the URL in the HTTP headers and replaces it with the one specified. This can be used on the client header going to the server.

Modify URL.png

Rule Name

Used for identification – the name should help to remind what the rule does in the Virtual Service.

Match String

Enter a pattern here to match against the URL. If the URL matches the pattern, the URL value will be replaced. This follows regular expression rules.

Modified URL

Enter the new URL to be sent to the server. Regular expressions and back references can be used here to reuse part of the existing value.

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.3.6 Force Complete RS Match

SCLC001.png

By default, when the LoadMaster is trying to locate a Real Server for use with content switching, it tries to use the same Real Server as currently selected, even if the port is not the same. Enabling this option forces the port to also be compared. To enable this option, go to System Configuration > L7 Configuration and select the Force Complete RS Match check box.

3.4 Content Matching Rules

Content Matching rules are also known as selection rules. These rules allow you to match all or some of a Header Field or URL string and then set flags if there is a match.

3.4.1 Adding Content Matching Rules

To add a content matching rule, follow the steps below:

Log in to the relevant LoadMaster WUI.

1. In the menu on the left, select Rules & Checking and Content Rules.

Adding Content Matching Rules.png

2. Click the Create New… button.

Adding Content Matching Rules_1.png

3. Enter a recognizable Rule Name.

4. Ensure Content Matching is selected as the Rule Type.

5. Select which Match Type to use.

For more information on the Match Type options, or any of the fields on this form, refer to the Content Matching section.

6. Enter the relevant Header Field. Or enter body to match on the body of a request.

7. Enter the Match String.

8. Enable/disable any of the check boxes as required.

9. Select any flags as needed in the Perform If Flag Set and Set Flag If Matched lists.

10. Click Create Rule.

3.4.2 Associating Content Matching Rules to a Virtual Service

Once a rule has been created, it can be associated to a Virtual Service. To do this, follow the steps below:

1. In the main menu of the LoadMaster WUI, select Virtual Services and View/Modify Virtual Services.

Associating Content Matching.png

2. Click Modify on the relevant Virtual Service.

3. Expand the Advanced Properties section.

Associating Content Matching_1.png

4. Click the Show Selection Rules button.

If any content matching rules exist on this LoadMaster, they will be visible here.

5. Select the relevant rule and click the Add button.

Associating Content Matching_2.png

If there is more than one rule in a section, the priority at which a rule is applied can be adjusted using the Promote button.

3.5 Header Modification

Modifying headers gives control over how HTTP functions. The LoadMaster has the ability to add, delete and replace HTTP headers, including URL modification. This is done on a per Virtual Service basis and can be used for request and/or response headers.

Header modification can be used to add identifying information to incoming requests. For example, if the LoadMaster is offloading SSL, the traffic back to the server is usually HTTP plain text. Normally, the server would not know that this had come in on SSL originally. A header such as SSL_Offload: Yes can be added, in order to help identify this traffic as SSL originating.

Another application would be to delete/modify sensitive information returning from the server, such as operating system or web server version.

3.5.1 Adding Header Modification Rules

To add a header modification rule, follow the steps below:

Log in to the relevant LoadMaster WUI.

1. In the menu on the left, select Rules & Checking and Content Rules.

2. Click Create New.

Adding Header Modification.png

From here a number of rule types can be added. The Add Header, Delete Header, Replace Header and Modify URL Rule Type options all modify the HTTP stream in some way. For information about what each of the fields mean, refer to the Content Rules WUI Options section. For Replace Header and Modify URL rules, shell syntax or PCRE style regular expressions can be used. For information on regular expressions, refer to the Perl Compatible Regular Expressions (PCRE) section.

3.5.2 Associating Header Rules to a Virtual Service

Once a rule has been created, it can be associated to a Virtual Service. To do this, follow the steps below:

1. Log in to the relevant LoadMaster WUI.

2. In the main menu, select Virtual Services and View/Modify Virtual Services.

Associating Content Matching.png

3. Click Modify on the relevant Virtual Service.

4. Expand the Advanced Properties section.

Associating Header Rules to.png

5. Click Show Header Rules.

Associating Header Rules to_1.png

If any header modification rules exist for this LoadMaster, they will be visible here.

Here, either Request Rules or Response Rules can be added.

Request Rules: These are modifications to the client headers going to the server.

Response Rules: These are modifications to the server headers going back to the client.

6. Select the relevant rule in the relevant section and click the Add button.

Associating Header Rules to_2.png

If there is more than one rule in a section the priority at which a rule is applied can be adjusted using the Promote button.

4 Perl Compatible Regular Expressions (PCRE)

PCRE implements regular expression pattern matching. It uses the same syntax and semantics as Perl 5. For further information regarding PCRE, please refer to www.PCRE.org

When using special characters in PCRE it is best practice to use the character’s ASCII or HTML equivalent rather than the actual character. For example, to match the percentage symbol, instead of writing /%/, for the HTML version, use /&#37/ and for the ASCII version use /\x25/.

To ensure that an expression is treated as a PCRE, the expression must be enclosed by the forward-slash character (/ ) or it will be treated as a Shell Regular Expression. For example, a PCRE expression would look like this: /^[Tt]est$/.

Character

Meaning

.

Matches any character but a line-break

\d

Matches any numeric digit

\c

Matches any alpha character

[]

Match a set of characters

?

Optionally matches the previous expression

*

Matches the previous expresssion zero or more times

+

Matches the previous expression one or more times

{x}

Matches the previous expression x times

{x, y}

Matches the previous expression x to y times

^

Matches the beginning of the string/line

$

Matches the end of the string/line

(x)

Allows grouping of expressions

a|b

Alternative expressions, matches a OR b

4.1 PCRE Examples

Some PCRE examples are below:

^/$ matches / and / only

^.*test.*$ matches the whole line of any line where test is mentioned

[A-F0-9]{8} matches a string of 8 hex characters

Gr[ae]y matches both spellings of gray/grey

(^|www.)example\.com matches www.example.com and example.com

[www]?\.example\.com matches www.example.com and example.com

^[^~].*$ match any line that does not start with ~

\s\s+ match multiple consecutive line breaks

5 Shell Regular Expressions

Regular expressions can be used to craft complex matching and replacing rules. The Match String can be a Shell Regular Expression, which is a type of statement that matches or excludes based on the strings. An asterisk (*) in a Shell Regular Expression means “match all”. 

A Shell Regular Expression is a sequence of characters. Any character, which is not a special character, will match itself. The following special characters are defined.

Character

Meaning

^

This can only be placed at the start of the string and means that the string must match at the start of the URL

$

This can only be placed at the end of the string and means that the string must match at the end of the URL

?

This matches any single character

*

This matches zero or more characters

[

This starts the set notation. This matches a single character which is contained within a set. If the set starts with ^, then this will match a single character which is not within the set

5.1 Shell Regular Expression Examples

Some examples of Shell Regular Expressions are below:

[0-9] will match any single digit

[^abf] will match any character, which is not “a”, “b” or “f”

^/[^a-z] will match any first character in the URL which is not a small letter

home/*.gif will match any URL which points to a .gif file in the /home directory

[gG][iI][fF] will match any URL which contains the string “gif”, “GIF”, “gIF”, “giF”, “GiF” and so on.

Given an input URL such as /home/cgi-bin/XXX.cmd?value=hello, the end of the string used in matching is terminated by the ? character, i.e. a postfix string of cmd will match this URL, while a postfix of hello will not. To include the end of the string, enable the Include Query in URL option.

 

6 Content Rules Cookbook

Some example rules that could be used in real life scenarios are below. For further information on content rules, and to see further examples, please refer to http://kemptechnologies.com/load-balancing-support/kemp-support.

The examples provided here are for guidance purposes only. They may not work in all configurations.

6.1 Alter the Host Header

Many times it is advantageous to have users refer to a web resource by a local hostname, rather than by the Fully Qualified Domain Name (FQDN). This can lead to server complexity if the server expects only the FQDN. This can be avoided by rewriting the host header at the LoadMaster.

Solution

Utilizing the "Rewrite_FQDN" rule below, requests will automatically have the full FQDN appended to the header so that server resources will see the full hostname.

Rule Name: Rewrite_FQDN

Rule Type: Replace Header

Header Field: Host

Match String: /(.*)/

Replacement String: \1.domain.com

Other Uses: This type of rule can be altered to perform full replacements of the hostname or more complex replacement patterns using PCRE style regular expressions.

6.2 Naked Domain Redirect

There may be scenarios when a www prefix needs to get added to the original request, for example if the original request is mydomain.com, the redirect is to www.mydomain.com

Solution

Utilizing the “Naked_Domain_Redirect” rule below, requests will automatically have www appended to the original request.

Rule Name: Naked_Domain_Redirect

Rule Type: Content Matching

Match Type: Regular Expression

Header Field: Host

Match string: /^www\..*/

Negation: Selected

Fail On Match: Selected

6.3 HTTP Redirect

There may be a need to redirect URLs, for example there is a URL called xyz.example.com and there is a new site that users should be directed to with the URL example.com/en/xyz.

Solution

To do this, two rules are needed. One to handle the host header rewrite, and the other to handle the URL rewrite.

Rule Name: Host_Rewrite

Rule Type: Replace Header

Header Field: Host

Match String: /^xyz.example.com$/

Replace String: example.com

Set Flag if Matched: Flag 1

 

Rule Name: URL_Rewrite

Rule Type: Content Matching

Match Type: Regular Expression

Match String: /^\/$/

Replace String: /en/xyz

Perform If Flag Set: Flag 1

Conditional content rules only work in LoadMaster version 6.0-44 or later.

6.4 Change a URL

In some cases, there may be a need to change a URL, depending what the original URL is, using a header modification rule. For example, changing mywebsite:81 to mynewebsite but then, if the URL is mywebsite:81/project change it to ourprojects.

Solution

Several rules are needed to achieve this kind of modification.

Rule Name: mywebsite

Rule Type: Replace Header

Header Field: Host

Match String: mywebsite

Replace String: mynewwebsite

Set Flag if Matched: Flag 1

 

Rule Name: project

Rule Type: Modify URL

Match String: /^/project$/

 

Modified URL: /

Perform If Flag Set: Flag 1

 

Rule Name: ourprojects

Rule Type: Replace Header

Header Field: Host

Match String: /.*/

Replace String: ourprojects

Perform If Flag Set: Flag 2

6.5 URL Rewrite Based on Source IP

In some cases, it may be required to rewrite a rule based on a source IP subnet. For example, if there are two different websites (A and B) on one webserver and depending on the source subnet the user should be redirected to either website A or B. The user is using the same external URL, for example aaa.bbb.com, but will get a different website based on the source IP.

Solution

This can be done one of two ways, but either will start the same. First, set up a conditional rule using the following parameters:

Rule Name: Subnet_A

Rule Type: Content Matching

Match Type: Regular Expression

Header Field: src-ip

Match String: /^10\.0\..*/

Set Flag If Matched: Flag 1

The subnet that needs to be rewritten should be entered in the Match String. It must be done as a “classful” address as the LoadMaster is using a pseudo-header “src-ip” to do a text match against the source IP of the request. That means that something like 192.168.0/17 cannot be used – instead, use something like /192\.168\.10\..*/ to match an entire Class A, B or C subnet.

Flag 1 is set if the above rule is matched. This can invoke another rule when matched. The rewrite can be done in two ways. Both are below.

Rule Name: Rewrite_Host

Rule Type: Replace Header

Header Field: Host

Match String: /.*/

Replace String: new.host.com

Perform If Flag Set: Flag 1

OR

Rule Name: Rewrite_URL

Rule Type: Modify URL

Match String: /.*/

Replace String: /new\0

Perform If Flag Set: Flag 1

Either of the two rewrite rules above can be used to either change the host header or the URL depending on how it needs to be changed on the server. KEMP recommends using the hostname option as it usually results in fewer issues.

Once the two rules have been created, navigate to the Virtual Service modify screen. In the Advanced Properties section, click Show Selection Rules and apply the Subnet_A rule. Then, click Show Header Rules and apply the rewrite rule. Now, the rewrite should be applied only to requests from the designated subnet.

6.6 Add the SSL Secure Flag and HTTPonly Flag to Cookies from the Real Server

To add flags to a cookie being generated by the Real Server, the content switching engine must be used.

Rule Name: SetSecure

Rule Type: Replace Header

Header Field: set-cookie

Match String: /(.*?);?$/

Replace String: \1; secure; httponly

Perform If Flag Set: [Unset]

6.7 Content Matching Rule Example

The diagram above shows an example architecture that can be achieved using content matching rules and SubVSs. Details are in the section below.

6.7.1 Content Matching Rules

Content Matching rules are also known as selection rules. These rules allow you to match all or some of a Header Field or URL string and then set flags if there is a match.

6.7.2 Virtual Services

To add the parent Virtual Service, follow the steps below in the LoadMaster WUI:

1. In the main menu, select Virtual Services.

2. Select Add New.

3. Enter a valid IP address.

4. Enter 80 as the Port.

5. Enter a recognizable Service Name.

6. Click Add this Virtual Service.

7. Select Super HTTP as the Persistence Mode.

8. Expand the Advanced Properties section.

9. Select X-Forwarded-For in the Add HTTP Headers drop-down list.

10. Expand the Real Servers section.

11. Click Add SubVS.

12. Click OK.

13. Click Modify.

14. Enter jdedv_1 as the SubVS Name.

15. Expand the Standard Options section.

16. Remove the tick from the Transparency check box.

17. Click Show Header Rules.

18. In the Request Rules section, select Modify URL: jde_modify_url and click Add.

19. In the Request Rules section, select Replace Header: jdedv_replace and click Add.

20. Expand the Real Servers section.

21. Click Add New.

22. Enter the relevant address in the Real Server Address text box.

23. Enter 9004 as the Port.

24. Click Add This Real Server.

The steps from 11 to 24 above describe how to add one SubVS. In this example, 8 SubVSs are needed. To add the rest of the SubVSs, follow the steps above but use the settings outlined in the table below:

SubVS Name

Transparency

Request Rules

Checked Port

Real Server Port

jdedv_1 (steps above)

Disabled

jde_modify_url

jdedv_replace

9004

9004

jdeps_1

Disabled

jdeps_replace

jde_modify_url

9001

9001

jdedv_2

Disabled

jde_modify_url

jdedv_replace_2

9004

9004

jdeps_2

Disabled

jde_modify_url

jdeps_replace_2

9001

9001

jdeit_1

Disabled

jde_modify_url

jdeit_replace

9002

9002

jdest_1

Disabled

jde_modify_url

jdest_replace

9003

9003

jdeit_2

Disabled

jde_modify_url

jdeit_replace_2

9002

9002

jdest_2

Disabled

jde_modify_url

jdest_replace_2

9003

9003

References

Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.

WUI, Configuration Guide

KEMP LoadMaster, Product Overview

Virtual Services and Templates, Feature Description

Document History

Date

Change

Reason for Change

Ver.

Resp.

Sep 2015

Release updates

Updated for 7.1-30 release

3.0

LB

Oct 2015

Release updates

Updated screenshots

4.0

LB

Jan 2016

Minor changes

Updated Copyright Notices

5.0

LB

Mar 2016

Release updates

Updated for 7.1-34 release

6.0

LB

Apr 2016

Minor updates

Enhancement made

7.0

LB

Jan 2017 Release updates Updated for 7.2.37 release 8.0 LB

 

Was this article helpful?

1 out of 1 found this helpful

Comments