Jump to content
Welcome to our new Citrix community!
  • Tech Brief: Hostname Policy Expressions


    Magnus Esse 2
    • Validation Status: Validated
      Summary: This document aims to look at a few different ways to write policy expressions to match on the hostname the client uses in the HTTP request and point out why the expression frequently used might not be the best option to use.
      Has Video?: No

    Overview

     

    This document aims to look at a few different ways to write policy expressions to match on the hostname the client uses in the HTTP request and point out why the expression frequently used might not be the best option to use.

     

    Hostname Header

     

    I have created a simple website that can be accessed through a web browser by accessing the following address: http://testweb.domain.local:8080/page.html 

     

    To clearly show the differences in result for different policy expressions, I have elected to run the service on a non-standard port.

     

    If I open development tools in my browser and look at the headers, this is what I can see:

     

    converted-file.thumb.png.6b6dd402a9ba631aac35ba0e7508bb13.png

     

    Looking at the above will show us that the hostname header looks like this:

     

    Host: testweb.domain.local:8080
     

     

    Policy expressions

     

    Let's look at some of the more common policy expressions I see being used to match against the hostname the user entered and how they will work. The main goal every time you write a policy expression is to match as exact as possible to not allow or block traffic unintentionally.

     

    Expression 1

     

    TRUE
     

     

    This expression will match all requests but doesn't help much if we want to make a logical decision based on the incoming request. The policy expression is useful in test environments if you want to make sure to get a match but it should be avoided in production environments unless the intention is to actually capture all traffic.

     

    Expression 2

     

    HTTP.REQ.IS_VALID
     

     

    This expression will match all traffic which has a valid HTTP request formatting but doesn't help much if we want to make a logical decision based on the incoming request. The policy expression is useful if you want to allow all valid HTTP requests, but it should be avoided in production environments unless the intention is to capture all valid HTTP requests.

     

    Expression 3

     

    HTTP.REQ.HOSTNAME.EQ(“testweb.domain.local”)
     

     

    This expression will not match the request as you can see the port number has been appended in the end of the hostname, “:8080”. If you are using the standard port number 80 or 443 for your web service most browsers will not include the port number in the hostname header, but some clients might do it and therefore the result might differ based on which client is accessing the service. My recommendation is to avoid this expression unless you know it will for sure match your traffic correctly.

     

    Expression 4

     

    HTTP.REQ.HOSTNAME.STARTSWITH(“testweb.domain.local”)
     

     

    I have seen this used frequently when it has been discovered that EQ() wouldn't work. This expression will match our hostname in this case and it is a decent expression, however it will allow for something to be added in the end of the hostname and the request will be forwarded to the web server and depending on the web server it might or might not work. I would try to avoid using this expression when matching against hostnames if the intention is to match a single hostname.

     

    Expression 5

     

    HTTP.REQ.HOSTNAME.SERVER.EQ(“testweb.domain.local”)
     

     

    This expression will match as we have used the SERVER statement together with EQ(). What the SERVER statement does is it will look at the hostname and filter out only the FQDN part of the hostname and then EQ() will match against this, the port number will not be evaluated. This is the policy expression to be used if you want to match against exactly the hostname for the web service.

     

    Case Sensitivity

     

    During all my years writing policy expressions I have never encountered any issues with case sensitivity when writing policies matching against the hostname header which makes me believe they are not case sensitive, All clients I have been able to test with when writing this has converted the hostname to lowercase before sending the request, and if I use uppercase in the NetScaler policy expression for the hostname it will still work. I have always written hostnames in lowercase as I see this as a good practice to do. Case sensitivity is important to have in mind when writing other policy expressions though, but can be ignored when looking at the hostname header.

     

    Conclusion

     

    Always strive to match your policy expressions as exactly as possible.

     

    When matching based on the hostname header I suggest using HTTP.REQ.HOSTNAME.SERVER.EQ() if the intention is to match the exact FQDN that is used.

     

     

     

     

    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...