Domains

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.