NetScaler ingress controller

Use Rewrite and Responder policies in Kubernetes

In a Kubernetes environment, to deploy specific layer 7 policies to handle scenarios such as:

Redirecting HTTP traffic to a specific URL
Blocking a set of IP addresses to mitigate DDoS attacks
Imposing HTTP to HTTPS

Requires you to add appropriate libraries within the microservices and manually configure the policies. Instead, you can use the Rewrite and Responder features provided by the Ingress NetScaler device to deploy these policies.

NetScaler provides Kubernetes CustomResourceDefinitions (CRDs) that you can use with the NetScaler Ingress Controller to automate the configurations and deployment of these policies on the NetScalers used as Ingress devices.

The Rewrite and Responder CRD provided by NetScaler is designed to expose a set of tools used in front-line NetScalers. Using these functionalities you can rewrite the header and payload of ingress and egress HTTP traffic as well as respond to HTTP traffic on behalf of a microservice.

Once you deploy the Rewrite and Responder CRD in the Kubernetes cluster. You can define extensive rewrite and responder policies using datasets, pat sets, and string maps and also enable audit logs for statistics on the ingress device. For more information on the rewrite and responder policy feature provided by NetScaler ADC, see Rewrite policy and Responder policy.

Note:

The Rewrite and Responder CRD is not supported for OpenShift routes. You can use OpenShift ingress to use Rewrite and Responder CRD.

Deploy the NetScaler Rewrite and Responder CRD

The NetScaler Rewrite and Responder CRD deployment YAML file: rewrite-responder-policies-deployment.yaml.

Note:

Ensure that you do not modify the deployment YAML file.

Deploy the CRD, using the following command:

kubectl create -f rewrite-responder-policies-deployment.yaml

For example,

root@master:~# kubectl create -f rewrite-responder-policies-deployment.yaml
customresourcedefinition.apiextensions.k8s.io/rewritepolicies.citrix.com created

Rewrite and Responder CRD attributes

The CRD provides attributes for the various options required to define the rewrite and responder policies. Also, it provides attributes for dataset, pat set, string map, and audit logs to use within the rewrite and responder policies. These CRD attributes correspond to NetScaler command and attribute respectively.

Rewrite policy

The following table lists the CRD attributes that you can use to define a rewrite policy. Also, the table lists the corresponding NetScaler command and attributes.

CRD attribute	NetScaler command	NetScaler attribute
rewrite-criteria	Add rewrite policy	rule
default-action	Add rewrite policy	undefAction
operation	Add rewrite action	type
target	Add rewrite action	target
modify-expression	Add rewrite action	stringBuilderExpr
multiple-occurence-modify	Add rewrite action	Search
additional-multiple-occurence-modify	Add rewrite action	RefineSearch
Direction	Bind lb vserver	Type

Responder policy

The following table lists the CRD attributes that you can use to define a responder policy. Also, the table lists the corresponding NetScaler command and attributes.

CRD attribute	NetScaler command	NetScaler attribute
Redirect	Add responder action	Type (the value of type)
url	Add responder action	Target
redirect-status-code	Add responder action	responseStatusCode
redirect-reason	Add responder action	reasonPhrase
Respond-with	Add responder action	Type (the value of type)
http-payload-string	Add responder action	Target
Noop	Add responder policy	Action (the value of action)
Reset	Add responder policy	Action (the value of action)
Drop	Add responder policy	Action (the value of action)
Respond-criteria	Add responder policy	Rule
Default-action	Add responder policy	undefAction

Audit log

The following table lists the CRD attributes provide to enable audit log within the rewrite or responder policies. Also, the table lists the corresponding NetScaler command and attributes.

CRD attribute	NetScaler command	NetScaler attribute
Logexpression	Add audit message action	stringBuilderExpr
Loglevel	Add audit message action	Loglevel

Dataset

The following table lists the CRD attributes for dataset that you can use within the rewrite or responder policies. Also, the table lists the corresponding NetScaler command and attributes.

CRD attribute	NetScaler command	NetScaler attribute
Name	Add policy dataset	Name
Type	Add policy dataset	Type
Values	Bind policy dataset	Value

Patset

CRD attribute	NetScaler command	NetScaler attribute
Name	Add policy patset	Name
Values	Bind policy patset	string

String map

CRD attribute	NetScaler command	NetScaler attribute
Name	Add policy stringmap	Name
Key	Bind policy stringmap	Key
Value	Bind policy stringmap	Value

Goto-priority-expression

The following table provides information about the goto-priority-expression attribute, which is a CRD attribute for binding a group of multiple consecutive policies to services.

CRD attribute	NetScaler command	NetScaler attribute	Supported values	Default value
goto-priroty-expression	Bind lb vserver	gotoPriorityExpression	NEXT and END	End

For more information on how to use the goto-priority-expression attribute, see the example Modify strings and host name in the requested URL

How to write a policy configuration

After you have deployed the CRD provided by NetScaler in the Kubernetes cluster, you can define the policy configuration in a.yaml file. In the .yaml file, use rewritepolicy in the kind field and based on your requirement add any of the following individual sections in spec for policy configuration.

rewrite-policy - To define rewrite policy configuration.
responder-policy - To define responder policy configuration.
logpackets - To enable audit logs.
dataset - To use a data set for extensive policy configuration.
patset - To use a pat set for extensive policy configuration.
stringmaps - To use string maps for extensive policy configuration.

In these sections, you need to use the CRD attributes provided for the respective policy configuration (rewrite or responder) to define the policy.

Also, in the spec section, you need to include a rewrite-policies section to specify the service or services to which the policy must be applied. For more information, see Sample policy configurations.

After you deploy the .yaml file, the NetScaler Ingress Controller applies the policy configuration on the Ingress NetScaler device.

Guidelines for the policy configuration

If the CRD is associated with a namespace then, by default, the policy is applied to the services associated with the namespace. For example, if you have the same service name associated with multiple namespaces, then the policy is applied to the service that belongs to the namespace associated with the CRD.
If you have defined multiple policies in a single .yaml file then the first policy configuration defined in the file takes priority and the subsequent policy configurations is applied as per the sequence. If you have multiple policies defined in different files then the first policy configuration defined in the file that you deployed first takes priority.

Guidelines for the usage of Goto-priority-expression

The rewrite and responder policies can be combined as multiple groups using the NEXT keyword within the goto-priority-expression field.
When the goto-priority-expression field is NEXT within the current policy and if the current policy evaluates to True, the next policy in the group is executed and the flow moves to the next consecutive policies unless the goto-priority-expression field points to END.
When the current policy evaluates to FALSE, the goto-priority-expression has no impact, as the policy execution stops at the current policy.
The rewrite or responder policy group within the rewrite or responder policies begins with the policy assigned with goto-priority-expression as NEXT and includes all the consecutive policies until the goto-priority-expression field is assigned to END.
When you group rewrite or responder policies using goto-priority-expression, the service names bound to the policies within the group should be the same.
The last policy within the rewrite-policies or responder-policies should always have the goto-priority-expression as END.
If the goto-priority-expression field is not specified for a policy, the default value of END is assigned to goto-priority-expression.

Note:

For more information on how to use the goto-priority-expression field, see the example Modify strings and host name in the requested URL.

Create and verify a rewrite and responder policy

Consider a scenario where you want to define a policy in NetScaler to rewrite all the incoming URLs to new-url-for-the-application and send it to the microservices. Create a .yaml file called target-url-rewrite.yaml and use the appropriate CRD attributes to define the rewrite policy as follows:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: targeturlrewrite
spec:
  rewrite-policies:
    - servicenames:
        - citrix-svc
      logpackets:
        logexpression: "http.req.url"
        loglevel: INFORMATIONAL
      rewrite-policy:
        operation: replace
        target: 'http.req.url'
        modify-expression: '"new-url-for-the-application"'
        comment: 'Target URL Rewrite - rewrite the url of the HTTP request'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid'
<!--NeedCopy-->

After you have defined the policy configuration, deploy the .yaml file using the following command:

kubectl create -f target-url-rewrite.yaml

After you deploy the .yaml file, the NetScaler Ingress Controller applies the policy configuration on the Ingress NetScaler device.

On the master node in the Kubernetes cluster, you can verify the status of the applied rewrite policy CRD using the following command:

Kubectl get rewritepolicies.citrix.com targeturlrewrite

You can view the status as follows:

kubectl get rewritepolicies.citrix.com targeturlrewrite 
NAME               STATUS    MESSAGE
targeturlrewrite   Success   CRD Activated

If there are issues while creating or applying the CRD, the same can be debugged using the citrix-k8s-ingress-controller logs.

kubectl logs citrixingresscontroller

Also, you can verify whether the configuration is applied on the NetScaler by using the following steps.

Log on to the NetScaler command-line.

Use the following command to verify if the configuration is applied to the NetScaler:

show run | grep `lb vserver`
add lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc HTTP 0.0.0.0 0 -persistenceType NONE -cltTimeout 180
bind lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc k8s-citrix_default_80_k8s-citrix-svc_default_80_svc
bind lb vserver k8s-citrix_default_80_k8s-citrix-svc_default_80_svc -policyName k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default -priority 100300076 -gotoPriorityExpression END -type REQUEST 

You can verify that the policy k8s_crd_rewritepolicy_rwpolicy_targeturlrewrite_0_default is bound to the load balancing virtual server.

Sample policy configurations

Responder policy configuration

Following is a sample responder policy configuration (block-list-urls.yaml)

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: blocklisturls
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied"'
        respond-criteria: 'http.req.url.equals_any("blocklistUrls")'
        comment: 'Blocklist certain Urls'


  patset:
    - name: blocklistUrls
      values:
        - '/app1'
        - '/app2'
        - '/app3'
<!--NeedCopy-->

In this example, if NetScaler receives any URL that matches the /app1, /app2, or /app3 strings defined in the patset, NetScaler blocks the URL.

Policy with audit logs enabled

Following is a sample policy with audit logs enabled (block-list-urls-audit-log.yaml).

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: blocklisturls
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      logpackets:
        logexpression: "http.req.url"
        loglevel: INFORMATIONAL
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied"'
        respond-criteria: 'http.req.url.equals_any("blocklistUrls")'
        comment: 'Blocklist certain Urls'


  patset:
    - name: blocklistUrls
      values:
        - '/app1'
        - '/app2'
        - '/app3'
<!--NeedCopy-->

Multiple policy configurations

You can add multiple policy configurations in a single .yaml file and apply the policies to the NetScaler device. You need add separate sections for each policy configuration (multi-policy-config.yaml).

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: multipolicy
spec:
  responder-policies:
    - servicenames:
        - citrix-svc
      responder-policy:
        redirect:
          url: '"www.citrix.com"'
        respond-criteria: 'client.ip.src.TYPECAST_text_t.equals_any("redirectIPs")'
        comment: 'Redirect IPs to citrix.com'
    - servicenames:
        - citrix-svc
      responder-policy:
        redirect:
          url: 'HTTP.REQ.HOSTNAME+http.req.url.MAP_STRING_DEFAULT_TO_KEY("modifyurls")'
        respond-criteria: 'http.req.is_valid'
        comment: 'modify specific URLs'

  rewrite-policies:
    - servicenames:
        - citrix-svc
      rewrite-policy:
        operation: insert_http_header
        target: 'sessionID'
        modify-expression: '"48592th42gl24456284536tgt2"'
        comment: 'insert SessionID in header'
        direction: RESPONSE
        rewrite-criteria: 'http.res.is_valid'



  dataset:
    - name: redirectIPs
      type: ipv4
      values:
        - 10.1.1.100
        - 1.1.1.1 - 1.1.1.100
        - 2.2.2.2/10

  stringmap:
    - name: modifyurls
      comment: Urls to be modified string
      values:
        - key: '"/app1/"'
          value: '"/internal-app1/"'
        - key: '"/app2/"'
          value: '"/internal-app2/"'
<!--NeedCopy-->

The example contains two responder policies and a rewrite policy, based on these policies NetScaler performs the following:

Any requests that match the client IP addresses specified in the redirectIPs dataset, that is, 10.1.1.100, IP addresses in the range 1.1.1.1 - 1.1.1.100 and IP addresses in the subnet 2.2.2.2/10, is redirected to www.citrix.com.
Any incoming URL with strings provided in the modifyurls stringmap is modified to the value provided in the stringmap. For example, if the incoming URL has the string /app1/ is modified to /internal-app1/
Adds a session ID as a new header in the response to the client.

Example use cases

Add response headers

When the requested URL from the client contains /citrix-app/, you can add the following headers in the HTTP response from the microservices to the client using a rewrite policy:

Client source port to the header
Server destination IP address
random HTTP header

The following sample rewrite policy definition adds these headers to the HTTP response from the microservices to the client:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
name: addresponseheaders
spec:
rewrite-policies:
  - servicenames:
      - frontend
    rewrite-policy:
      operation: insert_before_all
      target: http.res.full_header
      modify-expression: '"\r\nx-port: "+client.tcp.srcport+"\r\nx-ip:"+client.ip.dst+"\r\nx-new-dummy-header: Sending_a_gift"'
      multiple-occurence-modify: 'text("\r\n\r\n")'
      comment: 'Response header rewrite'
      direction: RESPONSE
      rewrite-criteria: 'http.req.url.contains("/citrix-app/")'
<!--NeedCopy-->

Create a YAML file (add_response_headers.yaml) with the rewrite policy definition and deploy the YAML file using the following command:

kubectl create -f add_response_headers.yaml

You can verify the HTTP header added to the response as follows:

$ curl -vvv http://app.cic-citrix.org/citrix-app/
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET /citrix-app/ HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.8.1
< Date: Fri, 29 Mar 2019 11:14:04 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.14
< x-port: 22481 ==================> NEW RESPONSE HEADER
< x-ip:10.102.33.176 ==================> NEW RESPONSE HEADER
< x-new-dummy-header: Sending_a_gift ==================> NEW RESPONSE HEADER
<
<html>
<head>
<title> Front End App - v1 </title>


TRIMMED
.......

Add custom header to the HTTP response packet

Using a rewrite policy, you can add custom headers in the HTTP response from the microservices to the client.

The following sample rewrite policy definition adds a custom header to the HTTP response from the microservices to the client:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: addcustomheaders
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: insert_before_all
        target: http.res.full_header
        modify-expression: '"\r\nx-request-time:"+sys.time+"\r\nx-using-citrix-ingress-controller: true"'
        multiple-occurence-modify: 'text("\r\n\r\n")'
        comment: 'Adding custom headers'
        direction: RESPONSE
        rewrite-criteria: 'http.req.is_valid'

<!--NeedCopy-->

Create a YAML file (add_custom_headers.yaml) with the rewrite policy definition and deploy the YAML file using the following command:

kubectl create -f add_custom_headers.yaml

You can verify the custom HTTP header added to the response as follows:

$ curl -vvv http://app.cic-citrix.org/
* Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET / HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.8.1
< Date: Fri, 29 Mar 2019 12:15:09 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.14
< x-request-time:Fri, 29 Mar 2019 13:27:40 GMT =============> NEW HEADER ADDED
< x-using-citrix-ingress-controller: true  ===============> NEW HEADER ADDED
<
<html>
<head>
<title> Front End App - v1 </title>
<style>

TRIMMED
........

Replace host name in the request

You can define a rewrite policy as shown in the following example YAML (http_request_modify_prefixasprefix.yaml) to replace the host name in an HTTP request as per your requirement:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httpheadermodifyretainprefix
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace_all
        target: 'http.req.header("host")'
        modify-expression: '"citrix-service-app"'
        multiple-occurence-modify: 'text("app.cic-citrix.org")'
        comment: 'HTTP header rewrite of hostname'
        direction: REQUEST
        rewrite-criteria: 'http.req.is_valid'
<!--NeedCopy-->

Create a YAML file (http_request_modify_prefixasprefix.yaml) with the rewrite policy definition and deploy the YAML file using the following command:

kubectl create -f http_request_modify_prefixasprefix.yaml

You can verify the policy definition using the curl command. The host name in the request is replaced with the defined host name.

curl http://app.cic-citrix.org/prefix/foo/bar

Output: Replace host name

Modify the application root

You can define a rewrite policy to modify the application root if the existing application root is /.

The following sample rewrite policy modifies / to /citrix-approot/ in the request URL:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
 name: httpapprootrequestmodify
spec:
 rewrite-policies:
   - servicenames:
       - frontend
     rewrite-policy:
       operation: replace
       target: http.req.url
       modify-expression: '"/citrix-approot/"'
       comment: 'HTTP app root request modify'
       direction: REQUEST
       rewrite-criteria: http.req.url.eq("/")
<!--NeedCopy-->

Create a YAML file (http_approot_request_modify.yaml) with the rewrite policy definition and deploy the YAML file using the following command:

kubectl create -f http_approot_request_modify.yaml

Using the curl command, you can verify if the application root is modified as per your requirement:

curl -vvv http://app.cic-citrix.org/

Output:

Modify app-root

Modify the strings in the requested URL

You can define a rewrite policy to modify the strings in the requested URL as per your requirement.

The following sample rewrite policy replaces the strings something to simple in the requested URL:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
name: httpurlreplacestring
spec:
rewrite-policies:
 - servicenames:
     - frontend
   rewrite-policy:
     operation: replace_all
     target: http.req.url
     modify-expression: '"/"'
     multiple-occurence-modify: 'regex(re~((^(\/something\/))|(^\/something$))~)'
     comment: 'HTTP url replace string'
     direction: REQUEST
     rewrite-criteria: http.req.is_valid
<!--NeedCopy-->

Create a YAML file (http_url_replace_string.yaml) with the rewrite policy definition and deploy the YAML using the following command:

kubectl create -f http_url_replace_string.yaml

You can verify the policy definition using a curl request with the string something. The string something is replaced with the string simple as shown in the following examples:

Example 1:

curl http://app.cic-citrix.org/something/simple/citrix

Output:

Replace string

Example 2:

curl http://app.cic-citrix.org/something

Or,

curl http://app.cic-citrix.org/something/

Output:

Replace string

Add the `X-Forwarded-For` header within an HTTP request

You can define a rewrite policy as shown in the following example YAML (http_x_forwarded_for_insert.yaml) to add the X-Forwarded-For header within an HTTP request:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httpxforwardedforaddition
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: insert_http_header
        target: X-Forwarded-For
        modify-expression: client.ip.src
        comment: 'HTTP Initial X-Forwarded-For header add'
        direction: REQUEST
        rewrite-criteria: 'HTTP.REQ.HEADER("X-Forwarded-For").EXISTS.NOT'

    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace
        target: HTTP.REQ.HEADER("X-Forwarded-For")
        modify-expression: 'HTTP.REQ.HEADER("X-Forwarded-For").APPEND(",").APPEND(CLIENT.IP.SRC)'
        comment: 'HTTP Append X-Forwarded-For IPs'
        direction: REQUEST
        rewrite-criteria: 'HTTP.REQ.HEADER("X-Forwarded-For").EXISTS'
<!--NeedCopy-->

Create a YAML file (http_x_forwarded_for_insert.yaml) with the rewrite policy definition and deploy the YAML file using the following command:

kubectl create -f http_x_forwarded_for_insert.yaml

Using the curl command you can verify the HTTP packet with and without the X-Forwarded-For header.

Example: Output of the HTTP request packet without X-Forwarded-For header:

curl http://app.cic-citrix.org/

Output:

Curl-output

Example: Output of the HTTP request packet with X-Forwarded-For header:

curl  curl --header "X-Forwarded-For: 1.1.1.1" http://app.cic-citrix.org/

Output:

Curl-output

Redirect HTTP request to HTTPS request using responder policy

You can define a responder policy definition as shown in the following example YAML(http_to_https_redirect.yaml) to redirect HTTP requests to HTTPS request:

apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: httptohttps
spec:
  responder-policies:
    - servicenames:
        - frontend
      responder-policy:
        redirect:
          url: '"https://" +http.req.HOSTNAME.SERVER+":"+"443"+http.req.url'
        respond-criteria: 'http.req.is_valid'
        comment: 'http to https'

<!--NeedCopy-->

Create a YAML file (http_to_https_redirect.yaml) with the responder policy definition and deploy the YAML file using the following command:

kubectl create -f http_to_https_redirect.yaml

You can verify if the HTTP request is redirected to HTTPS as follows:

Example 1:

$ curl -vvv  http://app.cic-citrix.org
* Rebuilt URL to: http://app.cic-citrix.org/
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET / HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found : Moved Temporarily
< Location: https://app.cic-citrix.org:443/   =======> Redirected to HTTPS
< Connection: close
< Cache-Control: no-cache
< Pragma: no-cache
<
* Closing connection 0

Example 2:

$ curl -vvv  http://app.cic-citrix.org/simple
*   Trying 10.102.33.176...
* TCP_NODELAY set
* Connected to app.cic-citrix.org (10.102.33.176) port 80 (#0)
> GET /simple HTTP/1.1
> Host: app.cic-citrix.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found : Moved Temporarily
< Location: https://app.cic-citrix.org:443/simple     ========> Redirected to HTTPS
< Connection: close
< Cache-Control: no-cache
< Pragma: no-cache
<
* Closing connection 0

Modify strings and host name in the requested URL

This example shows the usage of the goto-priority-expression attribute. The guidelines for usage of the goto-priority-expression field can be found at [How to write a policy configuration. This example modifies the URL http://www.citrite.org/something/simple/citrix to http://app.cic-citrix.org/simple/citrix.

Two rewrite policies are written to modify the URL:

Rewrite policy 1: This policy is used to modify the host name www.citrite.org to app.cic-citrix.org.
Rewrite Policy 2: This policy is used to modify the url /something/simple/citrix to /simple/citrix

You can bind the two policies using the goto-priority-expression attribute as shown in the following YAML:

  apiVersion: citrix.com/v1
  kind: rewritepolicy
  metadata:
    name: hostnameurlrewrite
  spec:
    rewrite-policies:
      - servicenames:
          - citrix-svc
        goto-priority-expression: NEXT
        rewrite-policy:
          operation: replace_all
          target: 'http.req.header("host")'
          modify-expression: '"app.cic-citrix.org"'
          multiple-occurence-modify: 'text("www.citrite.org")'
          comment: 'HTTP header rewrite of hostname'
          direction: REQUEST
          rewrite-criteria: 'http.req.is_valid.and(HTTP.REQ.HOSTNAME.EQ("www.citrite.org"))'
      - servicenames:
          - citrix-svc
        goto-priority-expression: END
        rewrite-policy:
          operation: replace_all
          target: http.req.url
          modify-expression: '"/"'
          multiple-occurence-modify: 'regex(re~((^(\/something\/))|(^\/something$))~)'
          comment: 'HTTP url replace string'
          direction: REQUEST
          rewrite-criteria: 'http.req.is_valid.and(HTTP.REQ.HOSTNAME.EQ("www.citrite.org"))'`
<!--NeedCopy-->

Verification

You can verify whether the following curl request http://www.citrite.org/something/simple/citrix is modified to http://app.cic-citrix.org/simple/citrix.

Example: Modifying the requested URL

curl http://www.citrite.org/something/simple/citrix

Modified host name and URL for the requested URL is present in the image shown as follows:

Curl output

HTTP callout

An HTTP callout allows the NetScaler to generate and send an HTTP or HTTPS request to an external server as part of the policy evaluation and take appropriate action based on the response obtained from the external server. You can use the rewrite and responder CRD to initiate HTTP callout requests from the NetScaler. For more information, see the HTTP callout documentation.

Feature Documentation
- NetScaler Rewrite Feature Documentation
- NetScaler Responder Feature Documentation
Developer Documentation

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Was this helpful

Use Rewrite and Responder policies in Kubernetes

Use Rewrite and Responder policies in Kubernetes

Deploy the NetScaler Rewrite and Responder CRD

Rewrite and Responder CRD attributes

Rewrite policy

Responder policy

Audit log

Dataset

Patset

String map

Goto-priority-expression

How to write a policy configuration

Guidelines for the policy configuration

Guidelines for the usage of Goto-priority-expression

Create and verify a rewrite and responder policy

Sample policy configurations

Responder policy configuration

Policy with audit logs enabled

Multiple policy configurations

Example use cases

Add response headers

Add custom header to the HTTP response packet

Replace host name in the request

Modify the application root

Modify the strings in the requested URL

Add the X-Forwarded-For header within an HTTP request

Redirect HTTP request to HTTPS request using responder policy

Modify strings and host name in the requested URL

Verification

HTTP callout

Related articles

In this article

Add the `X-Forwarded-For` header within an HTTP request