A Domain describes a network path to your website. SiteSpect Sites can have multiple Domains that may correspond to multiple back-end web servers or domain names. For example, consider a website that has a regular unencrypted shopping area (http://www.mysite.com), a secure area for manipulating a shopping cart (https://www.mysite.com), and a separate server for performing secure credit card checkout (https://checkout.mysite.com). To properly test customers as they visit the different areas of the website on their way to making a purchase, SiteSpect requires one Domain for each of these.
The Domain page lists the Domains that are defined for your Site. From this page, you can manage your Domain configuration, purge the cache, and get an entry to copy into your hosts file.
When you edit a Domain, the following tabs are available:
General
Front & Back End
Description
Specifies a brief description of the Domain.
Type
Specifies what type of Domain this is. The types are:
- Production
- Non-Production
- Test
- Demo
- API
Status
The following are the Statuses for Domains:
- Live – The Domain is ready to accept traffic.
- Bypass – The Domain has been manually configured to not accept traffic.
Release Order
Determines the order in which releases and other changes are rolled out to this Domain relative to other Domains.
Front End
Protocol
Specifies the protocol that SiteSpect uses for traffic. The options are:
- HTTP (default)
- HTTPS
Front End IP Address
Displays automatically assigned addresses unless this domain uses a different port on the same addresses assigned to an existing domain (common for HTTPS/SSL domains).
External Port
Specifies the port number where the front end listens on for web traffic. Typically, non-secure websites (HTTP) use port 80 and secure/SSL sites (HTTPS) use port 443.
Internal Port
This field specifies the internal port number where the front end listens for web traffic.
Front End IP Name
Specifies the DNS name where SiteSpect listens for traffic. Typically, it corresponds to the actual URL where you expect users to enter the website. Note that SiteSpect proxies requests to the origin website (located at the Back End IP or Back End Name) regardless of the Front End Name, preserving the Host header the client sent. For HTTP/1.0 requests (i.e., sent by very old browsers), SiteSpect inserts a Host header in the request based on the value of the Front End Name (although this may be superseded by the Back End Name if the Translate Hostname option is set).
Update DNS for Selected Address
Tells SiteSpect to update the live DNS record when the Domain is saved. When unchecked (the default), this feature is disabled; when checked, it’s enabled.
Back End
This section of the page displays several attributes about the back-end settings.
Protocol
Specifies the protocol that SiteSpect uses for origin traffic. The options are:
- HTTP (default)
- HTTPS
Back End IP Address
Specifies the back-end web server's IP address. If you also specify a Back End Name, SiteSpect attempts to resolve that DNS name and use it instead of the Back End IP address. If the Back End Name cannot be resolved through DNS, SiteSpect reverts to the Back End IP Address.
Port
Specifies the port number that the back-end web server uses to listen for web traffic. Typically, non-secure websites (HTTP) use port 80 and secure/SSL sites (HTTPS) use port 443. The default value is 80.
Add Origin IP for DNS Monitoring
Indicates whether or not SiteSpect should add the Back End (Origin) IP to the DNS Management Service to monitor its performance. This option is available only if the protocol and port are the same for the front end and back end. When checked, the default, SiteSpect adds the origin IP; unchecked, it does not.
Back End IP Name
Specifies the name of the back-end web server and used in conjunction with the following checkboxes, which specify how SiteSpect uses the Back End Name.
Perform DNS Lookups
Tells SiteSpect that instead of using the Back End IP Address, it should attempt to determine the back end's IP address through a DNS lookup of the Back End Name. SiteSpect then caches the resolved IP address for the period of time (TTL) specified by the DNS server record. Note that we discourage using this feature for DNS records that have a low TTL value (i.e., less than 300 seconds), as it may increase latency due to more frequent DNS lookups. When checked, this feature is enabled; unchecked (the default), it does not.
Translate Hostname (URL Tunnel®)
Tells SiteSpect to translate all Host headers to that of the Back End Name, translate the hostname used for SNI on the origin, and all response Set-Cookie headers to that of the Front End Name. This setting is useful in situations when the back-end web server has not been configured to accept requests for the Front End IP Name. For example, if the front end is www2.company.com but the back end accepts requests only for www.company.com, this feature automatically translates requests so that they appear as www.company.com to the back-end web server. Cookies set by the back end are also converted to the Front End domain. When enabled, this feature inserts a Host-Orig request header with the original Host value; this header is visible to the back-end web server. When checked, SiteSpect translates the Host header; unchecked (the default), it does not.
Healthcheck URL
Specifies the URL that the load balancer or monitoring agent checks to determine the health of the back-end host and the SiteSpect system. For example, if the back-end host contains a page accessed as http://www.mysite.com/?sshealth=1, this field should be defined as /?sshealth=1.
There are four potential responses that SiteSpect produces during a Healthcheck:
- All OK: SiteSpect is able to connect to the back-end host, the back end's response is 200 OK, and SiteSpect's own internal health checks pass. In this case, SiteSpect returns 200 OK.
- Back End Unreachable: SiteSpect is unable to connect to the back-end host. This could be due to a connectivity problem or the back-end host is simply down/failed. In this case, SiteSpect returns a status code 502 Bad Gateway.
- Back End Reports Problem: SiteSpect is able to connect to the back-end host, but the back end returns an error code (i.e., non-200 status code). In this case, SiteSpect passes the error along and does not attempt to validate its own internal health.
- SiteSpect Internal Problem: SiteSpect is able to connect to the back-end host, and the back end responds with 200 OK. SiteSpect next attempts to run its own internal checks to verify that the SiteSpect system itself is in good health. If it is, SiteSpect returns 200 OK; if the SiteSpect system itself is having problems, SiteSpect returns an error code 500 Internal Server Error.
If no Healthcheck URL is defined, SiteSpect still passes along requests and responses to the back-end Domain, but it does not attempt to check its own internal health.
Finally, note that if a Healthcheck URL is defined, SiteSpect always passes-through the content. In other words, although SiteSpect validates its own health when the URL is requested, that URL is never analyzed for Metrics or Variations. For this reason, we strongly recommend that you use a URL/page that is not visible to visitors.
DNS (Global) Healthcheck Path
Specifies the path to the Healthcheck file, which is carried over from the value in the Health check field and provided here for easy reference. It is a read-only field.
DNS Performance Test Path
Specifies the path to the file hosted on the origin web server that is used to optimize network performance across datacenters and geographic regions. SiteSpect’s DNS system performs periodic measurements to identify the best performing datacenter for different geographic regions. The target of those checks is identified in this field.
SSL
The SSL tab specifies settings that help to manage your HTTPS certificate.
Use Existing Key and Certificate
SiteSpect issues a new Certificate Signing Request (CSR) using the existing Private Key file already on hand. The drop-down lists any certificates that are used for any other Domain associated with your account.
Generate New SSL Key
SiteSpect creates a new Private Key file for use when generating a Certificate Signing Request (CSR).
SAN Domains
Creates a Certificate Signing Request (SAN) that includes Subject Alternative Names (SAN). This allows a single certificate to be valid for multiple domains.
Key Strength
Adjusts how secure the HTTPS Key should be.
Cipher
Specifies which encryption cipher to use.
Logging & Performance
The Logging & Performance tab specifies settings that determine what level of logging is established for your site as well as performance settings such as timeouts, caching, and compression.
Logging Level
Specifies how much information is included in SiteSpect transfer logs.
National Center for Supercomputing Applications Common Log Format, also known as NCSA format is a standardized text file format used by web servers when generating server log files. Their standardized format is readily analyzed by a variety of web analysis programs. The NCSA Combined Log format contains the same information as the Common Log format with the addition of the referral field, the user_agent field, and the cookie field.
The available options are:
- NCSA combined + User GUID + Status (default)
- NCSA combined + User GUID + Status + Debug
The option NCSA combined + User GUID + Status + Debug uses the Preview Cookie, which results in an extra cookie for each visitor.
Enable Persistent Front-End Connections
Tells SiteSpect to maintain a persistent TCP connection with the visitor if the incoming request includes a Connection: Keepalive request header. When checked, the default, this feature is enabled; unchecked, it is not.
Max. Requests per Connection
Specifies the maximum number of requests over a persistent TCP connection before SiteSpect closes the connection. The default is 250 requests.
Seconds Timeout (Front-End)
Specifies the idle timeout before SiteSpect closes the connection. The default is 10 Seconds.
Enable Persistent Back-End Connections
Tells SiteSpect to include a Connection: Keepalive request header when proxying requests to the origin. The origin maintains the persistent connection (if supported). When checked, the default, this feature is enabled; unchecked, it is not.
Seconds Timeout (Back-End)
Specifies the idle timeout before SiteSpect closes the connection to the origin. The default value is 0 seconds (disabled, allows the origin to control the connection).
Pair Back-End & Front-End Connections
Tells SiteSpect to establish a new TCP connection to the origin for each new front-end connection and discontinue using older TCP connections. When checked, this feature is enabled; unchecked (the default), it is not.
Enable Content Caching
Tells SiteSpect to cache content. When checked, the default, this feature is enabled; unchecked, it is not.
For more information see Content Caching.
Content to be Cached
Specifies the paths of content that you want to be cached. Enter complete or partial URL paths/files, left-anchored, one item per line. All items are treated as case-sensitive.
The following are typical examples of how to specify content to be cached:
/: Everything is eligible for caching.
/images/: Everything under the /images/ URL is eligible for caching.
/electronics-dept/images/: Everything under the /electronics-dept/images/ URL is eligible for caching.
/images/movie.wmv: The specific document /images/movie.wmv is eligible for caching.
Content is eligible for caching only if the back-end web server has not marked it as being un-cachable. Content served through HTTP "basic authentication" is not eligible for caching. Lines that begin with # or // are comments.
Default Value:
/images/
/favicon.ico
When Content Caching is enabled, you can (optionally) add an SS-Cache-Debug: 1 request header. When you do, SiteSpect returns the SS-Cache-Status response header with the following possible values:
MISS - The response was served from the origin.
HIT - The response was served from cache.
REVALIDATED - The response was revalidated, then served from cache.
+ and - Indicators
If you start a line of text with a - (minus sign), you're telling SiteSpect that you do not want to cache the content indicated by that line.
If you start a line of text with a + (plus sign), you're telling SiteSpect that you do want to cache the content indicated by that line.
When SiteSpect considers the lines in the text field, order matters. For example, if you specify that you want to cache everything under /images and then in a later line, you specify that you do not want to cache /images/banner.jpg, SiteSpect does not cache /images/banner.jpg.
In this scenario, the textbox value would look like the following:
/images/
-/images/banner.jpg
Ignore Cache-Control: no-store headers when caching content: Tells SiteSpect to ignore the no-cache directive in the Cache-Control header. Available only if Enable Content Caching is selected.
Ignore Cache-Control: private headers when caching content: Tells SiteSpect to ignore the private directive in the Cache-Control header. Available only if Enable Content Caching is selected.
Maximum Time to Cache the Content
Specifies how long SiteSpect caches an object. The default is 3600 seconds.
Enable Back-End Content Compression
Tells SiteSpect to include an Accept-Encoding: gzip request header when proxying requests to the origin. This allows the origin to respond with compressed content. When checked, the default, this feature is enabled; unchecked, it is not.
Enable Front-End Content Compression
Tells SiteSpect to present compressed content to the visitor when the visitor sends requests with an Accept-Encoding: gzip request header. When checked, the default, this feature is enabled; unchecked, it is not.
Compression Exclusions
Specifies content to exclude from compression. Enter complete or partial paths/files in this field, one item per line.
Compressed JavaScript content sometimes causes problems in browsers, particularly if the origin web server does not correctly tag it with the appropriate MIME type. To avoid these problems, you can define a set of file names or directories in this field with matching URLs that should be excluded from the compression filter. Each line that you specify should be in regular expression format and is interpreted as case-insensitive (so js is equivalent to JS).
For example, a value of ^/js/ excludes any files within the /js/ root directory from being compressed; A value of \.js$ excludes any files with a .js suffix.
You can enter the special value NON-HTML on its own line to indicate that only HTML content should be deflated.
Lines beginning with # or // are considered comments.
Enable Benchmarking of Content Retrieval & Analysis Overhead
When benchmarking is enabled, SiteSpect automatically samples round-trip proxy times and records them to an internal log file. When checked, the default, this feature is enabled; unchecked, it is not.
Benchmark Percent
Specifies the percentage of traffic to benchmark. The default is 5%.
Use Aggressive Cache Busting for all Analyzed Content
When using SiteSpect Metrics for binary content such as images (gif, jpeg, png, etc.), you may want to enable aggressive cache-busting. This is an unusual requirement, so in most cases you should leave this box unchecked.
Ordinarily, when this box is unchecked, SiteSpect performs moderate cache-busting on binary content such as images, as well as ordinarily static-only content such as CSS and JavaScript. Here, moderate cache-busting applies HTTP cache-control that allows the browser to cache a local copy, but requires a revalidation of the cached copy for each subsequent view. During the revalidation, SiteSpect is able to trigger a Metric (assuming status code 304 is NOT being passed-through). However, it has been observed that a small percentage of browsers ignore the revalidation requirement. Thus, to ensure the most accurate Metric tracking for binary content, enable this option to prevent browsers from caching the content in the first place.
You may want to enable this feature if you require the use of Visit Rating for Factors that modify CSS or JavaScript files. Here, using aggressive cache-busting ensures that SiteSpect can always refresh a CSS or JavaScript file that might have otherwise been cached in the browser.
Note that if you are using Metrics for binary content, you must also ensure that the Site is not configured to pass-through these content types. Then, if you leave this box unchecked (i.e., moderate cache busting), we recommend that you do not pass-through response status code 304 (revalidation). If you do check this box (i.e., to enable aggressive cache busting), you can pass through response status code 304.
When checked this feature is enabled; unchecked, the default, it is not.
Show User/Visit Tracking Info in Browser Status Bar
Adds visitor session information to the status bar of the browser. When checked this feature is enabled; unchecked, the default, it is not.
Access Control
The settings in this section specify what IP Addresses have access to your Site.
Enable Access Control for this Domain
Enables the Access Control feature that allows/disallows visitors based on their IP Addresses. When checked this feature is enabled and the Whitelist and Blacklist fields appear, allowing you to enter IP Addresses for each; unchecked, the default, it is not enabled.
Include Default Whitelist
When you select this option, SiteSpect adds the line Includes Default Whitelist to the top of the Whitelist text box and uses the existing preset defaults in addition to any Whitelist IP addresses you have entered on this page. The current Default Whitelist is empty.
Whitelist
A Whitelist is a list of IP addresses that are allowed to visit your site. Enter a list of IP addresses, separated by a space or a carriage return, that are allowed to visit your site. The following are acceptable formats:
192.168.1.1
192.168.1.1/32
Blacklist
A Blacklist is a list of IP addresses that are not allowed to visit your site. Enter a list of IP addresses, separated by a space or a carriage return, that you want to prevent from visiting your site. The following are acceptable formats:
192.168.1.1
192.168.1.1/32
Content Flushing
Enable content flushing
Allows SiteSpect to partially flush content before receiving the full origin response. When checked this feature is enabled; unchecked, the default, it is not.
Flush URL's that match RegEx
SiteSpect attempts to flush content for any responses that match this URL (regular expression). Note that the hostname is omitted; specify only the path and file (e.g., /path/xyz/file.asp).
Trigger flush upon finding content that matches RegEx
After identifying a URL to be flushed (based on Flush URL's that match RegEx field), SiteSpect searches for a RegEx string within the partial content that has been returned from the origin server. SiteSpect looks through a fixed number of bytes (defined by Search depth (bytes from top of file) for location flush RegEx field) and then attempts to match the RegEx in this field. If a match is found, SiteSpect flushes content.
Search depth (bytes from top of file) for locating flush RegEx
SiteSpect searches for the RegEx (defined by the Trigger flush upon finding content that matches RegEx field) in the first block of response content, defined by this field value. For example, if the field is set to 2000, then SiteSpect searches for the RegEx in the first 2000 characters (bytes). The default is 7000 bytes.
Insert HTTP header (name) when a URL is flushed
If this field is defined, SiteSpect inserts an extra HTTP response header when flushing content. This field defines the name of the header. This can be used for diagnostic purposes and/or for signaling to a downstream proxy or sniffer that SiteSpect flushed the response prior to the origin fully completing its response.
Insert HTTP header (value) when a URL is flushed
If this field is defined, SiteSpect inserts an extra HTTP response header when flushing content. This field defines the value of the header. This can be used for diagnostic purposes and/or for signaling to a downstream proxy or sniffer that SiteSpect partially flushed the response prior to the origin fully completing its response.
When saving changes, copy logging & performance settings to related Domains.
If this box is checked when saving changes, all logging & performance settings will be copied from the current Domain to those selected from the list of related Domains (the list will appear if the box is checked.)
Header Control
Response Header Manipulation
This feature lets you manipulate the HTTP response headers sent by the back-end web server. The following are the macros available for the value fields:
{SITE_ACTIVE}: 1 if the site is active, 0 if the site is set to passthrough
{CLUSTER_ID}: the ID of the cluster of the engine that is responding to the request
{NODE_ID}: the ID of the engine node that is responding to the request
{SERVERGROUP_ID}: the ID of the server group of the engine that is responding to the request
The most common use of this feature is to add a P3P policy tag.
Example 1: Set a P3P Policy
Rule: Append
Name: P3P
Value: CP="NOI DSP COR LAW NID CUR OUR NOR"
Example 2: Define a Persistent Cookie
Rule: Append
Name: Set-Cookie
Value: COOKIENAME=COOKIEVALUE; path=/; domain=.company.com; expires=Fri, 15-Dec-2010 23:59:59 GMT
Example 3: Define a Session-Only Cookie
Rule: Append
Name: Set-Cookie
Value: COOKIENAME=COOKIEVALUE; path=/; domain=.company.com
Options
- add: The header is added to the bottom of the existing set of headers (even if this header already exists.) This can result in two or more headers having the same name. When two or more Set-Cookie headers specify the same cookie name and path, the browser accepts the last one in the header. This means that you can override a back-end cookie by specifying a different value here.
- append: The header is appended to any existing header of the same name. When a new value is merged onto an existing header it is separated from the existing header with a comma.
- set: The header is set, replacing any previous header with this name. If there are multiple preview headers of the same name, all will be replaced.
- unset: The header of this name is removed, if it exists. If there are multiple headers of the same name, all will be removed. This operation permits a Name, but no Value.
The default is:
Append RTSS {SITE_ACTIVE}-{CLUSTER_ID}-{NODE_ID}
Delete Header Regex
A regular expression that is evaluated against all request headers. Any header that matches is removed from the request. The regular expression is automatically made case insensitive.
Response Location Rewriting
This feature allows you to rewrite Location headers sent on the HTTP response from the back-end web server. It facilitates specialized handling of web systems that redirect the visitor to alternate domain names. You can also use it for customizing the interactions that may occur with intermediary systems such as Akamai EdgeSuite (e.g., with the Akamai redirect-chase feature enabled). When checked this feature is enabled; unchecked, the default, it is not.
Request Header Manipulation
This feature lets you manipulate the HTTP request headers sent to the back-end web server. The following are the macros available for the value fields:
{SITE_ACTIVE}: This is 1 if the site is active, 0 if the site is set to passthrough.
{CLUSTER_ID}: The ID of the cluster of the engine that is responding to the request.
{NODE_ID}: The ID of the engine node that is responding to the request.
{CLIENT_IP}: The IP of the client request.
{SERVERGROUP_ID}: The ID of the server group of the engine that is responding to the request.
Options
- add: The header is added to the bottom of the existing set of headers (even if this header already exists.) This can result in two or more headers having the same name. When two or more Set-Cookie headers specify the same cookie name and path, the browser accepts the last one in the header. This means that you can override a back-end cookie by specifying a different value here.
- append: The header is appended to any existing header of the same name. When a new value is merged onto an existing header it is separated from the existing header with a comma.
- set: The header is set, replacing any previous header with this name. If there are multiple preview headers of the same name, all are replaced.
- unset: The header of this name is removed, if it exists. If there are multiple headers of the same name, all are removed. This operation permits a Name, but no Value.
Example 1 - Define a persistent cookie:
Rule: Append
Name: Set-Cookie
Value: COOKIENAME=COOKIEVALUE; path=/; domain=.company.com; expires=Fri, 15-Dec-2010 23:59:59 GMT
Example 2 - Define a session-only cookie:
Rule: Append
Name: Set-Cookie
Value: COOKIENAME=COOKIEVALUE; path=/; domain=.company.com
Alternative Proxy Setting
This setting maps incoming requests to the back-end server. It adds a ProxyPass directive to the system to support a cross-domain redirect. This setting enables the Origin Experiment type URL to direct certain requests to a different domain. If SiteSpect finds a value specified in Alternative Proxy Path, it directs it to the domain specified in Alternative Proxy URL.
Alternative Proxy Path
A path that SiteSpect looks for in the URL of an incoming request so that it can direct that request to a different domain. SiteSpect looks at the URL of an incoming request to see if it contains the value provided here. If it exists, SiteSpect directs that request to the domain provided in the Alternative Proxy URL field. SiteSpect allows a comma-separated list; any API request that specified a comma-separated list of paths must also specify paired values for the Alternative Proxy URL field.
Alternative Proxy URL
Alternative domain (including the protocol) that SiteSpect uses to change the direction of an incoming request if it contains the value specified above in the Alternative Proxy Path field.
History
The History tab lists any actions take on the selected Site. It lists the date and time of the change as well as the username of the person making the change.