There may be cases when part of your application content is not intended to be handled by MCS, either because the content is rendered by another process, or because certain devices require different handling.
There may be cases when part of your application content is not intended to be handled by MCS, either because the content is rendered by another process, or because certain devices require different handling.
In the optional servlet-filter section of the mcs-config.xml file, you can configure a filter based on the Servlet 2.3 API. The filter identifies device requests that are to be excluded from MCS processing, and also ensures that MCS handles only responses with XDIME content. Requests that are excluded, and responses that are not XDIME, are passed through without modification.
This section also contains the default scope for XDIME page caching in the page-cache element.
The servlet filter intercepts all requests and continues to process them, unless you have excluded a device or one of its parents in the device tree, using the required name attribute on the exclude-device element.
If a device is not excluded, the filter sets the correct character encoding for the device on both the request and the response.
In the value attribute on the mime-type element, you specify the MIME type the servlet filter will treat as XDIME.
The MIME type values in the mcs-config.xml file are provisional, and can be configured for a given application, so long as they uniquely identify the response as an XDIME document. These content types may be changed, or be superseded by a registered type.
The page-cache element contains the default-scope attribute which contains a global scope setting for XDIME page caching. The default value is 'none'. Authors can override this value with scopes for individual pages, using the cacheScope attribute on the canvas element.
The jsessionid-name attribute on the servlet-filter element contains the session ID label used by the MCS web application server. MCS uses this value to identify session IDs in content URLs and substitute a replacement value before a page cache key is created. So pages with different IDs will be reused if the IDs are the only content that changes. However, if a page contains multiple IDs from different contexts, new cache entries will always be made, defeating the purpose of caching. If a server produces variable length IDs for any reason, there may be problems in rendering fragments correctly.
<servlet-filter
jsessionid-name="jsessionid">
<exclude-device name="PC"/>
<mime-type value="x-application/vnd.xdime+xml"/>
<mime-type value="x-application/vnd.volantis.xdime+xml"/>
<page-cache default-scope="none"/>
</servlet-filter>