Content Rewriting

Back

LBL ADC implements the content rewriting in native mode and as a fundamental component in the government of application services. The system has been studied both for a use of rewriting in the strict sense, rewriting of HTTP header or BODY HTTP, both as a system of integration layer 7 and layer 4.

By design was given the possibility to use descriptive rules to use the Java programming language or scripting languages. These two modes of rewriting can be used simultaneously.

Another fundamental aspect of which was taken into account during the design is the ease of use and a “readability intuitive” in time as developed in both the¬†descriptive rules¬†both programmatically.

This document covers the topic rewriting using many examples so you can then be reused in their own projects.

Rewriting

With the topic rewriting you identify processes that, by filtering the data in transit through a gateway, can modify the content.

In a process of transformation of this type it is evident that the relevance of the changes must be very strict deed the latter to influence not only in content but also at the level of the protocol and then influencing the behaviors.

The system of rewriting should then provide the tools necessary to modify the contents in a selective manner with simplicity.

Intervene on the protocol obviously requires a certain awareness of changes that you want to make going to affect service delivery. Nevertheless the system should be sufficiently abstract to hide the complexity of technology by ensuring the user the final result.

In view of the articulation of the argument another aspect to be taken into consideration is the possibility to intervene through simple descriptive rules leaving the possibility to intervene even through extensions of Java classes or scripting with a real programming language.

This last aspect, in addition to the rewriting, allows to carry out activities of integration with applications going to manage tasks such as Single Sign On (SSO) or aspects of attribution of the use of the applications for subsequent billing or subdivision for cost centers.

HTTP Rewriting

LBL ADC implements the rewriting of the http protocol through the development of descriptive rules.

The rules are tagged with a name so that they can be reused on different data flows and at different levels by promoting the development of their own libraries of rules.

In LBL ADC with the http protocol can be described two types of rules, a relative to the header and the other relative to the body. These two elements in fact distinguish the http message. Both of these rules are implemented in a manner similar to diversify only for the purposes of relevance.

The rules that we will develop will act in the HEADER and in the body through two paragraphs enclosed by paragraph <rewriteManagement> within the file iproxy.xml:

<rewriteManagement>

<rewriteHeaderRule>

</rewriteHeaderRule>

...

...

<rewriteBodyRule>

</rewriteBodyRule>

...

...

</rewriteManagement>

 

 

Each rule is identified by its own unique name so as to be able to be used in the various services described in paragraph <virtualDomain> and for the difference up to in paragraphs <endp>.

<rewriteManagement>

<rewriteHeaderRule name="fromHttpsToHttp302">

</rewriteHeaderRule>

<rewriteHeaderRule name="fromHttpsToHttp301">

</rewriteHeaderRule>

...

...

<rewriteBodyRule name="changeColor">

</rewriteBodyRule>

<rewriteBodyRule name=tcoprojectDevToRelative"">

</rewriteBodyRule>

...

...

</rewriteManagement>

 

 

In this case we have created 4 rules, two relating to header and two relative to the body.

To use these rules, currently empty, it will be sufficient to dichiarale on services in which you They want to apply:

<endpoints> <endPointsGrouping 

enable= "true">

<virtualDomain virtualDomainName="www.tcoproject.dev" enable= "true"

   RewriteHeaderRules="fromHttpsToHttp301 fromHttpsToHttp302"

   RewriteBodyRules="translate tcoprojectDevToRelative tcoprojectDevToRelativePOST ilAAItToRelative ilBBbolItToRelative CCItToRelativeAll adserver.ilDD.it Reload_frame LBL">

  <endp address=legendonebackend"" port=8181"" uriPath="/papaya" enable= "true"/>

  <endp address=legendonebackend"" port=8181"" uriPath="/prvSevletEcho"  Enable= "true"/>

  <endp address=legendonebackend"" port=8181"" uriPath="/training"  Enable= "true"/>

  <endp address=legendonebackend"" port=8181"" uriPath="/trainingw"  Enable= "true"/>

  <endp address=legendonebackend"" port="8282 uriPath "="/papaya"  Enable= "true"/>

  <endp address=legendonebackend"" port="8282 uriPath "="/prvServletEcho"  Enable= "true"/>

  <endp address=legendonebackend"" port="8282 uriPath "="/training"  Enable= "true"/>

  <endp address=legendonebackend"" port="8282 uriPath "="/trainingw"  Enable= "true"/>

  <endp address=legendtwobackend"" port=8181"" uriPath="/papaya"  Enable= "true"/>

  <endp address=legendtwobackend"" port=8181"" uriPath="/prvServletEcho"  Enable= "true"/>

  <endp address=legendtwobackend"" port=8181"" uriPath="/training"  Enable= "true"/>

  <endp address=legendtwobackend"" port=8181"" uriPath="/trainingw"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8282 uriPath "="/papaya"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8282 uriPath "="/prvServletEcho"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8282 uriPath "="/training"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8282 uriPath "="/trainingw"  Enable= "true"/>

  <endp address=legendonebackend"" port="8585" uriPath="/TCOProject"  Enable= "true"/>

  <endp address=legendonebackend"" port="8585" uriPath="/TCOProjectSrv"  Enable= "true"/>

  <endp address=legendonebackend"" port="8585" uriPath="/CEC2003"  Enable= "true"/>

  <endp address=legendonebackend"" port="8585" uriPath="/publictest"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8585" uriPath="/TCOProject"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8585" uriPath="/TCOProjectSrv"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8585" uriPath="/CEC2003" Enable= "true"/>

  <endp address=legendtwobackend"" port="8585" uriPath="/publictest"  Enable= "true"/>

  <endp address=legendonebackend"" port=8787"" uriPath="/TCOProject"  Enable= "true"/>

  <endp address=legendonebackend"" port=8787"" uriPath="/TCOProjectSrv"  Enable= "true"/>

  <endp address=legendtwobackend"" port=8787"" uriPath="/TCOProject"  Enable= "true"/>

  <endp address=legendtwobackend"" port=8787"" uriPath="/TCOProjectSrv"  Enable= "true"/>

  <endp address=legendonebackend"" port="8585" uriPath="/Flowers/album"  Enable= "true"/>

  <endp address=legendtwobackend"" port="8585" uriPath="/Flowers/album"  Enable= "true"/>

  <endp address=legendonebackend"" port=8787"" uriPath="/Flowers/album"  Enable= "true"/>

  <endp address=legendtwobackend"" port=8787"" uriPath="/Flowers/album"  Enable= "true"/>

  <endp address=legendonebackend"" port="as 8383 uriPath "="" enable= "false"/>

  <endp address=legendtwobackend"" port="as 8383 uriPath "="" enable= "false"/>

  <endp address=legendonebackend"" port=54443"" SSL="true uriPath "="" 

RewriteHeaderRules="test000 test001 rewriteBodyRules "="changeColor" enable= "true"/>

  <endp address=legendtwobackend"" port=54443"" SSL="true uriPath "="" 

RewriteHeaderRules="test000 test001 rewriteBodyRules "="changeColor" enable= "true"/>

  <endp address=legendonebackend"" port="8484 uriPath "="/SurfaceCluster" 

  AssociateName="SCDEGroup_00000" loadBalancingType=FailOver"" enable= "true"/>

  <endp address=legendtwobackend"" port="8484 uriPath "="/SurfaceCluster" 

  AssociateName="SCDEGroup_00001" loadBalancingType=FailOver"" 

  HealthCheck= "false" enable= "true"/>  

</virtualDomain>

  </endPointsGrouping>

 

These rules, now empty, will be implemented at a later date.

HTTP Header Rewriting

For HTTP Header Rewriting we mean all the possibility of modifying the contents of the header or to a change of behavior, for example a redirect.

We take as a first example the passage from one transmission HTTPS to a HTTP transmission. The changes to the header will be related to the requests of redirects the services that must be transformed from HTTPS (service) for HTTP. We take this process for example because the reverse process, by HTTPS to HTTP (SSL terminator), is carried out automatically by LBL ADC in a transparent manner.

The example below will make this type of change only in cases where it is required.

Resuming our XML example we will have to go to describe in which flows we want to carry out the change. Wishing to carry out the change in the return flow from the server, the response, we indicate in rules that their application should take place only in that sense.

<rewriteManagement>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp302">

</rewriteHeaderRule>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp301">

</rewriteHeaderRule>

...

...

<rewriteBodyRule name="changeColor">

</rewriteBodyRule>

<rewriteBodyRule name="tcoprojectDevToRelative">

</rewriteBodyRule>

...

...

</rewriteManagement>

With parameter “flow” we went to identify the direction of application of the rule. The parameter “flow” can have three values:¬†RESPONSE,¬†REQUEST,¬†BOTH, in dependence of the flow that we want to intercept.

In this image is evidenziala differentiation of the flow of request and response:

After you have identified the flow that we want to intercept we should increasingly “filter” rule only for events that tipizzeranno its application. As we will see later¬†LBL ADC,¬†in paragraphs of rewriting (<rewriteHeaderRule>¬†and¬†<rewriteBodyRule>), implements a superfine system conditions. To facilitate the implementations have however been made available to some of the conditions most used directly on paragraph¬†<rewriteHeaderRule>¬†(and in equal measure in paragraph¬†<rewriteBodyRule>).

Between these conditions for example you can indicate directly the responseCode parameter for which apply the rule. If enhanced  responseCode will be taken into consideration only in the flow of resposne.

<rewriteManagement>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp302"

   ResponseCode="302">

</rewriteHeaderRule>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp301"

   ResponseCode="301">

</rewriteHeaderRule>

...

...

<rewriteBodyRule name="changeColor">

</rewriteBodyRule>

<rewriteBodyRule name=tcoprojectDevToRelative"">

</rewriteBodyRule>

...

...

</rewriteManagement>

In this case the two rules identified by the names¬†“fromHttpsToHttp302”¬†and¬†“fromHttpsToHttp301”¬†will be applied only in correspondence of the flow of¬†response¬†and only in cases of redirection controlled by the services of the backend identified by the return codes¬†302,¬†MOVED TEMPORARILY, and¬†301¬†MOVED PERMANENTLY.

Below, after identifying exactly the flow and the condition of application, we will further define the boundary of action of rules restricting them to a single domain.

<rewriteManagement>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp302"

   ResponseCode="302">

<conditions>

<cond from="entity" name="Location">

<regexTag>^Https://www.tcoproject.dev</regexTag>

</cond>

<cond from=INNERVAR"" 

Name="REQUEST_HTTP_HOST_NAME">

<regexTag>www.tcoproject.dev</regexTag>

</cond>

</conditions>

</rewriteHeaderRule>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp301"

      ResponseCode="301">

<conditions>

<cond from="entity" name="Location">

<regexTag>^Https://www.tcoproject.dev</regexTag>

</cond>

<cond from=INNERVAR"" 

Name="REQUEST_HTTP_HOST_NAME">

<regexTag>www.tcoproject.dev</regexTag>

</cond>

</conditions>

</rewriteHeaderRule>

...

...

<rewriteBodyRule name="changeColor">

</rewriteBodyRule>

<rewriteBodyRule name=tcoprojectDevToRelative"">

</rewriteBodyRule>

...

...

</rewriteManagement>

 

 

The result of the introduction of this new paragraph <conditions> is the application of the rule only for the headers that are trying to make a redirect on URL with https protocol to the domain name www.tcoproject.dev.

In this example was then introduced the concept of “condition” explicit in a paragraph. The condition can be exerted on all the elements of the header or on parts of them through regular expressions.

Below will be analyzed point by point the conditions mentioned above. The construction of a condition begins by paragraph¬†<conditions>. This paragraph contains all of the conditions relating to the rule. All the conditions will be evaluated with an¬†AND operator¬†(default) if not otherwise specified by the appropriate parameter “operator”:

<conditions operator="and">

<cond ...

<cond ...

...

<conditions operator="or">

<cond ...

<cond ...

...

 

In our case not having indicated an operator  will automatically be assumed the AND operator and then only if all the conditions inside the paragraph <conditions> will verify the rule will be applied. The first condition, identified by paragraph <cond>, indicates first of all from where you want to obtain the element to be tested.

<conditions>

<cond from="entity" name="Location">

<regexTag>^https://www.tcoproject.dev</regexTag>

</cond>

...

 

In the parameter “from” may be indicated the following items from which to draw the information:

¬†INNERVAR=preloaded values from¬†LBL¬ģADC¬†to facilitate operations

INNER VARIABLES

===============

REQUEST_HTTP_URL=Request URL with params and query string

REQUEST_HTTP_URL_LAST_ELEMENT=only last element of the URL without params and

Query string

REQUEST_HTTP_URI_PATH=Only URI Path whithout parameters and query string

REQUEST_HTTP_HOST_NAME=hosname in entity “Host”¬†(Note: The use of this

Innervar can determine the name resolution through DNS.

If the name is not associated with any address its timeout can

Cause a strong deceleration)

REQUEST_HTTP_HOST_PORT= port number in the entity “Host”

REQUEST_HTTP_COOKIES_LIST= List of cookies names separated by “;”

REQUEST_CLIENT_ADDRESS=TCP client address

RESPONSE_ENDPOINT_ADDRESS=TCP endpoint address

SSL_CONNECTION_CLIENT = true if the client connects to SSL with LBL

SSL_CONNECTION_ENDPOINT = true if the endpoint connects to SSL with LBL

SSL_CONNECTION_REENCRYPTION = true if it runs the reencryption SSL

(Then LBL ago SSL termination and connects to the endpoint in SSL)

REQUEST_INCOMING_ADDRESS = local address on which has been accepted the request

Of Service

REQUEST_INCOMING_HOST_NAME = host name or local address on which has been accepted

The service request (attention: the use of this

Innervar can determine the name resolution through DNS.

If the name is not associated with any address its timeout can

Cause a strong deceleration)

REQUEST_HTTP_SCHEME = http or https depending on the type of client connection toward LBL

HIGH_WATER_YELLOW_WARNING_REACHED = if true was exceeded the threshold Yellow

Warning. Thus indicates a considerable load but not yet

Critical.

HIGH_WATER= number of connection requests in the queue in long format.

HIGH_WATER_LEVEL= % of connection requests in the queue compared to the number of

Tunnels contemporary settings, this is a float value.

TUNNEL_SESSIONS_ACTIVE= Instant active tunnels, int format.

TUNNEL_SESSIONS_COMMITTED= Instant tunnel committed, (subset of¬† ¬† TUNNEL_SESSIONS_ACTIVE”

These values “preloaded” to be used as modifiers (%xxx%) must

However to be loaded in a local variable to the rule.

The entity=loading of the variable described in varName with the value of the Entity

The HTTP header whose name is indicated in the name.

URI_PARAM=loading of the variable described in varName with the value of the

Parameter or query string of the HTTP header whose name is shown in

Name.

CONSTANT=loading of the variable described in varName with the value of the parameter

Indicated in the name. Only in this case the value contained in the name can be

Composed of another variable previously loaded.

COOKIE=loading of the variable described in varName with the cookie value

The HTTP header whose name is indicated in the name.

VARIABLE=loading of the variable described in varName with the value of another    The variable whose name is indicated in the name.

A complete discussion of all the arguments and parameters is available on the manual LBL S.A.A.I. Reference Guide. In this case the first test condition is extracted by an entity.

For the entity is intended as an element of the HTTP header delimited by a CRLF.

GET / HTTP/1.1

Host: www.tcoproject.dev

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; it; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2

Accept: text/html,application/XHTML+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 115

Connection: keep-alive

Cookies: LBLSESSIONID=1277228676044; TCOPROJECTAUTH=1277048578420; TCOPROJECTSESSIONID=1277048578511; SSID_caltagroup=453794224774; SV_caltagroup 1276415693024=HTTP/1.1 302 MOVED TEMPORARILY

Server: TCOProject(R)-http-appserver/3.1

Dates: Sun, 164 Jun 2010 10:40:26 CEST

Content-Length: 0

Location: Https://www.tcoproject.dev/login.html

In this case for the entity you intend to

Host,

User-Agent,

Accept,

Location,

Etc…

While their value is respectively:

www.oplon.net

Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.2.3) Gecko/20100401…

image/png,image/*;q=0.8,*/*;q=0.5

https://www.tcoproject.dev/login.html

Then, with the expression below, it extracts the value from theentity¬†“Location” and occurs through a regular expression that the content has valueHttps://www.tcoproject.dev “” with departure from the first character (indicated with the expression “^“).

<cond from="entity" name="Location">

<regexTag>^https://www.tcoproject.dev</regexTag>

</cond>

 

If the value content was: “https://www.TcOpRoJeCt.DeV” however the result would be verified because the conditions¬†are not¬†caseSensitve. If we wanted to indicate a regular expression with distinction between lowercase and uppercase characters we could indicate in paragraph¬†<conditions>¬†to¬†caseSensitve parameter¬†which by default is enhanced to¬†false:

In this case all the conditions will not be caseSensitive if not otherwise indicated on the individual paragraphs <conf>:

<conditions caseSensitive= "false">

<cond from="entity" name="Location">

<regexTag>^https://www.tcoproject.dev</regexTag>

</cond>

...

 

In this case all the conditions will not be caseSensitive while the first condition will take account of the difference of characters:

<conditions caseSensitive= "false">

<cond from="entity" name="Location" caseSensitive= "true">

<regexTag>^https://www.tcoproject.dev</regexTag>

</cond>

...

 

In this case all the conditions will be caseSensitive sand not otherwise indicated as in the first condition:

<conditions caseSensitive= "true">

<cond from="entity" name="Location" caseSensitive= "false">

<regexTag>^https://www.tcoproject.dev</regexTag>

</cond>

...

 

 

In the specific case of the example being the URISchema and URIHost not sensitive to differentiation lowercase or uppercase letters (as by recommendations W3C) the test more exact to do is¬†caseSensitive= “false”.

We shall now analyze the second condition:

<conditions>

<cond from="ENTITY" name="location">

<regexTag>^https://www.tcoproject.dev</regexTag>

</cond>

<cond from=INNERVAR"" 

   Name="REQUEST_HTTP_HOST_NAME">

  <regexTag>www.tcoproject.dev</regexTag>

</cond>

</conditions>

 

This second condition verifies that the host to which had been addressed to the request is equivalent to the host of redirection in response in order to perform the rewriting. In fact, if it had been different would not have had to perform the rewriting being a redirect not relevant to the domain concerned. With this test you introduces a new source of information and that is the INNERVAR. For INNERVAR you indicate a set of values which are already available to use to facilitate writing rules of rewriting. In this case even though in a flow of response we can also check the values of the request that generated it.

Other types of sources of information can be used as indicated above in the list.

Once you enter the conditions of verification can enter the actions you want to take in the header.

The actions in the header may be of two types:

1- Changes in one or more elements of the header

2- commanding a redirect

To change one or more elements of the header is sufficient to insert the paragraph <entities> that will be used to list the actions to be taken.

<rewriteManagement>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp302"

   ResponseCode="302">

<conditions>

<cond from="entity" name="Location">

  <regexTag>^Https://www.tcoproject.dev</regexTag>

</cond>

<cond from=INNERVAR"" 

   Name="REQUEST_HTTP_HOST_NAME">

  <regexTag>www.tcoproject.dev</regexTag>

</cond>

</conditions>

<entities>

<entity entityName="Location" action=change"">

<regexTag>^https</regexTag>

<replaceTohttp></replaceTo>

</entity>

</entities>

</rewriteHeaderRule>

<rewriteHeaderRule flow="response" name="fromHttpsToHttp301"

   ResponseCode="301">

<conditions>

<cond from="entity" name="Location">

  <regexTag>^Https://www.tcoproject.dev</regexTag>

</cond>

<cond from=INNERVAR"" 

   Name="REQUEST_HTTP_HOST_NAME">

  <regexTag>www.tcoproject.dev</regexTag>

</cond>

</conditions>

<entities>

<entity entityName="Location" action=change"">

  <regexTag>^https</regexTag>

  <replaceTohttp></replaceTo>

</entity>

</entities>

</rewriteHeaderRule>

Paragraph <entities> contains the actions to be carried out in the header.

<entities>

<entity entityName="Location" action=change"">

  <regexTag>^https</regexTag>

  <replaceTohttp></replaceTo>

</entity>

</entities>

</rewriteHeaderRule>

 

In the specific case you will act in the value of’entity¬†“Location” Changing (Change), the value that begins withhttps “” with the corresponding value “http“:

…From:HTTP/1.1 302 MOVED TEMPORARILY

Server: TCOProject(R)-http-appserver/3.1

Dates: Sun, 164 Jun 2010 10:40:26 CEST

Content-Length: 0

Location: ¬†https://www.tcoproject.dev/login.html…to:HTTP/1.1 302 MOVED TEMPORARILY

Server: TCOProject(R)-http-appserver/3.1

Dates: Sun, 164 Jun 2010 10:40:26 CEST

Content-Length: 0

Location: http://www.tcoproject.dev/login.html

This simple operation allows you to have as a final result a data transmission with HTTP source and the corresponding services in HTTPS.

As said previously¬†LBL¬ģADC¬†in reverse flow, i.e. as the terminator of HTTPS session, performs this operation automatically and then None required.

HTTP Header Rewriting Redirect

Another possibility at the level of the header is to perform a redirect conditional. Obviously this would be possible by modifying the entity for the entity the header. Being an operation very used has created a special paragraph <redirectTo>  to facilitate the operation.

<rewriteHeaderRule enable= "true" flow="REQUEST" name="test000 caseSensitive "= "false"

   HttpInterceptorClass=loadbalancer".rewriter.LBLHTTPRewriteInterceptorHeaderLogging"

   HttpMethod="get">

<conditions operator="and">

<cond from=INNERVAR"" name="REQUEST_HTTP_HOST_NAME">

<regexTag>www.tcoproject.dev</regexTag>

</cond>

<cond from=INNERVAR"" name="REQUEST_HTTP_URL" caseSensitive= "true">

<regexTag>^/viewProcessProperties.html\?process=A00_LBLGoSysCommand$</regexTag>

</cond>

<cond from=INNERVAR"" name="REQUEST_HTTP_URI_PATH">

<regexTag>^/viewProcessProperties.html$</regexTag>

</cond>

<cond from="entity" name="Connection">

<regexTag>Keep-alive</regexTag>

</cond>

<cond from="URI_PARAM" name="process">

<regexTag>A00_LBLGoSysCommand</regexTag>

</cond>

</conditions>

<redirectTo responseCode="302" redirectURL=http://www.tcoproject.dev/training?myParam=AAA""/>

</rewriteHeaderRule>

 

At this point you should already be able to “read” this rule of rewriting even if were introduced new elements such as the parameters¬†flow=”REQUEST” and ¬†httpMethod=”get” that filter requests with HTTP¬†GET method¬†and that they also meet other conditions before running as established on paragraph¬†<redirectTo>.

If all the conditions are verified then will be controlled a redirect with response queues 302 at address Http://www.tcoproject.dev/training with a query string myParam=AAA.

A new parameter instead deserves a closer look, the parameter is¬†httpInterceptorClass¬†valued in this case with “loadbalancer.rewriter.LBLHTTPRewriteInterceptorHeaderLogging”.

This parameter indicates the rule to perform also a user class. This functionality will be detailed hereinafter.

HTTP Header Rewriting with variables

The use of variables is the most simplified and powerful has been realized to extract the values from the data in transit and dial in a simple manner the new values to be reused. Variables such as the conditions, can be used both in the rules of rewriting of the header is in the rules of rewriting of the body.

For variable would be a “symbolic name” that is used to indicate a value in a given context in a given time.

In the rules of rewriting variables are used to store values that can derive from different sources previously declared, including of the variables themselves.

The case that we want to use to explain the use of variables is the same as the previous redirect where however the URL redirection will be populated by constant values and with variable values from the data flow itself.

Imagine you want to perform a redirect with a parameter having the value as the value derived from a cookie if valued.

<rewriteHeaderRule enable= "true" flow="REQUEST" name="test000 caseSensitive "= "false"

   HttpInterceptorClass=loadbalancer".rewriter.LBLHTTPRewriteInterceptorHeaderLogging"

   HttpMethod="get">

<variables>

<var varName="MY_LBLSESSIONID" name=LBLSESSIONID"" from="cookies"/>

</variables>

<conditions>

<cond  from="cookies" name=LBLSESSIONID"" eval="not">

<regexTag></regexTag>

</cond>

<cond from=INNERVAR"" name="REQUEST_HTTP_HOST_NAME">

<regexTag>www.tcoproject.dev</regexTag>

</cond>

<cond from=INNERVAR"" name="REQUEST_HTTP_URL" caseSensitive= "true">

<regexTag>^/viewProcessProperties.html\?process=A00_LBLGoSysCommand$</regexTag>

</cond>

</conditions>

<redirectTo responseCode= "302" 

  RedirectURL=http://www.lblloadbalancer.dev/training?myParam=%MY_LBLSESSIONID%""/>

</rewriteHeaderRule>

 

You will immediately notice a new paragraph identified by the tag¬†<variables>¬†and a new parameter at state level:¬†eval=”not”.

In the specific paragraph <variables> serves to declare variables that will be loaded when the data flow. Also in this case the sources of loading of the variables can be plural and for most of these sources are in common with the sources on the paragraph of condition.

In this case the value will be loaded with the contents of the COOKIE LBLSESSIONID only if present.

<variables>

<var varName="MY_LBLSESSIONID" name=LBLSESSIONID"" from="cookies"/>

</variables>

 

Other sources of information can be used for the purpose of loading a variable and below a list of the sources of information. For details, and a complete list, please refer to the manual¬†LBL¬ģADC¬†Reference Guide:

INNERVAR=preloaded values from¬†LBL¬ģADC¬†to facilitate operations

INNER VARIABLES

===============

REQUEST_HTTP_URL=Request URL with params and query string

REQUEST_HTTP_URL_DECODED =Request URL with params and query string decoded

REQUEST_HTTP_URL_LAST_ELEMENT=only last element of the URL without params and

Query string

REQUEST_HTTP_URI_PATH=Only URI Path whithout parameters and query string

REQUEST_HTTP_URI_PATH_DECODED=URI Path whithout parameters and query string in    Decoded format

REQUEST_HTTP_HOST_NAME=hosname in entity “Host”¬†(Note: The use of this

Innervar can determine the name resolution through DNS.

If the name is not associated with any address its timeout can

Cause a strong deceleration)

REQUEST_HTTP_HOST_PORT= port number in the entity “Host”

REQUEST_HTTP_COOKIES_LIST= List of cookies names separated by “;”

REQUEST_CLIENT_ADDRESS=TCP client address

RESPONSE_ENDPOINT_ADDRESS=TCP endpoint address

SSL_CONNECTION_CLIENT = true if the client connects to SSL with LBL

SSL_CONNECTION_ENDPOINT = true if the endpoint connects to SSL with LBL

SSL_CONNECTION_REENCRYPTION = true if it runs the reencryption SSL

(Then LBL ago SSL termination and connects to the endpoint in SSL)

REQUEST_INCOMING_ADDRESS = local address on which has been accepted the request

Of Service

REQUEST_INCOMING_HOST_NAME = host name or local address on which has been accepted

The service request (attention: the use of this

Innervar can determine the name resolution through DNS.

If the name is not associated with any address its timeout can

Cause a strong deceleration)

REQUEST_HTTP_SCHEME = http or https depending on the type of client connection toward LBL

HIGH_WATER_YELLOW_WARNING_REACHED = if true was exceeded the threshold Yellow

Warning. Thus indicates a considerable load but not still

Critical.

HIGH_WATER= number of connection requests in the queue in long format.

HIGH_WATER_LEVEL= % of connection requests in the queue compared to the number of

Tunnels contemporary settings, this is a float value.

TUNNEL_SESSIONS_ACTIVE= Instant active tunnels, int format.

TUNNEL_SESSIONS_COMMITTED= Instant tunnel committed, (subset of¬† ¬† TUNNEL_SESSIONS_ACTIVE”

ACTUAL_TUNNEL_SESSIONS_SIZE= The actual size of tunnels: (usually equal to

“MAX_tunnel_SESSIONS_SIZE”)

MAX_TUNNEL_SESSIONS_SIZE= Maximum number of tunnels set.

These values “preloaded” to be used as modifiers (%xxx%) must

However to be loaded in a local variable to the rule.

The entity=loading of the variable described in varName with the value of the Entity

The HTTP header whose name is indicated in the name.

URI_PARAM=loading of the variable described in varName with the value of the

Parameter or query string of the HTTP header whose name is shown in

Name.

URI_PARAM_DECODED=value of parameter “name” taken from the query string of HTTP headers, in¬† ¬† Decoded format

CONSTANT=loading of the variable described in varName with the value of the parameter

Indicated in the name. Only in this case the value contained in the name can be

Composed of another variable previously loaded.

COOKIE=loading of the variable described in varName with the cookie value

The HTTP header whose name is indicated in the name.

VARIABLE=loading of the variable described in varName with the value of another    The variable whose name is indicated in the name.

Another new element is the condition that returns the modifier¬†eval=”not”. This condition negativizza the result so that if will be blank will be discarded by giving a negative result:

<cond  from="cookies" name=LBLSESSIONID"" eval="not">

<regexTag></regexTag>

</cond>

 

Paragraph <redirectTo> shows the URL redirection with constant parts and variable parts derived from the passage of information:

<redirectTo responseCode= "302" 

  RedirectURL=http://www.lblloadbalancer.dev/training?myParam=%MY_LBLSESSIONID%""/>

 

The example below shows a rule with a usage, didactic, intensive variables:

<rewriteHeaderRule enable= "true" flow="REQUEST" name="test001 caseSensitive"= "false"

   HttpInterceptorClass=loadbalancer".rewriter.LBLHTTPRewriteInterceptorHeaderLogging"

   HttpMethod="get">

<variables>

<!-- load variables from innervar -->

<var varName="MY_REQUEST_HTTP_URL" Name="REQUEST_HTTP_URL" From="INNERVAR"/>

<var varName="MY_REQUEST_LAST_URL_ELEMENT" Name="REQUEST_HTTP_URL_LAST_ELEMENT" from=INNERVAR""/>

<var varName="MY_REQUEST_HTTP_URI_PATH" Name="REQUEST_HTTP_URI_PATH"  From=INNERVAR""/>

<var varName="MY_REQUEST_HTTP_HOST_NAME" Name="REQUEST_HTTP_HOST_NAME"  From=INNERVAR""/>

<var varName="MY_PORT" Name="REQUEST_HTTP_HOST_PORT" From=INNERVAR""/>

<var varName="MY_response_endpoint_ADDRESS"  Name="response_endpoint_ADDRESS"  From=INNERVAR""/>

<var varName="MY_REQUEST_HTTP_HOST_PORT" Name="REQUEST_HTTP_HOST_PORT" From=INNERVAR"">

<regexTag>%MY_PORT%</regexTag>

<replaceTo>10100</replaceTo>

</var>

<var varName="MY_REQUEST_CLIENT_ADDRESS" Name="REQUEST_CLIENT_ADDRESS" From=INNERVAR""/>

<var varName="MY_response_endpoint_ADDRESS" Name="response_endpoint_ADDRESS"  From=INNERVAR""/>

<var varName="MY_REQUEST_HTTP_COOKIES_List" Name="REQUEST_HTTP_COOKIES_List"  From=INNERVAR""/>

<!-- load variables from contant values -->

<var varName="MY_IS" Name="is"  From="CONSTANT"/>

<var varName="MY_Var_FROM_THIS_VALUE" Name="this is my value %MY_REQUEST_HTTP_URL%" from="CONSTANT">

<regexTag>this %MY_IS % to my value</regexTag>

<replaceTo>this %MY_IS % to my value %MY_REQUEST_HTTP_HOST_PORT% HTTP_URL</replaceTo>

</var>

<!-- load variables from header entity -->

<var varName="MY_Var_FROM_ENTITY" Name="Connection"  From="entity">

<regexTag>Keep-alive</regexTag>

<replaceTo>Close</replaceTo>

</var>

<!-- load variables from uri params or query string -->

<var varName="MY_PROCESS" Name="process"  From="URI_PARAM"/>

<var varName="MY_PARAM" Name="paramName"  From="URI_PARAM">

<regexTagvalueInParamQueryString></regexTag>

<replaceTonewValueInVar></replaceTo>

</var>

<!-- extract cookie value -->

<var varName="MY_Var_cookie_LBLSESSIONID" Name=LBLSESSIONID""  From="cookies"/>

<var varName="MY_Var_cookie_TCOPROJECTAUTH" Name=TCOPROJECTAUTH""  From="cookies"/>

<var varName="MY_Var_cookie_TCOPROJECTSESSIONID" name=TCOPROJECTSESSIONID""  From="cookies"/>

<var varName="MY_Var_cookie_JSESSIONID" Name=JSESSIONID""  From="cookies"/>

<var varName="MY_Var_cookie_jsessionid" Name=jsessionid""  From="cookies"/>

<var varName="MY_Var_cookie_NOTFOUND" Name=NOTFOUND""  From="cookies"/>

<!-- only cookies list names -->

<var varName="MY_REQUEST_HTTP_COOKIES_LIST000" Name="REQUEST_HTTP_COOKIES_List"  From=INNERVAR"">

<regexTag>(*)(LBLSESSIONID)(.*)</regexTag>

<replaceTo>$2</replaceTo>

</var>

<var varName="MY_REQUEST_HTTP_COOKIES_LIST001" Name="REQUEST_HTTP_COOKIES_List"  From=INNERVAR"">

<regexTag>(*)(TCOPROJECTAUTH)(.*)</regexTag>

<replaceTo>$2</replaceTo>

</var>

<var varName="MY_REQUEST_HTTP_COOKIES_LIST002" Name="REQUEST_HTTP_COOKIES_List"  From=INNERVAR"">

<regexTag>(*)(TCOPROJECTSESSIONID)(.*)</regexTag>

<replaceTo>$2</replaceTo>

</var>

<!-- extract cookies from entity -->

<var varName="MY_Var_COOKIES" Name="Cookies"  From="entity">

<regexTag>(.)+</regexTag>

<replaceTo>$1;</replaceTo>

</var>

<!-- extract cookies from entity through variable -->

<var varName="MY_Var_cookie_LBLSESSIONID_FV00"  Name="MY_Var_COOKIES"  From="VARIABLE">

<regexTag>(*)(LBLSESSIONID=)(.+?)((;+?)(.*))</regexTag>

<replaceTo>$3</replaceTo>

</var>

<var varName="MY_Var_cookie_LBLSESSIONID_FV01"  Name="MY_Var_COOKIES"  From="VARIABLE">

<regexTag>(*)(TCOPROJECTAUTH=)(.+?)((;+?)(.*))</regexTag>

<replaceTo>$3</replaceTo>

</var>

<var varName="MY_Var_cookie_LBLSESSIONID_FV02"  Name="MY_Var_COOKIES"  From="VARIABLE">

<regexTag>(*)(TCOPROJECTSESSIONID=)(.+?)((;+?)(.*))</regexTag>

<replaceTo>$3</replaceTo>

</var>

</variables>

<conditions operator="and">

<cond enable= "false" from="cookies" name=LBLSESSIONID"" eval="not">

<regexTag></regexTag>

</cond>

<cond from="VARIABLE" name="MY_IS caseSensitive "= "true">

<regexTag>is</regexTag>

</cond>

<cond from=INNERVAR"" name="REQUEST_HTTP_HOST_NAME">

<regexTag>www.tcoproject.dev</regexTag>

</cond>

<cond enable= "false" from=INNERVAR"" name="REQUEST_CLIENT_ADDRESS">

<regexTag>127.0.0.1</regexTag>

</cond>

<cond from=INNERVAR"" name="REQUEST_HTTP_URL" caseSensitive= "true">

<regexTag>^/viewProcessProperties.html\?process=A05_LBLGoDNSManager$</regexTag>

</cond>

<cond from=INNERVAR"" name="REQUEST_HTTP_URI_PATH">

<regexTag>^/viewProcessProperties.html$</regexTag>

</cond>

<cond from="entity" name="Connection">

<regexTag>Keep-alive</regexTag>

</cond>

<cond from="URI_PARAM" name="process">

<regexTag>A05_LBLGoDNSManager</regexTag>

</cond>

</conditions>

<redirectTo responseCode="302" 

  RedirectURL=http://www.tcoproject.dev/trainingw?http://%MY_REQUEST_HTTP_HOST_NAME%:%MY_REQUEST_HTTP_HOST_PORT%/mynew" path"/></rewriteHeaderRule>

 

HTTP Header Rewriting with extended Java classes

As seen above it is possible to indicate in a rule using a class in Java defined and written by the user.

This functionality can be used simultaneously as seen up to now because the class is an extension of a class specially created in LBL ADC to this purpose. The class provides 6 times (methods):

1-interceptorInit (invoked once to initialize the object)

2-interceptorEnd (invoked once at the termination of the object)

3-doRequestHeaderBeforeReplace

4-doRequestHeaderAfterReplace

5-doResponseHeaderBeforeReplace

6-doResponseHeaderAfterReplace

Package loadbalancer.rewriter;

import loadbalancer.rewriter.LBLHTTPInterceptorHeaderAbstr;

import loadbalancer.rewriter.LBLHTTPInterceptorHeaderStreamFragment;/**

 * Test class HTTP Header Interceptor for dynamic change during stream

 * @version 1.0 created on 5-Jun-2010

 */

public class  extends LBLHTTPRewriteInterceptorHeaderLogging LBLHTTPInterceptorHeaderAbstr {

/** Copyright */

Public static final String COPYRIGHT="LBL and TCOProject are trademarks all rights reserved";@Override

Public void interceptorInit() {

}

@Override

Public void interceptorEnd() {

}

@Override

Public void doRequestHeaderBeforeReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) {

LogWarning("REQUEST HEADER BEFORE REPLACE\n"+

  StreamFragment.getRequestRowImageStreamFragment());

For (String varName: streamFragment.getVariables())

LogWarning("RQBR HEADER VarName:"+varName+

   " Value:"+streamFragment.getVariable(varName));

}

@Override

Public void doRequestHeaderAfterReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) {

LogWarning("REQUEST HEADER AFTER REPLACE\n"+

  StreamFragment.getRequestRowImageStreamFragment());

}

@Override

Public void doResponseHeaderBeforeReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) {

LogWarning("RESPONSE HEADER BEFORE REPLACE\n"+

  StreamFragment.getResponseRowImageStreamFragment());

For (String varName: streamFragment.getVariables())

LogWarning("REBR HEADER VarName:"+varName+

   " Value:"+streamFragment.getVariable(varName));

}

@Override

Public void doResponseHeaderAfterReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) {

LogWarning("RESPONSE HEADER AFTER REPLACE\n"+

   StreamFragment.getResponseRowImageStreamFragment());

}}

Also included in our “gear” methods will be invoked in sequence under exposed, obviously if have not been declared via XML or controlled through JAVA program of redirect. In that case some of these methods will not be retrieved.

Within each method is made available to an object that represents the “fragment” consisting of what is passing.

In the example seen previously, and available from library LBL ADC, within each method were carried out some actions like the one shown below:

@Override

Public void doRequestHeaderBeforeReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) {

logWarning("REQUEST HEADER BEFORE REPLACE\n"+

StreamFragment.getRequestRowImageStreamFragment());

for (String varName: streamFragment.getVariables())

LogWarning("RQBR HEADER VarName:"+varName+

" Value:"+streamFragment.getVariable(varName));

}

 

The LBLHTTPInterceptorHeaderAbstr class provides several methods and among these the possibility to log onto the system logging LBL ADC.

/**

* Generating a message with type |Error|

* @Param logMessage message to persist on log files

*/

Public void logError(String logMessage)

/**

* Generating a message with type |WARNING|

* @Param logMessage message to persist on log files

*/

Public void logWarning(String logMessage)

/**

* Generating a message with type |DEBUG| only if the definition of launch
* Java ... -DDEBUG=true - DLBL_DEBUG_REWRITING=true ...

* @Param logMessage message to persist on log files

*/

Public void logDebug(String logMessage)

 

In this case by the fragment of header, passed as a parameter to the method, it is possible to request list the declared variables and use the value:

For (String varName: streamFragment.getVariables())

LogWarning(“RQBR HEADER VarName:”+varName+” value:”+streamFragment.getVariable(varName));

Other methods for querying and manipulating data are available on the object streamFragment such as those relating to the management of entities:

* get entity value

* @param entityName entity name e.g. Content-Type:

* @return entity value or null if not match

*/

public getHTTPEntity String(String entityName)

/**

* Remove an enity

* @param entityName

*/

public void removeEntity(String entityName)

/**

* Append an entity

* Warning: this method doesn't remove any entity... use changeEntity for change it.

* @param entity

*/

public void appendEntity(String entityName, String entityValue)

/**

* Change an entity

* @param entity

*/

public void changeEntity(String entityName, String entityValue)

/**

* Replace first line

* @param firstLineHeader new first header line

*/

public void changeFirstHeaderLine(String firstLineHeader)

 

A complete list of the methods is available in the manual LBL ADC Reference Guide.

The location of the classes is dependent from the name of the package that will be used and will be relative to the directory (see chapter created in Java extended class in this manual):

HTTP header rewriting the displace endPointsGrouping

With this directive it is possible to displace in another EndPointsGrouping a request from an afferent listener to a different EndPointsGrouping.

This functionality is achieved using the rules of rewriting of the header with a new paragraph that indicates the action of displacement.

The simplest form is given below:

 <rewriteHeaderRule enable= "true" flow="REQUEST" name=setEndpGrouping"">

<displaceEndPointsGrouping enable="true endPointsGrouping "="services001"/>

 </rewriteHeaderRule>

 

Paragraph <displaceEndPointsGrouping> (displace = displacement) indicates where the request must refer as endPointsGrouping.

It is possible to use all forms already envisaged for the composition of the displacement as for example the variables and conditions:

 <rewriteHeaderRule enable= "true" flow="REQUEST" name=setEndpGrouping"">

<variables>

<var varName="DISPLACE_TO_GROUP" name="services001" from="CONSTANT"/>

</variables>

<displaceEndPointsGrouping enable="true endPointsGrouping "="%DISPLACE_TO_GROUP %"/>

 </rewriteHeaderRule>

 

The displace and you can control it also from class interceptor Java HEADER:

<rewriteHeaderRule enable= "false" flow="REQUEST" name=setEndpGrouping""

   HttpInterceptorClass="my_httprewriters.LBLDisplaceEndPointGroupingTemplate">

</rewriteHeaderRule>

Import loadbalancer.rewriter.LBLHTTPInterceptorHeaderAbstr;

import loadbalancer.rewriter.LBLHTTPInterceptorHeaderStreamFragment;/**

 * Template interceptor class for the displace EndPointsGrouping * @author TCOProject(r) * @version 1.0 created on 12-Feb-2011, 17.04.05 */

public class extends LBLDisplaceEndPointGroupingTemplate LBLHTTPInterceptorHeaderAbstr{

  …

  @overriding

public  void doRequestHeaderBeforeReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) { streamFragment.setEndPointsGrouping("services001");

  }

  @overriding

public  void doRequestHeaderAfterReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) {

  }

  @overriding

public  void doResponseHeaderBeforeReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) {

  }

  @overriding

public  void doResponseHeaderAfterReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment) { }}

 

HTTP BODY Rewriting

The rewriting of the¬†HTTP BODY¬†is currently the most sophisticated you can use in this field. It is possible to simultaneously use both descriptive rules both extensions of Java classes¬†or scripting. In both cases the data are “passed” to rewriter with buffer consisting in order to apply regular expressions of modification.

The use of the rules of rewriting for the body is similar to the use of the rules of rewriting of the header and then once used one or the other was quickly able to use both.

Let us look again at the fragment of initial rules to go to carry out the first rewriting of the body.

<rewriteManagement>

<rewriteHeaderRule name="fromHttpsToHttp302">

</rewriteHeaderRule>

<rewriteHeaderRule name="fromHttpsToHttp301">

</rewriteHeaderRule>

...

...

<rewriteBodyRule name="changeColor">

</rewriteBodyRule>

<rewriteBodyRule name=tcoprojectDevToRelative"">

</rewriteBodyRule>

...

...

</rewriteManagement>

 

 

Also in this case the initial parameters are identical in paragraph <rewriteHeaderRule> and provide an Identification rule through a symbolic name declared on the parameter “name”, an indication of the data flow that it wants to intercept, parameter “flow” and basic conditions such as the HTTP method used in the request or the response queues in the response from the service to arrive at our example with these parameters:

<rewriteManagement>

<rewriteHeaderRule name="fromHttpsToHttp302">

</rewriteHeaderRule>

<rewriteHeaderRule name="fromHttpsToHttp301">

</rewriteHeaderRule>

...

...

<rewriteBodyRule flow="response" name=changeColor"""

   HttpMethod="get"

   ResponseCode="200">

</rewriteBodyRule>

<rewriteBodyRule flow="response" name=tcoprojectDevToRelative"">

</rewriteBodyRule>

...

...

</rewriteManagement>

 

 

The name indicates deliberately the action you want to take in the first rule you want to change the color of an item within a css known while in the second we want to generally transported from absolute hyperlink to hyperlink relating a body which is delivered by a service placed in the backend.

We will begin with the first rule of rewriting to identify the name of the css resource which is the depositary of the datum of color. Identified in the “Styles.css” we can go to settle our rule with this condition:

...

<rewriteBodyRule flow="response" name=changeColor""

   HttpMethod="get"

   ResponseCode="200">

<requestURLMatches>styles.css</requestURLMatches>

</rewriteBodyRule>

...

 

Paragraph <requestURLMatches> is a facilitator of condition. Check with a regular expression if the value is checked within the URL. In this case within the URL must be present the resource “styles.css“.

Once you have identified the resource we have to educate the rewriter mime type type associated.

...

<rewriteBodyRule flow="response" name=changeColor""

   HttpMethod="get"

   ResponseCode="200">

<requestURLMatches>styles.css</requestURLMatches>

<mimeType enable= "true" value="text/css fragmentClose "="} fragmentOpen "="{"/>

</rewriteBodyRule>

...

 

This association in the case of the rewriting of the body is not optional because under the mime type identifies the blocks of rewriting consistent through the parameter¬†fragmentClose¬†and ¬†fragmentOpen.¬†It is important to establish the block consisting of change because the “frammentatore” of the Rewriter of body will make available to regular expressions described on the XML file or to esetensione java class only editable portions and consistent from a logical point of view.

If we take for example the resource described above its original content could be the following:

/* Lines of inclusion title and the bottom of the page */td.EncloserLine {

Height: 2px; 

Background-color: rgb(51, 51, 255);}/* Table of Contents */table.ContentTable {text-align: left; width: 100%;}/* Paragraph Title */td.ParagraphTitle {

Text-align: left;

Color: black;

Font-weight: bold; 

Font-style: italic;

Background-color: rgb(255, 143, 89);}


/* The body of the paragraph */td.ParagraphBody {

Text-align: left;}

 

It is clear that if it is desired to modify values inside the curly braces the only possibility is to make available buffers that always contain a block that breaks into two content between these brackets during the transfer. In so doing and wishing to modify the value 255 in 100 you will never submit the following situation with a first buffer valued at:

/* Lines of inclusion title and the bottom of the page */td.EncloserLine {

Height: 2px; 

Background-color: rgb(51, 51, 25);}

 

 

And a second buffer with the remaining content.

/* Table of Contents */table.ContentTable {text-align: left; width: 100%;}/* Paragraph Title */td.ParagraphTitle { Text-align: left;

Color: black;

Font-weight: bold; 

Font-style: italic;

Background-color: rgb(255, 143, 89);}
/* The body of the paragraph */td.ParagraphBody {

Text-align: left;}

 

The block consisting in this case could also be identified in parentheses round, in fact the value that you want to edit is always comprised in a block consisting enclosed by round parenthesis.

It was left ample freedom to choose the definition of block consisting precisely in order to be able to adapt to the best of his rule. Obviously the best practices indicate as block consisting for¬†HTML¬†and¬†XML¬†angle brackets, “<” “>”, for css braces, “{” “}”, for parameters within a body produced by a HTTP form (application/x-www-form-urlencoded) the “&” which divide the parameters with their name=value;

In the case of css and then we’ll set a mime type to type “text/css” with braces and for rewriting hipelink from absolute to relative we will denote a mime type of the type “text/html” with angle brackets. Being the brackets a reserved keyword of XML you must enter in their stead¬†fragmentClose=”&gt;” and¬†fragmentOpen=”&lt;” (see XML manual for other definitions).

Our rules then assume this aspect:

<rewriteManagement>

...

<rewriteBodyRule flow="response" name=changeColor"""

   HttpMethod="get"

   ResponseCode="200">

<requestURLMatches>styles.css</requestURLMatches>

<mimeType enable= "true" value="text/css fragmentClose "="} fragmentOpen "="{"/>

</rewriteBodyRule>

<rewriteBodyRule flow="response" name=tcoprojectDevToRelative"">

<requestURLMatches>/TESTRewrite.html</requestURLMatches>

<mimeType enable= "true" value="text/html" fragmentClose="&gt; fragmentOpen "="&Lt;"/>

</rewriteBodyRule>

...

</rewriteManagement>

 

At this point if the conditions “facilitated” enough to verify the applicability of the rule is sufficient to apply the rule of rewriting by adding it with paragraphs¬†<regexTag>¬†and¬†<replaceTo>¬†respectively on the¬†changeColor rule¬†and¬†tcoprojectDevToRelative.

<rewriteManagement>

...

<rewriteBodyRule flow="response" name=changeColor"""

   HttpMethod="get"

   ResponseCode="200">

<requestURLMatches>styles.css</requestURLMatches>

<mimeType enable= "true" value="text/css fragmentClose "="} fragmentOpen "="{"/>

<regexTag>255</regexTag>

<replaceTo>100</replaceTo>

</rewriteBodyRule>

<rewriteBodyRule flow="response" name=tcoprojectDevToRelative"">

<requestURLMatches>/TESTRewrite.html</requestURLMatches>

<mimeType enable= "true" value="text/html" fragmentClose="&gt; fragmentOpen "="&Lt;"/>

<regexTag>(href|src)=\"(http|https)://www.tcoproject.dev/</regexTag>

<replaceTo>$1=\"</replaceTo>

</rewriteBodyRule>

...

</rewriteManagement>

 

While the first regular expression is quite intuitive, even if not obvious as this rule change all the values 255 encountered with 100 can cause changes of inappropriate, the second appears quite articulated. Of course please refer to the documentation of the regular expressions, very consisting in the Internet, but we will try to give a quick explanation:

The regular expression

(href|src)=\"(http|https)://www.tcoproject.dev/

indicates:

For ugualianze strings:

href=”Http://www.tcoproject.dev/

Or

src=”Http://www.tcoproject.dev/

Or

href=”Https://www.tcoproject.dev/

Or

src=”Https://www.tcoproject.dev/

Alter with the result of the first set through the expression

$1=\”

This expression indicates with $1 the result of the contents of the first set (href|src) and then adds the constants =”.

The final result will change any value

From

¬† ¬†Href=”Http://www.tcoproject.dev/training

In

¬† ¬†Href=”/training

Below another example of changing the body that changes all words encountered with “WARNING” uppercase and the change in the “attention”:

<rewriteBodyRule enable= "true" flow="response" name="translate caseSensitive "= "true">

<mimeType enable= "true" value="text/html" fragmentClose="&gt; fragmentOpen "="&Lt;"/>

 <conditions operator="and">

<cond from=INNERVAR"" name="REQUEST_HTTP_URL">

<regexTag>^/viewLogFile.html</regexTag>

</cond>

</conditions>

<regexTag>WARNING</regexTag>

<replaceTo>ATTENTION</replaceTo>

</rewriteBodyRule>

 

The result of this operation can be appreciated by using all the rules views up to this moment, including the rules of rewriting of the headers to pass from a service that communicates in HTTPS (SSL) to a client that communicates through HTTP:

Not passing through the rewriter…

Passing through the rewriter

HTTP BODY Rewriting with variables

As in the HEADER also in the body may be used variables to compose new values to be used in the content changes.

With the same rules as those applied on regular expressions related to body, below is an example of minimum that uses the variables:

<rewriteBodyRule enable= "true" flow="response" name="LBL caseSensitive "= "false">

<mimeType enable= "true" value="text/html" fragmentClose="&gt; fragmentOpen "="&Lt;"/>

<variables>

  <var varName="MY_Var_FROM_THIS_VALUE" name="LBL the best! " From="CONSTANT">

  </var>

</variables>

<regexTag>LBL\(r\)</regexTag>

<replaceTo>%MY_Var_FROM_THIS_VALUE %</replaceTo>

</rewriteBodyRule>

 

HTTP BODY Rewriting with extended Java classes

Even with the functionality of the rewriting of the body it is possible to simultaneously use the rewriting through rules described on the XML file and associate an extension of a Java class specially made available from the library using the following methods:

1-doRequestBodyBeforeReplace

2-doRequestBodyAfterReplace

3-doResponseBodyBeforeReplace

4-doResponseAfterAfterReplace

Also in this case the class puts at the disposal of the methods the fragments consisting of body where it is possible to intervene bit by bit with changes or checks of content.

Package loadbalancer.rewriter;

import loadbalancer.rewriter.LBLHTTPInterceptorBodyAbstr;

import loadbalancer.rewriter.LBLHTTPInterceptorBodyStreamFragment;/**

 * Test class BODY HTTP interceptors for dynamic change during stream...

 * @version 1.0 created on 5-Jun-2010

 */

public class extends LBLHTTPRewriteInterceptorBodyLogging LBLHTTPInterceptorBodyAbstr {

/** Copyright */

Public static final String COPYRIGHT="LBL and TCOProject are trademarks all rights reserved";

/**

 * The method invoked to client request before making changes to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doRequestBodyBeforeReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("REQUEST BODY BEFORE REPLACE\n"+streamFragment.getStreamFragment());

For (String varName: streamFragment.getVariables())

LogWarning("RQBR BODY VarName:"+varName+" value:"+streamFragment.getVariable(varName));

}

/**

 * The method invoked to client request after changes have been made to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doRequestBodyAfterReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("REQUEST BODY AFTER REPLACE\n"+streamFragment.getStreamFragment());

}

/**

 * The invoked method to the response of the service before making any changes to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doResponseBodyBeforeReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("RESPONSE BODY BEFORE REPLACE\n"+streamFragment.getStreamFragment());

For (String varName: streamFragment.getVariables())

LogWarning("REBR BODY VarName:"+varName+" value:"+streamFragment.getVariable(varName));

}

/**

 * The invoked method to the response of the service after changes have been made to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doResponseBodyAfterReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("RESPONSE BODY AFTER REPLACE\n"+streamFragment.getStreamFragment());

}

}

 

Unlike the header body from a point of view purely technological data stream will be passed to “blocks” consistent and not for entire contents. This will be completely transparent to the one who is preparing to write the rule of rewriting and will be fully automated from rewriter while maintaining consistent fragment through the characters described in¬†fragmentOpen¬†fragmentClose and.

On the body have been made available different methods of interaction with the fragment, some are common others are typical of course for the treatment of body. Perhaps one of the most interesting is the interaction with the values contained in a body and supplied from a HTML form.

Package testrewrite;

import loadbalancer.rewriter.LBLHTTPInterceptorBodyAbstr;

import loadbalancer.rewriter.LBLHTTPInterceptorBodyStreamFragment;/**

 * Test class HTTP interceptors for dynamic change during stream...

 * @version 1.0 created on 20-May-2010

 */

public class extends HTTPRewriteInterceptorBodyAddParam LBLHTTPInterceptorBodyAbstr {

/** Copyright */

Public static final String COPYRIGHT="LBL and TCOProject are trademarks all rights reserved";

/**

 * The method invoked to client request before making changes to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doRequestBodyBeforeReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

   LogDebug("REQUEST BEFORE REPLACE\n"+streamFragment.getStreamFragment());

   // Insertion of a new parameter in the body!!!!

   StreamFragment.addParameterInTheBody("COPYRIGHT", "LBL and TCOProject are trademarks all rights reserved");

}

/**

 * The method invoked to client request after changes have been made to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doRequestBodyAfterReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

  LogDebug("REQUEST AFTER REPLACE\n"+streamFragment.getStreamFragment());

}

/**

 * The invoked method to the response of the service before making any changes to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doResponseBodyBeforeReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

  LogDebug("RESPONSE BEFORE REPLACE\n"+streamFragment.getStreamFragment());

}

/**

 * The invoked method to the response of the service after changes have been made to the work of regular expressions

 * @Param streamFragment fragment consisting of the body (HTML/CSS/JS etc)

 */

@Override

Public void doResponseBodyAfterReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

  LogDebug("RESPONSE AFTER REPLACE\n"+streamFragment.getStreamFragment());

}}

 

The XML rule to enter for each HTTP POST the new parameter will be:

<rewriteBodyRule enable= "true" flow="REQUEST" name="addTrademarkParam caseSensitive "= "false"

HttpMethod="POST"

HttpInterceptorClass=testrewrite".HTTPRewriteInterceptorBodyAddParam">

<mimeType enable= "true"

   Value="application/x-www-form-urlencoded fragmentClose "="&AMP; fragmentOpen "="&AMP;"/>

</rewriteBodyRule>

 

In this case the action of rewriting will be entirely carried out by the extension of the java class and the result will be an addition of a parameter to the form existing HTML:

39|20100607-09:40:53|A HTTP Method=POST||

54|20100607-09:40:53|A HTTP URL request/papaia/ServletSession||

54|20100607-09:40:53|A Parameter Service name=null||

54|20100607-09:40:53|A Request address=127.0.0.1||

54|20100607-09:40:53|A Response address=127.0.0.1||

54|20100607-09:40:53|A Paramname=applicationId value=9EFCE61F5A8582BAE219CB720FCE33CE-PapaiaLoaderId-6781414||

54|20100607-09:40:53|A Paramname=jprogram value=asstec.programs.JTUSecond||

54|20100607-09:40:53|A Paramname=TransactionButton.Trash value=Cancella||

54|20100607-09:40:53|A Paramname=area1.cod_cli value=Mango||

54|20100607-09:40:53|A Paramname=area1.data_nascita value=01/01/1964||

54|20100607-09:40:53|A Paramname=area1.address value=Via estate, 2010||

54|20100607-09:40:53|A Paramname=area1.nota value=Test||

54|20100607-09:40:53|A Paramname=COPYRIGHT value=LBL and TCOProject are trademarks all rights reserved||

70|20100607-09:40:53|B 11||

70|20100607-09:40:53|B POST||

70|20100607-09:40:53|B /papaia/ServletSession||

70|20100607-09:40:53|B Paramname=applicationId value=9EFCE61F5A8582BAE219CB720FCE33CE-PapaiaLoaderId-6781414||

70|20100607-09:40:53|B Paramname=jprogram value=asstec.programs.JTUSecond||

70|20100607-09:40:53|B Paramname=TransactionButton.Trash value=Cancella||

70|20100607-09:40:53|B Paramname=area1.cod_cli value=Papaia||

70|20100607-09:40:53|B Paramname=area1.data_nascita value=01/01/1964||

85|20100607-09:40:53|B Paramname=area1.address value=Via SnowBoard, 2010||

85|20100607-09:40:53|B Paramname=area1.nota value=Biancaneve||

85|20100607-09:40:53|B Paramname=COPYRIGHT value=LBL and TCOProject are trademarks all rights reserved||

85|20100607-09:40:53|LBLSESSIONID>>>>1276185123144||

85|20100607-09:40:53|TCOPROJECTAUTH>>>>null||

 

ATTENTION:

Some application server does not support the POST method with “transfer-encoding chunked:”. For example Apache Tomcat has solved this problem definitely from version 6.0.26 with lower versions (e.g.:6.0.14) does not work. Make sure that the application server is compliant to the recommendation HTTP1.1 transfer-encoding chunked:

Create Java extended class HTTP interceptors

To create and compile an extension of the java class in basic form is sufficient:

1- go to directory: (LBL_HOME\interceptors\rewriteclasses

2- Create a class as reported in example:

Package rewriteclasses

import loadbalancer.rewriter.LBLHTTPInterceptorBodyAbstr;

import loadbalancer.rewriter.LBLHTTPInterceptorBodyStreamFragment;

public class  extends HTTPRewriteBody LBLHTTPInterceptorBodyAbstr {

@Override

Public void doRequestBodyBeforeReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("REQUEST ADDPARAM BEFORE REPLACE\n"+

   New String(streamFragment.getStreamFragment()));

}

@Override

Public void doRequestBodyAfterReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("REQUEST ADDPARAM AFTER REPLACE\n"+

   New String(streamFragment.getStreamFragment()));

}

@Override

Public void doResponseBodyBeforeReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("ADDPARAM RESPONSE BEFORE REPLACE\n"+

   New String(streamFragment.getStreamFragment()));

}

@Override

Public void doResponseBodyAfterReplace(LBLHTTPInterceptorBodyStreamFragment streamFragment) {

LogWarning("ADDPARAM RESPONSE AFTER REPLACE\n"+

   New String(streamFragment.getStreamFragment()));

}}

 

4- compile the program using a small batch file to make the operation easier

With the parameters contextualized in your environment (example of batch file):

@OFFSET ECHO PATH=

C:\work1\bin\Java\jdk1.6.0_11\bin;%PATH%

SET CLASSPATH=.;C:\work1\bin\LBLLoadBalancer\LBLLoadBalancer_enterprise_007_001_000\lib\LBLLoadBalancer.jarJAVAC

 %*

#|/bin/shPATH=

/work1/bin/java/jdk1.6.0_11/bin:$PATHexport PATH

CLASSPATH=.:/work1/bin/LBLLoadBalancer/LBLLoadBalancer_enterprise_007_001_000/lib/LBLLoadBalancer.jarexport CLASSPATHjavac $@

 

With one of the two batch files to perform for example: compiles.bat HTTPRewriteBody.java

5- Create a rule that provides the program you just created:

<rewriteBodyRule flow="BOTH" name=myBodyTest""

   HttpInterceptorClass=testrewrite".HTTPRewriteBody">

</rewriteBodyRule>

 

6- Declare what services apply the rule:

 

<endpoints>

  <endPointsGrouping enable= "true">

  <virtualDomain virtualDomainName="www.tcoproject.dev"

     RewriteHeaderRules=""

     RewriteBodyRules="translate myBodyTest">

    <endp address=legendonebackend"" port=8181"" uriPath="/papaya"/>

    <endp address=legendonebackend"" port=8181"" uriPath="/prvSevletEcho"/>

    <endp address=legendonebackend"" port=8181"" uriPath="/training"/>

    <endp address=legendonebackend"" port=8181"" uriPath="/trainingw"/>

    <endp address=legendonebackend"" port="8282 uriPath "="/papaya"/>

  ...

  ...

  ...

 

Or:

 <endpoints>

  <endPointsGrouping enable= "true">

  <virtualDomain virtualDomainName="www.tcoproject.dev"

     RewriteHeaderRules=""

     RewriteBodyRules="translate">

    <endp address=legendonebackend"" port=8181"" uriPath="/papaya"/>

    <endp address=legendonebackend"" port=8181"" uriPath="/prvSevletEcho"/>

    <endp address=legendonebackend"" port=8181"" uriPath="/training"

RewriteBodyRules=myBodyTest""/>

    <endp address=legendonebackend"" port=8181"" uriPath="/trainingw"/>

    <endp address=legendonebackend"" port="8282 uriPath "="/papaya"/>

   ...

  ...

...

 

7- Stop and start the service in order to acquire a new parameter.

Create Java extended class TCP Interceptor

How to use the classes of rewriting in the streams Layer 4 TCP put at the disposal of the implementer a powerful tool able to check and/or change the values that cross the road routing and balancing. The classes of rewriting also make it possible to carry out the considerations on the contents and route in a coherent manner the information.

The principle on which is based the implementation the classes of rewriting Layer 4 TCP is very simple. The declaration of the listener is possible to indicate a class of rewriting that will intercept the priming coming from the client and then the stream full duplex. Below is a sample listener that you can find in the template provided in the distribution in the directory: (LBL_HOME)/interceptors/rewriteclasses/LBLTCPRewriteInterceptorLogging.java.

<!-- RDP with session affinity -->

< listenType bind="NAT"

  Address="localhost" port="4389"

  OsiLayer="4"

  Protocol="RDP-session-affinity"

  EndPointsGrouping="RDP-service"

  Transport="tcp"

  TransportSessionAffinity= "true"

  DistinguishSingleConnection= "true"

  TcpInterceptorClassPath=interceptors"/"

  TcpInterceptorClass=rewriteclasses".LBLTCPRewriteInterceptorLogging"

  Enable= "true"/>

 

The parameters:

TcpInterceptorClassPath=interceptors”/”

TcpInterceptorClass=rewriteclasses”.LBLTCPRewriteInterceptorLogging”

Indicate the class that will be used in the rewriting.

The classes of rewriting extend the abstract class with 6 Methods of flow control:

Loadbalancer.rewriter.LBLTCPRewriteInterceptorAbstr@Overridepublic interceptorInit void(String processHomePath, String address, int port) {}@Overridepublic interceptorEnd void(String processHomePath, String address, int port) {}

@Override

public void interceptorInit(String processHomePath, String address, int port) {

}

@Override

public void interceptorEnd(String processHomePath, String address, int port) {

}

@Override

public boolean doPrimerFromClient(LBLTCPRewriteInterceptorFragment tcpFragment) {

return true;

}

@Override

public boolean doPacketFromClient(LBLTCPRewriteInterceptorFragment tcpFragment) {

return true;

}

@Override

public boolean doPacketFromEndpoint(LBLTCPRewriteInterceptorFragment tcpFragment) {

return true;

}

@Override

public boolean doPrimerFromEndpoint(LBLTCPRewriteInterceptorFragment tcpFragment) {

return true;

}

 

The first method is called after the first primer of the client that takes the request, the second method is called for every packet that passes from the client to the endpoint and the third method is called for every packet that passes from the endpoint toward the client. NOTE: The two methods doPacketFromClient doPacketFromEndpoint and can also be used at the same time as the flow is full-duplex.

The first primer (doPrimerFromClient), in dependence of the Protocol, it is possible to exclude the reading of the first packet coming from the client through the parameter¬†tcpInterceptorPrimerCapture=”false”.¬†This feature must be disabled in all cases in which it is executing the rewriting of protocols that do not provide a primer on the part of the client (es.: telnet). The¬†tcpInterceptorPrimerCapture parameter¬† has no effect if it is not explicitly used a class of rewriting TCP.

LBLTCPRewriteInterceptorFragment tcpFragment

The Fragment past in methods call-back allows you to access different features of control and change of flow. The following is a list of some of the functions made available:

/**

 * Buffer getter stream

 * @Return stream buffer or null if error

 */

Public byte[] getStream()

/**

 * Set a new stream buffer

 * @Param newBufferStream

 * @Throws IOException

 */

Public void setStream(byte[] newBufferStream) throws IOException

/**

 * Return client host address

 * @Return client host address or null if not found

 */

Public String getRequestClientAddress()

/**

 * Return incoming host address

 * @Return incoming host address or null if not found

 */

Public String getRequestIncomingAddress()

/**

 * Return incoming socket

 * @Return incoming socket or null if not found

 */

Public getRequestIncomingSocket Socket()

/**

 * Return incoming SSLSocket or null if not found or not SSL Socket

 * @Return incoming SSLSocket or null if not found or not SSL Socket

 */

Public SSLSocket getRequestIncomingSSLSocket()

/**

 * SSL Session socket connected to the incoming

 * @Return SSL session connected to the incoming socket,

 * Or null if no SSL or non-existent socket

 */

Public SSLSession getRequestIncomingSSLSession()

/**

 * Peer certificates connected to the incoming socket

 * @Return Peer certificates connected to the incoming socket,

 * Or null if no SSL or non-existent socket

 */

Public java.security.cert.Certified[] getRequestIncomingSSLCertificates()

/**

 * Return incoming host name or address

 * @Return incoming host host name or address or null if not found

 */

Public String getRequestIncomingHostName()

/**

 * Ssl client connection

 * @Return true if ssl client connection

 */

Public String isSSLClientConnection()

/**

 * Return endpoint socket

 * @Return endpoint socket or null if not found

 */

Public getResponseEndpointSocket Socket()

/**

 * Return SSLSocket endpoint or null if not found or not SSL Socket

 * @Return SSLSocket endpoint or null if not found or not SSL Socket

 */

Public SSLSocket getResponseEndpointSSLSocket()

/**

 * SSL session connected to the incoming socket endpoint

 * @Return SSL session endpoints connected to the socket,

 * Or null if the incoming non-SSL sockets or nonexistent

 */

Public SSLSession getResponseEndpointSSLSession()

/**

* Peer certificates connected to the socket endpoint

* @Return Peer certificates connected to the socket endpoint,

* Or null if no SSL or non-existent socket

*/

Public java.security.cert.Certified[] getResponseEndpointSSLCertificates()

/**

* Return host endpoint address

* @Return host endpoint address or null if not found

*/

Public String getResponseEndpointAddress()

/**

* Ssl endpoint connection

* @Return true if SSL endpoint connection

*/

Public String isSSLEndpointConnection()

/**

* Reencryption ssl

* @Return true if in reencryption ssl

*/

Public String isSSLReencryptionConnection()

 

Create Java extended class UDP Interceptor

The use of classes of rewriting in the forwarding of UDP packets is possible by setting in the listener the reference to the class of rewriting that you intend to use.

The mode is similar to the rewriting TCP and the setting of the class in the file parameters occurs in the following manner. The class set in the example is included in the distribution in source mode in the directory:

(LBL_HOME)/interceptors/rewriteclasses/LBLUDPRewriteInterceptorLogging

<bind enable= "true"

DoubleIncomingQueues= "false"

ListenType="NAT"

Description="First FWD"

Address="localhost"

Port=8888-8889""

OsiLayer="4"

Protocol= "UDP"

EndPointsGrouping="udp-forward-group"

TransportSessionAffinity= "true"

Transport= "UDP"

UdpInterceptorClass=rewriteclasses" .LBLUDPRewriteInterceptorLogging"/>

Even with the UDP it is possible to set the affinity of the session, as by example.

The classes of rewriting UDP extend the class with the following methods to implement:

Loadbalancer.rewriter.LBLUDPRewriteInterceptorAbstr@Overridepublic interceptorInit void(String processHomePath, String address, int port) {}@Overridepublic interceptorEnd void(String processHomePath, String address, int port) {}

@Override

public void interceptorInit(String processHomePath, String address, int port) {

}

@Override

public void interceptorEnd(String processHomePath, String address, int port) {

}

@Override

public void doAfterReceivedUDPPacketFromClient(LBLUDPRewriteInterceptorFragment udpFragment) {

}

@Override

public void doAfterReceivedUDPPacketFromEndpoint(LBLUDPRewriteInterceptorFragment udpFragment) {

}

 

From the object that is passed as a parameter of the functions it is possible to inspect and vary both packets that transit both vary their destination.

The following are some of the methods provided by the object that is passed during the crossing of the package.

/**

* Input buffer. This is not a copy of the buffer.

* Remind to setPacketLength after used the array.

* @Return input buffer

*/

Public byte[] getPacketByteArray()

/**

* Write pointer of the array

* @Return write pointer of the array

*/

Public getPacketLength int()

/**

* Set a write pointer of the array

* @Param wp write pointer

*/

Public void setPacketLength(int wp)

/**

* Endpoint Address before rewriting

* @Return the endpointAddress

*/

Public InetAddress getEndPointAddress()

/**

* Endpoint Address before rewriting

* @Param endPointAddress endpointAddress tea to set

*/

Public void setEndPointAddress(InetAddress endPointAddress)

/**

* Return to local incoming port

* @Return local incoming port

*/

Public getLocalIncomingPort int()

/**

* Return to local incoming Inet Address

* @Return local incoming Inet Address

*/

Public InetAddress getLocalIncomingInetAddress()

/**

* Return the inet host address of the client that sent the packet

* @Returnhost inet address of the client that sent the packet

*/

Public InetAddress getClientHostAddress()

 

LBL ADC: Development of integrated rules



Through the graphical interface HTML 5 it is possible to manage the entire development cycle of the Advanced Rules. From graphical interface it is possible to perform the editing, compilation, the import and export of the code while maintaining consistency in the case of installations in the cluster across multiple nodes.

LBL VAPP Developer: Development of integrated rules

For an advanced development of rules is available free download of a virtual environment that allows to develop and test rules of rewriting before applying them in production.

The system is designed for enterprise environments and can be configured to support certification processes of the rules developed up to the creation of environments of software versioning, test, internships, and release.

With LBL Developer you can centralise policies for security systems, SSO, Third-Party Integrations easily verifiable, step by step, reproducible and vision.

ENABLE REWRITING TRACE

Enabling the trace of the functionality of rewriting is possible through two definitions at the start of the JVM.

It is possible to only track events, such as the loading of the variables and the verification of the conditions, or perform also the trace of the changes made.

To activate the two trace it is possible to use the following definitions to start:

– DLBL_DEBUG_rewriting (enables the trace of the rewriting during tests of

Conditions and the loading of the variables)

– DLBL_DEBUG_ROW_rewriting (enables the trace of the rewriting of the fragments of

Stream before and after the changes

Attention: this flag if enabled

Performs a log very bulky,

Enable in the debug phase of rules)

To be able to activate it is necessary during the launch phase to set the process in debug with the definition -DDEBUG=true perform e.g.:

Java -server …. -DDEBUG=true – DLBL_DEBUG_REWRITING=true – DLBL_DEBUG_ROW_REWRITING=true

Conclusion

The functionality of rewriting implemented in LBL ADC are among the most complete for a professional market. This document, together with the document LBL ADC  Reference Guide, give an idea of the power applicable in different contexts and situations while maintaining control and self-documenting what developed through the refined expressiveness of the paradigm XML or of the Java language.