Section VIII - Server Configuration and new settings related to XPages 8.x resources 

Table of Contents | Previous Page

Introduction to this section

The following section discusses specific server configuration settings and recommendations from an infrastructure perspective to help achieve maximum efficiency for your Domino 8.x server environment.

Domino Web Server

Domino provides an excellent HTTP server that can support servlet, html, cgi, NSF based applications and now XPages. For the most part, the settings for Domino as a web server don't change because of using XPages. However, there are a few areas that will impact XPage experience or performance. For all the Domino server's web settings see the Domino wiki or Administration help.

Note about partitioned servers:
This issue was resolved in 851 so upgrade if it will impact you. The issue is where an application can not be opened on the partitioned servers on AIX and UNIX systems. This is cause by problems with recognizing the correct directories, the work around was to Change the permission to "rwxrwxr-x" for both the "xsp" and "ps" directories after they were created in /tmp directory.

As an administrator you should focus on the following points:
- Domino security for XPages developer
- Internet sites
- Global Web site
- SSO
- Rules

Domino security for XPages developers

For the administrator side, the XPages security is located in each server documents, on the Security tab. We want to stress again that all security fields concerning agents are applied top-down from the Domino server point of view. So if you are listed in the very first field that does mean that you are authorized by default in all other fields. So if you do authorized a developer to sign an XPage, all subsequent security is available to him. moreover you do not have to add the server (corresponding to the named server in the server document) nor "Lotus Notes Template Development/Lotus-Notes", whatever you do they do have the authorization on all fields.

For performance reason you should not add anybody in the field "Sign libraries", doing that is impacting webqueryopen and webquerysave agents that use LotusScript libraries. Effectively each time an agent of this type is ran, Domino will try to validate the execution rights for all libraries used by the agent. So if all agents run concurrently you will have performance issues on heavily used servers.

For the designer side, you just have to define the normal access for the application and ask the administrator if he has enabled your Lotus-Notes account to sign XPages to be able to run on the Domino server. You do not have to care about that on the local Lotus-Notes client as far as you have defined a correct ACL for your tests. We suppose you are manager of your local database of course.

Security tab on the server document


To greatly simplify your administration, we recommand to only fill the first field "Sign or run unrestricted methods and operations", as a rminder these fields are read top down and aggregated by the Domino server. Thas means that if you define the very first field, all subsequent restrictions will apply including all preceding content. The only exception is for the field concerning the libraries signatures. This last field should be left empty if you have many WebQueryOpen and WebQuerySave agents that uses many libraries (that concerns only old fashioned Web development with Domino, not the XPages utilization).

Internet Sites

The advantage of using Internet Sites is to simplify management of Internet sites in your Domino domain. One easy explanation is to simplify web management within Domino. Using Internet sites makes web management easier and facilitate any recovery on another Domino server if you have correctly replicate and synchronized all files and configuration amongst all your Domino servers. Before activating Internet web sites you do need to properly configure your DNS. Effectively you have to create SMTP Internet site defining host names and IP addresses of your Domino server. You can define exactly if your web sites are defined to run on all servers or just a group of servers of your Domino domain. All web configuration are grouped this way, a Domino administrator has a simple way to manage web configuration according to host names. Moreover developers can then use substitutions defined at the the domain level or at one host level. For instance you can define "rsc" as a substitution for a Lotus-Notes Databases containing all resources for your web sites. So any design can use "/rsc/" to access a resource file instead of managing parameters in profiles or in a parameter document.
Each web site can refine this substitution at their very own level if the global setting is not suitable to a specific web site.
Each web site can have its proper configuration.

So you can say, what for? Imagine that one web site requires UTF-8 and another requires Windows character set. In the old fashioned Domino world one must modify the server document. In that way, there will be an incompatible function. If you do use Internet site, you just have to modify the concerned Internet site based on the url. It will be easier to maintain and also easier to develop.

A simple example can be: on one site your SSO will need to have a ltpatoken from WebSphere while another one will only need a Domino key?
You cannot ignore Internet sites in a Domino clustered environment. That will assure you that both Domino web server will be configured identically. The only required operation is to verify that all servers do have an accurate replica of all databases and system files if needed. I will not restrict this great functionality to Domino clusters. Effectively in a huge Domino environment (with more than 2 servers for instance) it can be a great way to replace a down server with another just to respond to http request.
 
In a complex architecture, you should use an http balancer (or even the Domino ICM for Domino clusters).

In one word Internet sites are the solution to configure all HTTP Domino servers at only one location instead of modifying many server documents.

SSO

Single Sign On is really important in Domino environment. First of all you need to know the architecture of your Domino web site(s). Domino web sites are based on FQDN (Fully Qualified Domain Name). In Domino the Single Sign On is based on your Internet domain name. According to your needs you will use an existing key (from WebSphere for instance) or create a Domino one for all your participating servers.

Global Web site

A global web site is simply a document which will have as many related rules document as needed (file protections, web site rules, etc....) and the goal is to define rules to facilitate Internet sites management. A rule that can be used for all Internet sites used by all the Domino servers of your domain.
Many administrators are using that for redirecting all users to their mail file with a single FQDN or simpler with a redirection (for instance: Mymail, url redirects to iwaredirect.nsf for all users).




As you can see we just can use global rules for directories or URL, it will be easier for the developers to use /yui instead of the complete path (which can sometimes be outside of the domino directory!)

Web site document

As you can see there can be Internet sites dedicated to one organization (for normal or xSP Domino organisations) or any name that will help you categorize or use your configuration, organization name does not matter for Web sites

A simple screenshot of the configuration for a web site:



This is a capture of the second tab which contains parameters that can be important in XPages performance:

GZIP provides a compressed file to the browser so to reduce the transit time.

To use GZIP both compressed and non compressed file need to reside together on system file structure and not in a Domino database. The name of the compressed file needs to be the same as the original with ".gz" added to it. For example for dojo.js the gzip would be dojo.js.gz, If you want the server to automatically create the GZIP file for you then Enable Create Compressed files. The server will compare the time-stamp of the file and it's GZIP version and create a new GZIP if the file version is newer. the Using gzip compression will gain time. But according to your server performance, you do have to analyze the "Wait time out", if this time-out is reached, the Domino server will send back the non-compressed file instead. So if you had a large CSS file called SiteStyle.css it would have a gzip version called SiteStyle.gzip. The GZIP is sent as one file and can't be done with ranges.

The settings can be done in either the NOTES.INI or on the Web Site Document. They are mutually exclusive, the NOTES.INI is for sites without web site documents.

On the Domino Web Engine tab you need to enable Compressed output for the GZIP support.

You can also do it an other way by modifying the xsp.properties file (see last section of this chapter) for XPages.

Rules

All rules are related to a web site document. Any developer can be informed which rules are available. If rules or Internet sites are not already deployed, you should talk to the Domino administrators to get it working, explaining all benefits from using the Domino Internet Sites for them and also for the Lotus-Notes designers.
 
A problem can arise with Sametime and QuickR which do not use the Internet site configuration. But solving that point is really easy for a Domino administrator. 
 
You can use the rules to do substitution, redirection, control the headers and even override the session authentication. It's here that you can adjust how the HTTP server responds to URLs. The rules are used to process the incoming URL before the HTTP server process the URL. You can use wildcards to allow the rule to apply across applications. The "?" replaces one character and "*" is anything. An example would be /docs/*, this would cover any URL that referenced anything in the /docs/ path. You have to take care because the rules are all applied in the order listed in the Internet Site view.

Rule Substitution

Substitution rule lets you replace just part of the URL with different values. This can be used to masks the actual file path of the Notes application. When an incoming URL contains a matching pattern that value is replaced and then processed by the server. The user doesn't see the resulting URL like they would with redirection. Do be careful, the web site's rules are all processed sequentially from the view, so you could inadvertently have a rule will affect a following rule.
Sample: Rule (substitution): /notesini --> /doc/notesini.nsf - with an incoming URL of www.kalechi.com/notesini the rule will change the URL to www.kalechi.com/doc/notesini.nsf and pass it to the server.

Rule Redirection

Redirection will redirect the the browser to a new URL. This can be used when you have moved an application to a different folder as part of a site upgrade or to have a URL that would be easy for the user to type in such as www.kalechi.com/jobs. You would then create a redirect rule to send the browser to the actual URL of the job posting applications.
Rule (redirection): /Jobs--> /HR/jobrequests.nsf?open

This rules will let me get my mail with the url: www.kalechi.com/bruce

Rule Header

Header rules are the only rules that are applied to the HTTP response instead of the incoming URL. The Header rule allows the developer to change aspects such as an Expires header or add custom headers to HTTP responses. One of the biggest uses is to set the cache control for files sent to the browser. You can set images, CSS, JavaScript files to have a longer life in the browser's cache or you can set them not to cache.
The Header rules need a matching URL and the HTTP response codes to match before it is used. This can let you build special error messages for a specific site location or for the entire site.

Rule (headers): *.png* 200;206

Sample Cache control for CSS files

Rule Override Session Authentication

In this case, there may be times that you need to allow a application have basic access instead of session access. WebDAV and web services are to type of access that need basic authentication to work. This rule would allow the URL to be accessed using basic authentication.
Rule (Override Session authentication): /wd.nsf/* - allow WebDAV access to the wd.nsf database.
Rule (Override Session authentication): *?OpenWebService - allow all web services to have basic authentication.

Rule Directory

Directory rule give access to a system level file directory that can be relative to the data directory or located elsewhere by entering the full path. The directory rules is similar to the Substitution rule, except here you can specify the type off access allowed. The rule lists you select a CGI program to run so you would select the Execute.access level to allow PHP.exe to be run from a URL allowing you to have a PHP enabled site.

You could easily select which version of dojo to use by just changing the Directory rule.

File Protection

This document is really important in a secure environment. Currently you do have to define protection on all Internet Sites because you cannot define a global file protection, so if you do need to protect a specific directory and ensure no one can access it, you should protect it.


In our example, the current access is by default set to "No access" if you do belong to administrators group or specific access group you will gain POST and GET or only GET privilege.

Authentication Realm

Authentication realm is only used in non Internet Sites configuration and when basic authentication is needed. To simplify the authentication process you can define one realm that stands for all you web site. So the navigator will be asked to authenticate to the realm instead of the path of your web resource. So the browser will only see that the server will ask authentication fro your realm.

So if the user need to authenticate the browser will ask him a login an password for "Hello Microsoft" realm. Once your are done, for any resource located in another path on the same server (IP Address), if the browser had stored your password, you will not see the authentication dialog box again.

Domino cluster environment

Web configuration vs Internet Sites configuration.
Correct SSO amongst Domino servers in a domain
Global web rules vs Sites rules
 
We suppose the Domino cluster is correctly setup and running.  To avoid any problem you should verify (when using multiple IP addresses) that your notes.ini and server document is fine.
We recommend to always use a non IP dedicated Lotus-Notes port and to define it before any Lotus-Notes port. That port should never have a defined TCPIP address. For instance in a three network interfaces Domino architecture, you should have



that way you are sure that SMTP will listen on ALL Domino and Notes ports, the order is really important. There is normally no impact on the XPages web server, but having a clean Domino architecture is better.
 
 
 

Web configuration vs Internet Sites configuration

 
As we mentioned it before, in a Domino cluster environment it is recommended (quite mandatory indeed) to use the Internet Sites configuration instead of Web configuration. In a cluster environment, the Internet Sites configuration is the only way to maintain a coherent Web configuration for your Domino servers.
Moreover, you will be able to define all url for developers and administration. Instead of using long URLs you will be able to use short and easy to maintain user defined URLs.
For security (access to dedicated directories) you can modify the home url, so all files referenced in the code will be relative to these definitions. The only exceptions are the Lotus-Notes databases (.nsf), any reference to a nsf file will be referenced from the root data directory. So using a rule for substitution can simplify greatly the call to NSF files. For instance you can define a URL called "/MyBase" which will be substituted to "ApplicationDir/LongSubDir/Another/base.nsf" by the Domino server. The Lotus-Notes designer will only have to use the short version of this URL. In a complex architecture you can then define an Internet site specific to one host name, for example: dev.itso.com (development web site), nextstep.itso.com (validation web site), www.itso.com (production web site). All these sites can use their very own environment rules and combined also general rules of your Domino web server. Another interesting point is to use that functionality for Intranet and Extranet access.
 
Is setting up Internet Sites configuration complicated? No you do need to follow the IBM recommendations. Internet sites using IP addresses and default web sites should be at the bottom of the list. For web sites, you can use specific organization which will allow you to categorize your different web sites together to simplify readability. 
 
If you still want to use the web configuration feature, any time you will add a new Domino server, you will have to completely configure it the same way all others are. While using Internet Sites configuration, you only have to enable this configuration on the server document, and add this new server in all SSO and web site this server is supposed to join and participate in.
 
Internet sites configuration needs just one simple thing to work properly: the authentication method should be set to Single Server or Multiple servers (SSO). If not your users will be prompted to sign again and again if your resources are not located on the root directory. Defining a Real document at the server level is insufficient for correct authentication throughout the whole site.  
 
 
Always keep in mind that creating a new Internet site is simpler than modifying the server document and having to validate again all http access to your Domino server. For instance if an XPages developer ask you to add the whole new Dojo toolkit for testing using WebDAV, you will really be embarrassed to do that in production. As a reminder, WEBDAV needs "Basic Authentication", so if you have not set up Internet sites, you would have to explain to all users why they have a stupid Windows look alike dialog box for authentication. On the other hand using Internet web site will be completely transparent as you can define a new host name and a brand new web site for your beloved developers. 

Correct SSO amongst Domino servers in a domain

 
For single sign on across your Domino servers. The very first step is to list all Internet domain you want to use. You will not be able to use the IP address to be able to login anymore (for HTTP and HTTPS only). Connecting with http on the IP address will not allow you to login and you will be prompted to type in your login name again an again. Once you are done, you just have to create your documents. If WebSphere is used, you will have to import your ltpatoken from WebSphere, that's all. Each Internet domain will require one SSO document, so you do have to list all the domino servers which participate to the SSO your are planning.
 
Theoretically you can only create SSO documents for Domino servers in the same domain. But technically you can. If you do have multiple Domino domains and you do want to have one SSO for all Domino servers in all Domino domains, you just have to copy and paste server documents in one location, We recommend one neutral names.nsf to be used. Why, just because when you add the servers to the list of participating servers, during the saving process, Domino will use the public key of the servers to encrypt the token. When - in a multiple domain environment - you are done, you just have to copy and paste in the correct names.nsf databases the SSO documents and voilà you're done.
 
Another problem arises too, the administrator that saves the document is by default the only person capable to modify the Token if needed. We recommend to add all administrators that could possibly edit and modify the SSO configuration. This is an automatic or a manual process. To simplify the administration, you should add any administrator in the Administrators field document (leave the owner as owner), or in the view, do a right-click and on the security tab, add the names you want to give access. This last possibility is not a really good solution - even if it works - just because many administrators will never go there. 
 
The bad news 
Even if SSO is simple to set up on Domino, you do have to verify some specific points. 
First of all, the time synchronization. If you do not use any NTP server that will cause you many SSO errors, you should not have more than 2 minutes (TWO minutes) delay between servers in the same time zone.
So all your Domino servers (participating or not in a SSO configuration) should be synchronized with an available time server (internal or not). Debugging a SSO configuration is easy, probably not in a production environment of course. You just have to add a notes.ini variable.
You have to define a value for Debug_SSO_Trace_Level. I personally use level 2, but depending on the information you do want to collect, here are the different values:
 
- 0 : no debug (simply remove it from notes.ini please)
- 1 : debug information as tokens are generated and verified
- 2 : verbose memory dump while tokens are generated and verified
- 3 : all information

You can then trace and see why your SSO configuration is not working.
Last but not least, if you do use WebSphere portal, remember that Domino 8 is LTPA-2 aware, so you do need to completely verify any security issues between WebSphere and Domino access.

Tracing Domino http requests

To trace Domino HTTP requests you do have to execute the following commands

tell http debug session on
tell http debug thread on
tell http debug postdata on
tell http debug responsedata on

You need to respect the order for activating the trace of these informations.

Those commands will generate h*.log files into the IBM_TECHNICAL_DATA folder of your Domino server.

To disable the logging you will need to run these commands:


tell http debug session off
tell http debug thread off
tell http debug postdata off
tell http debug responsedata off

the order of execution does not matter for disabling the HTTP trace.

You should not execute these commands in a heavy loaded Domino environment.

Because you are using Internet Web Site configuration on Domino, you should disable the TRACE option on your production Domino servers (you are recommended to keep it alive on you test servers). You can disable it on all Internet site. But there is another better way: use a notes.ini variable HTTPDisableMethods=TRACE. This way you will impact all your Domino Internet sites. As a reminder you should define this variable in configuration documents, in case you cannot access the notes.ini file or you are not allowed to use live console on your site (We do suppose you can modify Configuration documents in the public address book of course).
For personal interest these are all methods you can disable using that notes.ini variable:

• GET
• HEAD
• POST
• OPTIONS
• PUT
• DELETE
• TRACE
• CONNECT

Server Directories

This chapter tends to sum up some directories we talked about in design section of this redbook
You do have to take a close look to tow main directories and all the sub folders they do contain.

First directory is located in the Lotus-Notes or Domino directory:



The other one is directly in the data directory of Lotus-Notes or Domino installation

XSP folder

The XSP folder is located in the root Domino directory (in the binary directory for the Domino server). So this is why it can be hard to handle correctly multi-hosting web sites with Domino if you let the developers modify the internal Domino files. 
Themes are located in the xsp/nsf directory, the OneUI V2 theme is missing there, you will need to copy it from the data/domino/html directory back into the Domino/xsp/nsf/Themes directory if you do want to replace simply the theme without taking care about maintaining version 1 or version 2. You should not do this as V2 is currently in beta state. Some more information will be described below.
The main difference between DOMINO 8 and Domino 8.5 is that the properties files are located in the binary directory for 8 and in the data directory for 8.5. The properties file are not active by default. The extension is .sample, so you just have to copy them without the extension and then restart the HTTP task after you have modified them. The main problem in a Domino clustered environment is that after any modification you do have to propagate these files on all participating Domino server of the cluster. You do not have to worry about upgrading to Domino Next because the standard files in the IBM package is the samples files.

Dojo

Dojo is stored by support versions which with 8.5.1 is dojo-1.3.2. If you upgraded from Domino 8.5 you may see the folder dojo-1.1.1 also. Dojo is stored in the server's data folder under:
\data\domino\js\dojo-1.3.2

The dojo resources available in the dojo toolkit are as follows:

\data\domino\js\dojo-1.3.2\dojo - core dojo classes
\data\domino\js\dojo-1.3.2\dijit - dojo UI components (dijits)
\data\domino\js\dojo-1.3.2\dojox - extended dojo classes
\data\domino\js\dojo-1.3.2\ibm - IBM classes used by XPages and classic web rendering

From the web the latest dojo release is redirected to:
/domjs/

This redirection is defined in the website document.


Use the /domjs/ on your web pages if you are accessing the dojo toolkit directly.

The template directory used to modify the headers when you include an IBM modified dojo widget on the page is::
\data\domino\template\dojo-1.3.2

Here you will see the header includes used for the actionbar, outline, view, richtext editor and common include html file.

If you are using IIS for Domino you also need to verify the file plugin-cfg.xml, if the URI is correctly set for XPages AND Dojo:
You do need to find the entry and under it verify that these URIs are defined

<Uri Name="/domjs/*"/>

<Uri Name="/xsp/*" />

So if you decide to use your very own Javascript Path instead of /domjs, do not forget to update the plugin-cfg.xml, even if using Microsoft IIS is currently out of question at your Company site, do not forget that sometimes we do need to work with Microsoft products.


You can also change the Dojo version (at your own risk) using the xsp.properties file. The file location is indicated furthermore in this chapter. To simplify this chapter information we've take the information from the xsp.properties (by default xsp.properties.sample):

# #######################################

# CLIENT SIDE JAVASCRIPT

# #######################################

# The version of the Dojo Toolkit to use. 

# By default the Dojo version is detected by examining the folder 

# Data/domino/js/ for subfolders with names like dojo-<version>,

# and using the latest version available.

# Change this setting if you are installing different versions of Dojo

# in that folder and you need XPages to use a specific version.

# Note, using XPages with a Dojo version other than the default is unsupported;

# if you do so you will need to test for compatibility problems.

#xsp.client.script.dojo.version=

# Add parameters to the djConfig attribute of Dojo.

# Useful to switch Dojo to debug, using for example:

#   xsp.client.script.dojo.djConfig=isDebug:true

#xsp.client.script.dojo.djConfig=

You can modify two lines of code to debug Dojo, the first one is "xsp.client.script.dojo.djConfig=isDebug:true" you can uncomment.
If you do have develop your own widgets you can use another option "xsp.client.script.dojo.djConfig=debugAtAllCosts:true"

Xsp properties files

 
Three properties files are available in the /properties directory. All files have the sample extension and will be overwritten during all upgrades of the Domino server and client. So to effectively use these files you just have to remove the ".sample"  and restart the http task after your modification have been applied to the files. The files are:

• xsp.properties 
• acf-config.xml
• proxy-config.properties 

Xsp properties file

Many sections are available to help you tune-up and configure globally your Domino server. Before talinkg about performance, we do prefer to talk about errors. Even if your development environment needs to show xsp errors, in production you should really configure a global error message to avoid that.
 

Managing errors

You can manage user errors in XPages code. But in some context the Domino Web server will throw an exception (for instance you made a mistake using the @DBLookup function). In that particular case and in a development environment it can be fine, but in a production environment you can choose between a very simple error generation page or a friendly error message that will help you debug the application without knock the user senseless with tons of non comprehensive internal error messages.
You can modify the server configuration by editing the xsp.properties file and select one or two options to avoid run-time error messages to be displayed to the end-user.

# #######################################

# ERROR MANAGEMENT

# #######################################

# Defines an XSP specific error pages

# When not defined, it displays a default error page

#xsp.error.page=

# Defines if the default error page should be displayed by the XSP layer

# This is very useful in development as it displays extra information on the error

#xsp.error.page.default=false

Uncommenting the xsp.error.page will help you define a global error page like you have already done in normal HTTP error management in Domino (for Domino web server the HTTPMultiErrorPage notes.ini variable allow you to define an error page to display instead of a bad 404 error message when a non Domino resource is called and not present on the server).

This is global to the Domino server, you you do want to keep the normal run-time error processing on Domino, you can then uncomment the xsp.error.page.default, setting this value to false instead of true, you will have less information.You should not modify these values on development and pre-production environments during tests. In a production environment, you have to choose the way run-time errors should be managed. This is a global parameter. So if the designer is not managing errors, your global error management will be in use. 
 

Setting default theme

By default Domino is using the webstandard.theme located in \xsp\nsf\Theme directory located in your Domino server. If you want to add (or use) another themes, you can simply copy the theme files into this directory. You should not modify the IBM themes if you are planning to upgrade your Domino servers, but remember you can inherit from IBM themes via the extend keyword in the theme file (any theme can inherit from any other theme, so you should document that).
The theme section in the xsp.properties file is simple, and you now can define one theme for Web clients and another theme for Lotus-Notes client.

# #######################################

# THEME

# #######################################

# Name of the XSP theme to use

#xsp.theme=webstandard

# Name of the XSP theme to use when running on the web

# If this property is not defined, the xsp.theme is used

#xsp.theme.web=

# Name of the XSP theme to use when running on the notes client

# If this property is not defined, the xsp.theme is used

#xsp.theme.notes=

The xsp.theme variable is the default theme you want to use over all your applications. To ease designer pain you can use the two other variables to be able to distinguish Notes and Web interface theme. 
 

Session Performance

If you do want to modify the XPage session time-outs without impacting your normal Domino Internet sites, you can define a different session time-out limit for XPages

# #######################################

# TIMEOUT

# #######################################

# Application timeout management

# Defines when an application is discarded from memory after a period of inactivity

# Expressed in minutes 

#xsp.application.timeout=30

# Session timeout management

# Defines when a user session is discarded from memory after a period of inactivity

# Expressed in minutes 

#xsp.session.timeout=30

According to the frequency user access some XPage application you can enforce Domino to not discard an application from memory when it is not used anymore.
By default the application remains in memory 30 minutes after last access. You have to analyze your server configuration and platform to define correct values. If you do not have an overloaded server and find out that the very first access to your application is slow you should define a greater value. For the user session, it depends on the session management policy you do have set up for your system. It should be defined equally between XPages and Internet sites, but XPages sessions can be managed differently within your company.

All these options should be combined with persistence of JSF files (section JSF PERSISTENCE) and also with the method you will manage the gzip compression (section HTML PAGE GENERATION)

Code Performance

Optimizing the code is normally done by the developer. But if you take a close look to Dojo and XPages you can see that some code is downloaded frequently by the client. The very first optimization you can define is the compression (gzip), we already presented to you in a preceding part of this section.

So to activate the gzip compression at the core level, you can modify the compression section (HTML PAGE GENERATION) in the xsp.properties file:

# #######################################

# HTML PAGE GENERATION

# #######################################

# XSP compression

# this defines the compression mode used when a page is rendered to the client

# the compression is effectively enabled when the client supports it, as specified in the HTTP header of the request

# the possible values are

#    none

#    no compression at all

#    gzip

#       the response contains the content-length header, which forces the data to be buffered. this is the prefered mode

#       and is required to support HTTP 1.1 persistent connections.

#    gzip-nolength

#       The content is compressed but it doesn't compute the content-length, thus it doesn't need to buffer the result.

#xsp.compress.mode=gzip

....

If you compare to the Internet site configuration, this option just concern the XPage compression mode. You can use this method to enforce it or not.
If you have activated persistent session, you do have to use the gzip value. More options can be defined in this section like encoding, redirect (sending code 302), the equivalent of the field $$HTMLFrontMatter (defining the doctype via the xsp.html.doctype value).

Server performance

You can define JSF persistence for your XPages on the server, to optimize the overall functionality of your XPages applications. Mixing persistence and gzip will help you increase response time of all XPages applications.

acf config xml

This file can be used to get rid of malicious code. Advanced iNotes users are accustomed to the ACF (Active Content Filter), as they do use the notes.ini variable iNotes_WA_DisableActCntSecurity=0, setting this variable to 1 can help increase security (By default this value is not present and the default value is inactive "0"). For XPages, you can mimic that functionality by editing the acf-config.xml file.
For instance, you can get rid of the script tag, defining this rule in the acf file:

<rule tag='script' action='remove-tag' />

You can add your own rule for some specific context, the sample file looks like

<?xml version="1.0"?>

<!-- Active Content Filter (ACF) configuration file -->

<config>

    <filter-chain>

        <filter name='base' class='com.ibm.trl.acf.impl.html.basefilter.BaseFilter' verbose-output='false' use-annotation='true' />

    </filter-chain>

    <filter-rule id='base'>

        <target scope=''>

            <!-- C14N rules -->

            <rule c14n='true' all='true' />

.........

        </target>

    </filter-rule>

</config>

As a reminder the C14N is a canonical XML (14 letters between C and N in' Canonicalization') draft describing a method to rewrite namespace in XML.

proxy config properties

This file will help your code AJAX extension to connect to a service or a server that do require access through a proxy. iNotes and QuickR users already modified that. By default the proxy is not enabled in the XPage extension of the Domino HTTP server task.

The default content of the sample file is as follow:

# Test properties for proxy policies

enabled=true

connectTimeout=10

policy0.url=http://www.google.com/

policy0.context=/xsp/proxy/GoogleProxy/

policy0.actions=GET,POST

policy0.cookies=

policy0.headers=*

policy0.mime-types=*

policy1.url=https://www.google.com/

policy1.context=/xsp/proxy/GoogleProxy/

policy1.actions=GET,POST

policy1.cookies=

policy1.headers=*

policy1.mime-types=*

# policy2.url=http://your_quickr_server:10038/

# policy2.context=/xsp/proxy/QuickrProxy/

# policy2.actions=GET,POST

# policy2.cookies=LtpaToken

# policy2.headers=*

# policy2.mime-types=*

We urge you to consult the QuickR wiki page for a simple and efficient explanation: [http://www-10.lotus.com/ldd/lqwiki.nsf/dx/05132009064114PMWEBULW.htm|QuickR wiki access]
The time-out is by default of 10, so you can change it if not sufficient in your environment.