This documentation is for an outdated version: 14.5.0. The current version is 14.6.17 - get the documentation here.

Delivery Context Detection Page

Detection

FIT uses the CDR to determine the best way a document should be served to a client, but sometimes the static data can not reflect the real circumstances of a pending request. By dynamically determining the actual client area real estate, for example, a document can be better optimized for the current rendering situation, taking into account the current setup of the client. This is achieved by sending a snippet of JavaScript code to calculate and store more accurate information about the client. Subsequent requests are adapted to the new properties automatically.

To obtain these properties also for the very first request, FIT can send the Delivery Context Detection Page, which is a minimal HTML page containing the respective JavaScript before rendering the actually requested content with the best Delivery Context values possible.

Detection Cookies

These cookies are set by the JavaScript which is used to detect the accurate values:

fitreferrer: Original Referrer

Contains the URL of the referring document the client came from. It may be used to feed statistic tools.

Technically, this cookie will be stored for 30 days. However, FIT removes the cookie upon the next request, as it is only needed to provide the missing Referer header when the Detection Page is used.

fitdetection: Detected Values

Makes technical information about the user’s Web browser, like viewport width and height, available to the server software. The cookie does not contain any tracking information.

This cookie will be stored for 30 days

Format: at least 16 parts ending in ‘:‘. The system parts in the following order are:

  1. version. Must be 6.
  2. viewport width portrait. The viewport width in portrait orientation in device-independent (CSS) pixels (e.g. 420). Format: A positive integer (< 10000).
  3. viewport height portrait. The viewport height in portrait orientation in device-independent (CSS) pixels (e.g. 208). Format: A positive integer (< 10000).
  4. viewport width landscape. The viewport width in landscape orientation in device-independent (CSS) pixels (e.g. 420). Format: A positive integer (< 10000).
  5. viewport height landscape. The viewport height in landscape orientation in device-independent (CSS) pixels (e.g. 208). Format: A positive integer (< 10000).
  6. viewport orientation. The viewport orientation (allowed values: ‘portrait’ or ‘landscape’). This is necessary for setting the viewport/portrait and viewport/landscape DC properties.
  7. device pixel ratio (e.g. 2). The value must be a positive number <= 30. This is necessary for creating sharp images for higher-density clients.
  8. screen width. Contains the screen.width value that can be used to improve the client/hw/display/width DC properties.
  9. screen height. Contains the screen.height value that can be used to improve the client/hw/display/height DC properties.
  10. supports history.pushState. Contains the information whether or not the client supports history.pushState(). This is needed to determine whether partial page loading is available.
  11. can parse HTML. Contains the information whether or not the client can parse HTML in JavaScript. This is needed to determine whether partial page loading is available.
  12. supports pointer events. Contains the information whether the client supports pointer events and an eventual prefix for them.
  13. supports webp images. Contains the information whether the client supports webp images.
  14. supports lossless webp images. Contains the information whether the client supports lossless webp images.
  15. supports webp images with alpha channel. Contains the information whether the client supports webp images with alpha channel.
  16. supports svg images. Contains the information whether the client supports svg images.

All other (user) parts are added by the JS Detection API and have the format key=value.

User parts are part of a beta feature.

Example:

fitdetection=6:583:983:983:583:landscape:1:1680:1050:true:true:false:true:false:false:true:foo=bar:

Detection Page requirements

For the detection page to be sent, your request needs to meet the following criteria:

  • the detection page has to be enabled in the config
  • the client must have cookies enabled
  • the cookie fitdetection must either not be existing or have the wrong version
  • the request method has to be GET
  • the urlmark apfail must not be in the request url
  • the urlmark m must not be in the request url
  • the X-Requested-With header must not be XMLHttpRequest
  • the X-moz header must not be prefetch
  • the X-Purpose header must not be preview
  • the Accept header must contain text/html
  • the DC property js must be true
  • the DC property client/bot must not be true
  • the configured include-pattern must match the request url
  • the requested resource must not be robots.txt or favicon.ico
  • the configured exclude-pattern must not match the request url

Configuration

You can enable the detection page in the ress settings in your config.xml:

<config>
  <ress>
    <detection-page />
  </ress>
</config>

The detection page config option offers multiple parameters.

  • title: changes the html title of the detection page.
  • include-pattern (optional): may contain a regular expression pattern.
  • exclude-pattern (optional): may contain a regular expression pattern.

The title parameter

The title parameter replaces the default value used as title for the detection page. The value must be a non empty string. The default is FIT14 Detection Page.

The following example shows how to generate a detection page with a different title:

<config>
  <ress>
    <detection-page title="Different Title" />
  </ress>
</config>

Note: Setting an empty title attribute results in an empty title element, creating an invalid document to be output.

The include-pattern and exclude-pattern parameters

The include-pattern must match the client request URL to allow FIT to respond with the detection page. If specified, it replaces the default, which allows any URL (think .*).

The exclude-pattern must not match the client request URL to allow FIT to respond with the detection page. If specified, the exclude pattern will be added to the default exclusions (robots.txt and favicon.ico).

Requested URLs that match both include and exclude pattern will be excluded from detection page responses.

The following example shows how to prevent FIT from responding with the detection page for every request containing /downloads/ in the URL:

<config>
  <ress>
    <detection-page exclude-pattern="/downloads/" />
  </ress>
</config>

BETA The ajax parameter

The ajax parameter replaces the default behaviour of loading the main content by an own request with an advanced mechanism to ensure the display of the actual content without having to reload. By serving the detection page within the same request, the original referrer is kept intact and can be used transparently.

Note: Keeping the original referrer intact renders the cookie fitreferrer useless, hence it will not be created.

The following example shows how to generate a detection page without requiring a reload:

<config>
  <ress>
    <detection-page ajax="true" />
  </ress>
</config>

BETA The script parameter

The script parameter takes a FIDJ URI pointing to a JavaScript file that will be inlined and executed in the detection page.

Warning: Defective JavaScript could stop the detection page execution and prevent the landing page from loading.

Example config.xml:

<config>
  <ress>
    <detection-page script="fit://site/conf/js/script.js" />
  </ress>
</config>

Errors

In the unlikely event of the client not supporting JavaScript, the page redirects to the originally requested URL, with a new URLMark fitscript=0.

In the unlikely event of the detection page not working correctly the content will be loaded with the URLMark apfail

Caveats

If enabled, the detection page can cause a HTTP redirect before the actual content is loaded.

Miscellaneous

The hardware display size of desktop clients is calculated from the detected viewport and pixel density.