A Domain describes a network path to your website. SiteSpect calls groups of Domains “Sites,” and these groups of domains share certain configuration characteristics, such as cookies. Domains in the same Site group can also share tests, variations, and metrics.
Generally speaking, each domain name (for example, www.example.com, shop.example.com, qa.example.com, …) will have its own Domain configuration.
Each Site lists its domain configurations on the Domain page for the Site. From this page, you can manage your Domain configurations, purge the cache, and get an entry to copy into your hosts file.
Many of the settings can only be set by a SiteSpect admin.
When you view or edit a Domain, the following tabs are available:
General
Front & Back End
Description
Specifies a brief description of the Domain.
Note that front end and back end are relative to SiteSpect.
Type
Specifies what type of Domain this is. The types are:
- Production
- Non-Production
- Test
- Demo
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
Note: an SSL certificate is required to create an HTTPS configuration.
Front End IP Address
Displays automatically assigned addresses used by SiteSpect to receive requests for your domain. There is one IP in each of our datacenters. Individual IPs can be disabled by unchecking that entry.
When there are both HTTP and HTTPS configurations for the same domain, they will share these and other settings.
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 SiteSpect’s internal port number where we listen 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
The back-end and front-end protocol need to match. (That is, both are http or both are https.)
Back End IP Address
This field is required, but its significance depends on whether a Back End Name is provided.
SiteSpect recommends using a Back End Name, since it provides more flexibility.
If no Back End Name is provided, SiteSpect will proxy requests to the Back End IP.
If a Back End Name *is* provided, the Back End IP will be ignored, unless the Back End Name cannot be resolved. In that case, the Back End IP will be used.
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 SiteSpect should monitor the availability of Back End host. If this is checked, our DNS Management Service will frequently ping your origin.
Back End IP Name
Specifies the domain name of the back-end web server. When specified, this value takes precedence over the Back End IP.
Perform DNS Lookups
This will cause SiteSpect to resolve the Back End Name and cache the result for the length of that entry’s TTL. Either this field or the next (Translate Hostname) must be checked if a Back End Name is given.
Translate Hostname (URL Tunnel®)
The most common setup for SiteSpect Domains is that the client’s back end is able to receive requests for the front-end name. However, there are cases in which the back end uses a different domain name, and will only accept requests for that domain.
For example, if the front-end name is www.company.com, but the back end will only receive requests for origin.company.com, this feature should be used.
When this feature is checked, SiteSpect will proxy requests to the specified domain (in this example, origin.company.com). It will change the host header and the cookie domain.
These changes are invisible to the end-user and/or to the CDN connecting to SiteSpect.
Healthcheck URL
Specifies the URL used to monitor the availability of the back-end host to SiteSpect.
SiteSpect frequently pings the healthcheck target through each of the IPs specified in the Front End IPs section. Since these requests strike SiteSpect directly, they skip over any CDN or other service that might be deployed in front of SiteSpect. In this way, they determine whether the client back end is accessible to us.
Note: Because the healthcheck target is requested so frequently, it’s important that it be as small as possible. It can be a text file, HTML, or an image file. All that matters is that it be small, and that it return a 200 status when requested.
Alternatively, the health check can be a programmatic link that returns a 204 status.
Elements that redirect (status of 30x) are not acceptable.
SiteSpect usually adds an HTML parameter to the healthcheck request (for example, /healthchecktarget.html?sshealth=1), for cache-busting. In other words, the use of an HTML parameter avoids being served a cached response.
If our healthcheck requests fail or return anything other than a 200 or 204 status, the domain will automatically be placed in bypass, which means that traffic will be routed to the Global Failover Address (see below), rather than to SiteSpect.
Once the healthcheck target becomes available again, the bypass will automatically end, and traffic will flow through SiteSpect once again.
SSL
The SSL tab specifies settings that help to manage your HTTPS certificate.
In general, only SiteSpect admins are able to use this tab. Although some users are given the SSL Uploader privilege, certificates are uploaded elsewhere.
Note: The certificate upload form is found on the Site’s list of Domains. Look for the tiny key on the far right of any HTTPS configuration. The uploaded certificate will not take effect until it has been applied by a SiteSpect admin (see Future SSL Certificate, below).
Future SSL Certificate
This field will only appear if a certificate has been uploaded via the upload form (see paragraphs immediately above).
A SiteSpect admin can apply an uploaded certificate by checking the left-pointing arrow and hitting SAVE.
Use Existing Key and Certificate
This drop-down list allows SiteSpect admins to apply another Domain’s certificate to the current Domain. This is useful when a single certificate covers several domains.
Generate New SSL Key
This function allows a SiteSpect admin to create a new CSR and private key. The private key is stored internally and is not accessible.
Note: The only time that a certificate can be uploaded on this tab, is if that certificate was generated by a CSR created on this specific tab, or if the same private key was reused when creating the certificate.
In any case, only a SiteSpect admin can load a certificate here.
SSL Protocol
Specifies which protocol SiteSpect will use.
SSL Cipher Suite
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
[This feature is deprecated.]
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.
Note: The following file types (based on URL suffix) are always excluded from compression; you do not need to explicitly define them: .gif, .flv, .jpg, .jpeg, .png, .pdf, .swf, .gz, .Z, .zip.
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.
Note: Benchmarking log files are not directly customer-accessible.
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.