Follow on Twitter
Post to Twitter
Secure Selected Pages
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
In situations where you want to make sure that for some selected pages only the secure server is used, the following can be used.
Apache rewrite:
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/?(page1|page2|page3|page4|page5)$ https://www.example.com/%1 [R,L]
AppExpert rewrite example 1:
Add responder action res_redirect redirect '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.REGEX_MATCH(re/page[1-5]/)' res_redirect
Bind responder global pol_redirect 100 END
AppExpert rewrite example 2:
Add patset pat1 Bind patset pat1 page1 Bind patset pat1 page2 Bind patset pat1 page3 Bind patset pat1 page4 Bind patset pat1 page5 Add responder action res_redirect redirect '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.CONTAINS_ANY("pat1")' res_redirect Bind responder global pol_redirect 100 END
Tap into the power of AppExpert!
Redirecting a URI to a new format
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Let's say, for example, that you've got a set of working URLs that look like this: /index.php?id=nnnn. However, you'd really like to change them to /nnnn and make sure search engines update their indexes to the new URI format. First, you'd have to redirect the old URIs to the new ones so that search engines update their indexes, but you still have to rewrite the new URI back to the old one so that the index.php script would run.
Example: The trick here is to place into the query string a marker code that will not be seen by visitors. We redirect from the old link to the new format only if the "marker" is not present in the query string. Then we rewrite the new format link back to the old format, and add a marker to the query string.
Apache rewrite:
RewriteCond %{QUERY_STRING} !marker
RewriteCond %{QUERY_STRING} id=([-a-zA-Z0-9_+]+)
RewriteRule ^/?index\.php$ %1? [R,L]
RewriteRule ^/?([-a-zA-Z0-9_+]+)$ index.php?marker&id=$1 [L]
AppExpert rewrite:
Add responder action act_redirect redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("index.php")+HTTP.REQ.URL.QUERY.VALUE("id")' -bypassSafetyCheck yes Add responder policy pol_redirect '!HTTP.REQ.URL.QUERY.CONTAINS("marker")&& HTTP.REQ.URL.QUERY.VALUE("id").REGEX_MATCH(re/[-a-zA-Z0-9_+]+/) && HTTP.REQ.URL.PATH.CONTAINS("index.php")' act_redirect Bind responder global pol_redirect 100 END Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"index.phpmarker&id="+HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' -bypassSafetyCheck yes Add rewrite policy pol1 '!HTTP.REQ.URL.QUERY.CONTAINS("marker")' act1 Bind rewrite global pol1 100 END
Tap into the power of AppExpert!
Creating Extensionless links
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Sometimes you may want to support extension less links, either to hide extensions from end users or to make URLs easy to remember.
Example 1: add .php extension to all requests
Apache rewrite:
RewriteRule ^/?([a-z]+)$ $1.php [L]
AppExpert rewrite:
Add rewrite action act1 insert_after 'HTTP.REQ.URL' '".php"'
Add rewrite policy pol1 'HTTP.REQ.URL.PATH.REGEX_MATCH(re#^/([a-z]+)$#)' act1
Bind rewrite global pol1 100
Example 2: if we have a mixture of both .html and .php files, the following can be used
Apache rewrite:
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.php [L]
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.html [L]
AppExpert rewrite:
Here HTTPCallout would be used, script file_check.cgi hosted on 10.102.59.101 is used to check wether provided argument is avalid file name or not.
add HTTPCallout Call_html add HTTPCallout Call_php set policy httpCallout Call_html -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url+".html" set policy httpCallout Call_php -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url+".php" Add patset pat1 Bind patset pat1 .html Bind patset pat1 .php Bind patset pat1 .asp Bind patset pat1 .cgi Add rewrite action act1 insert_after 'HTTP.REQ.URL.PATH' '".html"' Add rewrite action act2 insert_after "HTTP.REQ.URL.PATH" '".php"' Add rewrite policy pol1 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_html)' act1 Add rewrite policy pol2 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_php)' act2 Bind rewrite global pol1 100 END Bind rewrite global pol2 101 END
Tap into the power of AppExpert!
Blocking Inline Images
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume you have under http://www.quux-corp.de/~quux/ some pages with in lined GIF graphics. These graphics are nice, so others directly incorporate them via hyperlinks to their pages. you don't like this practice because it adds useless traffic to your server.
Example : You can restrict the cases where the browser sends a HTTP Referer header.
Apache rewrite:
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$
RewriteRule .*\.gif$ - [F]
AppExpert rewrite:
Add patset pat1 Bind patset pat1 .gif Bind patset pat1 .jpeg add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"' add responder policy pol1 '!HTTP.REQ.HEADER("Referer").EQ("") && !HTTP.REQ.HEADER("Referer").STARTSWITH("http://www.quux-corp.de/~quux/")&&HTTP.REQ.URL.ENDSWITH_ANY("pat1")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Blocking Robots
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
You can block a really annoying robot from retrieving pages of a specific webarea. This way you can ease up the traffic at some directories.
Example : This could be done by using a rule set which forbids the URLs of the web area /~quux/foo/arc/. This could also be accomplished by matching the User-Agent HTTP header information. In this example, the ip address to be blocked is 123.45.67.8 & 123.45.67.9.
Apache rewrite:
RewriteCond %{HTTP_USER_AGENT} ^NameOfBadRobot.*
RewriteCond %{REMOTE_ADDR} ^123\.45\.67\.[8-9]$
RewriteRule ^/~quux/foo/arc/.+ - [F]
AppExpert rewrite:
add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"' add responder policy pol1 'HTTP.REQ.HEADER("User_Agent").STARTSWITH("NameOfBadRobot")&&CLIENT.IP.SRC.EQ(123.45.67.8)&&CLIENT.IP.SRC.EQ(123.45.67.9) && HTTP.REQ.URL.STARTSWITH("/~quux/foo/arc")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Browser Dependent Content
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
At least for important top-level pages it is sometimes necessary to provide the optimum of browser dependent content, i.e. one has to provide a maximum version for the latest Netscape variants, a minimum version for the Lynx browsers and an average feature version for all others.
Example : We will act on the HTTP header "User-Agent". The following config does the following: If the HTTP header "User-Agent" begins with "Mozilla/3", the page foo.html is rewritten to foo.NS.html and the rewriting stops. If the browser is "Lynx" or "Mozilla" of version 1 or 2 the URL becomes foo.20.html. All other browsers receive page foo.32.html. This is done by the following rule set:
Apache rewrite:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.*
RewriteRule ^foo\.html$ foo.NS.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx/.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[12].*
RewriteRule ^foo\.html$ foo.20.html [L]
RewriteRule ^foo\.html$ foo.32.html [L]
AppExpert rewrite:
Add patset pat1 Bind patset pat1 Mozilla/1 Bind Patset pat1 Mozilla/2 Bind patset pat1 Lynx Bind Patset pat1 Mozilla/3 add rewrite action act1 insert_before 'HTTP.REQ.URL.SUFFIX' '"NS."' add rewrite action act2 insert_before 'HTTP.REQ.URL.SUFFIX' '"20."' add rewrite action act3 insert_before 'HTTP.REQ.URL.SUFFIX' '"32."' add rewrite policy pol1 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").EQ(4)' act1 add rewrite policy pol2 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").BETWEEN(1,3)' act2 add rewrite policy pol3 '!HTTP.REQ.HEADER("User-Agent").STARTSWITH_ANY("pat1")' act3 bind rewrite global pol1 101 END bind rewrite global pol2 102 END bind rewrite global pol3 103 END
Tap into the power of AppExpert!
Old to New External URL Rewrite
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume that you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. But this time you want the users of the old URL to see new one, i.e. their browsers Location field should change too.
Example : The following rules can force an HTTP redirect to the new URL which leads to a change of the URL in the users browser:
Apache rewrite:
RewriteEngine on RewriteBase /~quux/ RewriteRule ^foo\.html$ bar.html [R]
AppExpert rewrite: (There are two ways to do this)
add responder action act1 redirect 'HTTP.REQ.URL.BEFORE_STR("foo.html")+"bar.html"' -bypassSafetyCheck yes add responder policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1 bind responder global pol1 100
add responder action act1 redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("foo.html")+"bar.html"+HTTP.REQ.URL.AFTER_STR("foo.html")' -bypassSafetyCheck yes add responder policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Old to New Internal URL Rewrite
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. Actually you want users of the old URL to not recognize that the pages were renamed.
Example : Rewrite the old URL to the new one internally via the following rule, let the base directory be /~quux/.
Apache rewrite:
RewriteEngine on RewriteBase /~quux/ RewriteRule ^foo\.html$ bar.html
AppExpert rewrite: (There are two ways to do this)
add rewrite action act1 replace 'HTTP.REQ.URL.AFTER_STR("/~quux").SUBSTR("foo.html")' '"bar.html"' add rewrite policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1 bind rewrite global pol1 100
Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"bar.html"' Add rewrite policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1 Bind rewrite global pol1 100
Tap into the power of AppExpert!
Time Dependent Rewriting
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
We can rewrite a URL based on time.
Example : Changing the request foo.html to foo.day.html or foo.night.html according to time.
Apache rewrite:
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.day.html [L]
RewriteRule ^foo\.html$ foo.night.html
AppExpert rewrite:
Add rewrite action act1 insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"day."' Add rewrite action act2 insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"night."' add rewrite policy pol1 'SYS.TIME.WITHIN(LOCAL 07h 00m,LOCAL 18h 59m)' act1 add rewrite policy pol2 'true' act2 bind rewrite global pol1 101 bind rewrite global pol2 102
Tap into the power of AppExpert!
Failed URL Redirect
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
In case the current url is not valid & the request needs to be redirected to another web server, the following steps could be taken.
Example : We will check weather the request filename exists on the server or not, in case it fails then redirection is done to another webserver (for example, webServerB.com). In the case of AppExpert, HTTPCallout is used to check the presence of the file on the server by running a script file_check.cgi on the server. The returned value from HTTPCallout is used to validate the policy.
The Script file_check.cgi takes the url as the argument, checks for its presence on the server & returns True or False accordingly.
Apache rewrite:
RewriteCond /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule ^(.+) http://webserverB.com/$1 [R]
AppExpert rewrite: (There are two ways to do this)
add HTTPCallout Call set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url.path -headers Name("ddd") add responder action act1 redirect '"http://webserverB.com"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS && !SYS.HTTP_CALLOUT(call)' act1 bind responder global pol1 100
add HTTPCallout Call set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url.path -headers Name("ddd") add responder action act1 respondwith '"HTTP/1.1 302 Moved Temporarily\r\nLocation: http://webserverB.com"+HTTP.REQ.URL+"\r\n\r\nHTTPCallout Used"' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS && !SYS.HTTP_CALLOUT(call)' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Structured Homedirs
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Some sites with thousands of users usually use a structured homedir layout, i.e. each homedir is in a subdirectory which begins for instance with the first character of the username. So, /~foo/anypath is /home/f/foo/.www/anypath while /~bar/anypath is /home/b/bar/.www/anypath.Following rules could be used to implement this.
Apache rewrite:
RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/.www$3
AppExpert rewrite:
Add rewrite action act1 replace 'HTTP.REQ.URL' '"/home/"+ HTTP.REQ.URL.AFTER_STR("~").PREFIX(1)+"/"+ HTTP.REQ.URL.AFTER_STR("~").BEFORE_STR("/")+"/.www"+HTTP.REQ.URL.SKIP(\'/\',1)' -bypassSafetyCheck yes Add rewrite policy pol1 'HTTP.REQ.URL.PATH.STARTSWITH("/~")' act1 Bind rewrite global pol1 100
Tap into the power of AppExpert!
Move Homedirs to Different Web Server
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
There are cases when you want to redirect requests for homedirs on one web server to another web server. The typical use case for this arises when establishing a newer web server which will replace the old one over time. i.e. you need to redirect all the requests for a particular homedir to another web server.
Example : Let the hostname for new webserver be newserver.
Apache rewrite:
RewriteRule ^/(.+) http://newserver/$1 [R,L]
AppExpert rewrite: (There are two ways to do this)
Add responder action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.REGEX_MATCH(re#^/(.+)#)' act1
Bind responder global pol1 100 END
Add responder action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.LENGTH.GT(1)' act1
Bind responder global pol1 100 END
Tap into the power of AppExpert!
Canonical Hostnames
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
The goal of the following rule is to force the use of a particular hostname, in preference to other hostnames which may be used to reach the same site. For example, if you wish to force the use of www.example.com instead of example.com, you might use a variant of the following rules.
Example : changing example.com to www.example.com
Apache rewrite:
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*) http://www.example.com:%{SERVER_PORT}/$1 [L,R]
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.example.com/$1 [L,R]
AppExpert rewrite:
add responder action act1 redirect '"http://www.example.com:"+CLIENT.TCP.DSTPORT+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&!HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
add responder action act1 redirect '"http://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
Tap into the power of AppExpert!
Canonical URLs
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler. On some Apache web servers there is more than one URL for a resource. Usually there are canonical URLs (which should be used and distributed as a best practive) and those which are just shortcuts, internal ones, etc. Independent of which URL was supplied with the request, the user should only see the canonical one URL in the response.
Example : converting URL /~user to /u/user.
Apache rewrite:
RewriteRule ^/~([^/]+)/?(.*) /u/$1/$2[R]
AppExpert rewrite:
Add responder action act1 redirect '"/u/"+HTTP.REQ.URL.AFTER_STR("/~")' -bypassSafetyCheck yes Add responder policy pol1 'HTTP.REQ.URL.STARTSWITH("/~") && HTTP.REQ.URL.LENGTH.GT(2)' act1 Bind responder global pol1 100
Tap into the power of AppExpert!
The #1 Web Filter by St.Bernard is now Citrix Ready. The Highest Performance Web Application Solution from Citrix Systems can now be deployed with the the #1 Web Filter by St. Berdard. IDC ranked them #1, SC Magazine gives them high ratings, and you will agree when you plug this thing in. The Citrix Web Application Firewall protects inbound traffic destined to Web and Application Servers without degrading throughput or response time. Now, with St.Bernard's iPrism h-Series high performance appliances, you can also do outbound Web filtering, IM/P2P filtering, and antivirus detection. The iPrism Web Filter is optimized for the datacenter infrastructure and sits behind the firewall while it monitors traffic. St. Bernard's platforms are hybrid so that Web filtering, antivirus and IM/P2P filtering are all contained within one box - unlike other point solutions.
St.Bernard's iPrism Web Filter is easy to use and easy to manage. If fact, it's so easy, we had the device up and running in Proxy mode and then in Bridge mode in a matter of seconds. The management software auto-discovers the box, so you don't have to plug in a console cable - very nice!
It is far better than a transparent proxy because St.Bernard has engineered their filtering technology at the kernel level, so their bridge mode really is a bridge between interfaces, and not just a transparent proxy like other solutions in the market.
We deployed the iPrism Web Filter behind our NetScaler, and had the NetScaler perform NAT (Reverse NAT) for outbound connections to the Internet. The iPrism Web Filter adds another level of security that IT organizations sometimes look for to complement their existing base of high-performance Citrix Gear.
Citrix & St.Bernard Deployment Guide!
You can try this product for free.
The product demo is awesome.
As a hybrid unit, this is a steal.
NetScaler Developer Network!
As web applications grow in complexity, the art of accelerating them seems to remain the same. This art is performed by applying some basic concepts to the application; that is, Caching, Compression, Load Balancing, Global Server Load Balancing, SSL Offload & Acceleration, Content Switching, TCP Multiplexing and SSL Session Reuse.
Citrix® is a leader in Gartners magic quadrant for Application Delivery with their flagship appliance NetScaler®. NetScaler accelerates web application performance by leveraging multiple acceleration technologies and innovative TCP optimizations.
Whether you are building out a new datacenter and architecting it the right way, or retrofitting an existing datacenter, Citrix NetScaler will perform and keep costs down. Whether you are looking to accelerate legacy enterprise applications such as Oracle or SAP, or building a new web 2.0 social community, Citrix NetScaler contains all of the tools to get you there.
Citrix NetScaler web application delivery solutions are purpose built appliances that accelerate application performance, while simultaneously reducing datacenter costs and improving web application security. Platforms range from the entry level 7000 to the latest MPX-series appliances that provide an industry-leading 15 Gbs of throughput at Layers 4 through 7.
There's more here: Case Studies, White Papers, Analysts , Datasheets
Check out the new MPX!
Buy it here!
Tap into the power of AppExpert!
Becoming an Application Expert means that you can profile an application and quickly determine how it can be architected or re-constructed for higher performance. Of course, we want you to use the Citrix Application Switch as part of the architecture. In Part 1, we learned how to profile an application to learn what it looks like as the traffic flows through the Citrix Application Switch. Now we will determine what parts of an application are cacheable and what parts are non-cacheable.
By Application Profiling we can determine which parts of the application are cacheable and non-cacheable just by looking at the Request and Response headers. The application will sometimes tell you through it's "Cache-Control" header directives. Some content that we just know is static and doesn't ever change, we can consider cacheable as static content. Content that changes, such as reports, are often considered non-cacheable but with the help of Selectors and Dynamic Content Groups in the Citrix NetScaler, this content can be cached. As a proof of concept, we deployed the Citrix NetScaler Application Switch in the front of Oracle E-Business Suite v12 application and implemented caching policies for both static and dynamic content. As it turns out, alot of static content is cached by default policies and setting up dynamic policies is not that difficult. To see how, read the Caching Deployment Guide for Oracle E-Business Suite v12.
Watch this Caching Tip:
Tap into the power of AppExpert!
Application Profiling
Introduction:
I can turn you into an Application expert in 5 minutes by reading this post. Just do what the experts do, or even the not-so-experts. They pay meticulous attention to the requests from clients and the responses from servers, both headers and body content. You do this the old fashioned way by taking a trace. There are better tools out there, some free, some not-so-free.
Running a trace:
Running a trace will help you 'profile' the application. It is recommended that you do this before placing the Citrix Application Switch in-line of the Application traffic. This will gather important information about the Application that will help you understand it's basic operation at Layer 7, and help you begin to understand what it is that needs to be accelerated - cached, compressed, load balanced, ssl offloaded, etc.
Running a trace exposes the flow of transactions between all points of interest. Traces are especially helpful when digging in to find what is contained within the headers being exchanged between the client and the application.
Taking a trace with wireshark:
The free network protocol analyzer called wireshark, http://www.wireshark.org, will capture packets for you on the localhost, whether it's windows or linux. By filtering the stream of packets by IP Address, right clicking and selecting 'Follow TCP Stream' inside of wireshark, you can see the headers for both requests and responses.
 | Wireshark tip 1 Find the first 'SYN' in the stream, right click, 'Follow TCP Stream'. |
| Wireshark tip 2 Client requests are in Red, Server responses are in Blue. |
Taking a trace with the Citrix Application Switch:
If the Citrix Application Switch is already in place, a trace can be run directly on the Citrix Application Switch. Running a trace will expose the flow of transactions between all points of interest, especially the client, load balancing VIPs and backend servers. Traces are especially helpful when digging in to find out if the proper headers are being exchanged between client & VIP and VIP & backend servers. A trace can be run directly on the Citrix Application Switch. Once downloaded this file can be opened and request and response headers read with Wireshark, a free network trace utility, http://www.wireshark.org. From the Citrix Application Switch GUI, navigate to NetScaler -> System -> Diagnostics -> New Trace -> Run.
Viewing headers with Paros:
Paros was originially written for web security, but has value when viewing request and response headers, cookies and the like. Through Paros's proxy nature, all HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted. There is an additional option of trapping and modifying data before sending it on to the server, or client. Paros can be found at http://parosproxy.org. Free.
Viewing headers with Live HTTP Headers:
Live HTTP Headers, http://livehttpheaders.mozdev.org/, was developed for use with the Firefox web browser. It is a free add-on and allows you to view HTTP header information in real time. Free.
Viewing headers with IE Analyzer:
IEInspector HTTP Analyzer, http://www.ieinspector.com, is a tool that allows you to monitor, trace, debug and analyze HTTP/HTTPS traffic in real-time. It works with Microsoft Internet Explorer. Not-Free.
Viewing headers with IE Watch:
IEWatch, http://www.iewatch.com, is another plug-in for Microsoft Internet Explorer that helps you profile your web applications. You can use this tool to dig deep into the inner workings of web applications to find hidden issues. Not-Free.
Watch this Application Profiling Tip:
Tap into the power of AppExpert
The SAP Enterprise Service Oriented Architecture (SOA) provides a blueprint for services-based, enterprise scale business solutions that are adaptable, flexible, and open. Enterprise Services Architecture takes the concept of service-oriented architecture to a new level by transforming Web services into enterprise services. Bringing Citrix and SAP Enterprise Services Architecture together reduces the dependence on customized applications, and increases flexibility and reduces time to deployment while reducing operational expenses.
This Citrix / SAP Enterprise SOA Deployment Guide was created out of a joint engagement between Citrix and SAP at the Co-Innovation Laboratory in Palo Alto, California, USA. This deployment guide walks through the step-by-step configuration details of how to configure the Citrix NetScaler for use as front-end to SAP Portal for end-user traffic, that is HTTP ~ HTML. To further complement the value of the Enterprise SOA, this guide walks through the details of how to configure the Citrix NetScaler for use as a front-end to the SAP Composite Application Framework and SAP ERP Web Services platforms, providing a flexible load balancer and HTTPS encryption point for machine to machine web service traffic. With this deployment Citrix becomes an integral and flexible part of the SAP Enterprise SOA "Applistructure" bringing together applications and technology for a fast, flexible and highly effective service oriented IT infrastructure.
Watch this Load Balancing Tip:
Tap into the power of AppExpert
We recently had a meeting with a large partner of ours and they handed down some hefty requirements. An average of 100 partners using their portal on any given month to access their development environments on the backend. It was clear that NetScaler could scale, but the question was how to keep all of those partners separated from each other, without them peeking into each others traffic. It turned out to be easier than we thought using the NetScaler as an SSL VPN with the addition of some policies bound to each partner's user group. The following is an overview of the network diagram, and there are some deployment guides to walk you through these installations.
The Citrix SSL VPN CPS Deployment Guide walks you through deploying NetScaler SSL VPN as an ICA Proxy and authentication point. It then walks you through deploying Citrix Presentation Server and the steps necessary to connect the SSL VPN to the CPS Applications. The guide includes Session policies which direct users upon authentication to specific CPS farms on the backend of the NetScaler SSL VPN. Think of it as an authentication portal.
The Citrix SSL VPN Deployment Guide walks you through deploying NetScalers as an HA Pair, and then as an SSL VPN with ICA Proxy OFF. The intention was to use the SSL VPN for regular VPN traffic, and not Citrix Presentation Server traffic. Just as well, policies can be combined on the same NetScaler Application Switch to allow both non-CPS and CPS traffic to traverse the same SSL VPN.
Tap into the power of AppExpert