The 4D Web Server has a cache that allows you to load static pages, GIF images, JPEG images (<128 kb) and style sheets (.css files) in memory, as they are requested.
Using the cache allows you to significantly increase the Web server’s performance when sending static pages.

The cache is shared between all the Web processes. You can set the size of the cache in the Settings. By default, the cache of the static pages is enabled for new databases. To disable it, just uncheck the Use the 4D Web cache option.

You can modify the size of the cache in the Pages Cache Size area. The value you set depends on the number and size of your Web site’s static pages, as well as the resources that the host machines has at its disposal.

Note: While using your Web database, you can check the performance of the cache by using the routine WEB GET STATISTICS. If, for example, you notice that the cache’s rate of use is close to 100%, you may want to consider increasing the size that has been allocated to it.
The /4DSTATS and /4DHTMLSTATS URLs allow you to also obtain information about the cache’s state. Please refer to the Information about the Web Site section.

When the cache is enabled, the 4D Web server looks for any static page requested by the browser in the cache first. If it finds the page, it sends it immediately. If not, 4D loads the page from disk and places it in the cache.
When the cache is full and additional space is required, 4D “unloads” the oldest pages first, among the least demanded ones.

At any moment, you can clear the cache of the pages and images that it contains (if, for example, you have modified a static page and you want to reload it in the cache).
To do so, you just have to click on the Clear Cache button. The cache is then immediately cleared.

Note: You can also use the special URL .

This area allows you to configure how the web server will handle user sessions and their associated processes. Note that the Legacy sessions option is only available for compatibility in databases/projects created with 4D versions prior to 4D v18 R6.

When you select this option (recommended), a user session is managed through a Session object. 

No other settings are available. Scalable sessions:

• can use any number of processes,
• can be assigned privileges,
• can share information between processes
• always use thread-safe code (see Using preemptive Web processes)
• always reuse temporary contexts (see Reuse Temporary Contexts (4D in remote mode)).

Scalable sessions are detailed in the User sessions page on developer.4d.com.

When this option is selected, the web server does not provide any specific support for user sessions. Successive requests from web clients are always independant and no context is maintained on the server. 

In this mode, you can configure additional web server setttings:

• Maximum Concurrent Web Processes
• Reuse Temporary Contexts (4D in remote mode)
• Use preemptive processes

Compatibility Note: This option is only available in databases/projects created with a 4D version prior to 4D v18 R6.

This option enables the handling of legacy user sessions by the 4D HTTP server. This mechanism is described in the Web Sessions Management (Legacy) section.

In this mode, you can configure additional web server settings:

• Maximum Concurrent Web Processes
• Use preemptive processes
• Inactive Process Timeout

The Reuse Temporary Contexts (4D in remote mode) option is automatically checked (and locked).

This option indicates the strict upper limit of Maximum Concurrent Web Processes of any type (standard Web processes or belonging to the “pool of processes”) that can be open simultaneously on the server. This parameter allows prevention of 4D Server saturation as the result of massive number of requests.

By default, this value is 100. You can set the number anywhere between 10 and 32000.

When the maximum number of concurrent Web processes (minus one) is reached, 4D no longer creates new processes and sends the following message “Server unavailable” (status HTTP 503 – Service Unavailable) for each new request.

Note: You can also set the maximum number of Web processes using the WEB SET OPTION command.

In theory, the maximum number of Web processes is the result of the following formula: Available memory/Web process stack size(*).
Another solution is to visualize the information on Web processes displayed in the Runtime Explorer: the current number of Web processes and the maximum number reached since the Web server boot are indicated.

(*) The stack size allocated by 4D for a Web process is around 512 KB (indicative value, ​​which may vary based on context). 

Allows you to optimize the operation of the 4D Web server in remote mode by reusing Web processes created for processing previous Web requests. In fact, the Web server of a 4D client needs a specific Web process for the handling of each Web request; when necessary, this process connects to the 4D Server machine in order to access the data and database engine. It then generates a temporary context using its own variables, selections, etc. Once the request has been dealt with, this process is killed.

When the Reuse Temporary Contexts option is checked, 4D maintains the specific Web processes created on the client machine and reuses them for subsequent requests. By removing the process creation stage, Web server performance is improved.

In return, you must make sure in this case to systematically initialize the variables used in 4D methods in order to avoid getting incorrect results. Similarly, it is necessary to erase any current selections or records defined during the previous request.

Allows you to set the maximum timeout before closing for inactive Web processes on the server.

Enables preemptive web processes in your compiled applications. When Use preemptive processes is selected, the eligibility of your web-related code (including 4D tags and web database methods) to the preemptive execution will be evaluated during the compilation. For more information, see Using preemptive Web processes.

Note: This option does not apply to Web service processes (server or client). Preemptive mode is supported by Web service processes at method level: you just have to select "Can be run in preemptive processes" property for published SOAP server methods (see Publishing a Web Service with 4D) or proxy client methods (see Subscribing to a Web Service in 4D) and make sure they are confirmed thread-safe by the compiler. 

Set the authentication system that you want to apply to your Web server. The authentication concerns the way the information concerning the user name and password are collected and processed. For the user, the authentication mode is transparent.

Notes: 

• You must restart the web server in order for the changes made to these parameters to be taken into account.
• These parameters are detailed in the Connection Security section.

No authentication is provided by the web server, authentication must be done by your code. When this option is selected:

• If the On Web Authentication database method exists, it is executed and, in addition to $1 and $2, only the IP addresses of the browser and the server ($3 and $4) are provided, the user name and password ($5 and $6) are empty. In this case, you can filter connections according to the IP address of the browser and/or the requested IP address of the server.
• If the On Web Authentication database method does not exist, connections are automatically accepted.

Standard authentication in BASIC mode. The name and password entered by the user are sent unencrypted in the HTTP requests. This does not ensure total system security since this information could be intercepted and used by a third party (https connections are recommended).

When a user connects to the server, a dialog box appears on their browser in order for them to enter their user name and password. These two values are then sent to the On Web Authentication database method along with the other connection parameters (IP address and port, URL...) so that you can process them.

This mode provides access to the Include 4D passwords option that allows you to use, instead of or in addition to your own password system, 4D’s database password system (as defined in 4D).

Note: With the 4D Client Web server, keep in mind that all the sites published by the 4D Client machines will share the same table of users. Validation of users/passwords is carried out by the 4D Server application.

The authentication information is processed by a one-way process called hashing which makes their contents impossible to decipher.

As in BASIC mode, users must enter their name and password when they connect. These two values are then sent encrypted to the On Web Authentication database method with the other connection parameters. You must authenticate a user using the WEB Validate digest command.

You can designate a user, previously defined in the 4D password table, as a “Generic Web User.” In this case, each browser that connects to the database can use the access authorizations and restrictions associated with this generic user. You can therefore easily control the browser’s access to the different parts of the database.

Note: Do not confuse this option, which allows you to restrict the browser’s access to different parts of the application (methods, forms, etc.), with the Web server’s connection control system, managed by the password system and the On Web Authentication Database Method.

To define a Generic Web User:

1. In the Design mode, create at least one user with the Users editor of the Tool Box.
   You can associate a password with the user if you wish.
2. In the different 4D editors, authorize or restrict access to this user.
3. In the Database Settings dialog, choose the Options (I) page of the Web theme.
   The “Web Passwords” area contains the Generic Web User drop-down list.By default, the Generic Web User is the Designer and the browsers have full access to the entire database.
4. Choose a user in the drop-down list and validate the dialog box:
   
   

All the Web browsers that are authorized to connect to the database will benefit from the access authorizations and restrictions associated with this Generic Web User (except when the BASIC mode and the “Include 4D Passwords” option are checked and the user that connects does not exist in the 4D password table, see below).

The "Passwords with BASIC protocol" option does not influence how the Generic Web User operates. Whatever the state of this option, the access authorizations and restrictions associated with the “Generic Web User” will be applied to all the Web browsers that are authorized to connect to the database.

However, when the "Include 4D passwords" option is selected, two possible results can occur:

• The user’s name and password don’t exist in 4D’s password table. In this case, if the connection has been accepted by the On Web Authentication Database Method, the Generic Web User’s access rights will be applied to the browser.
• If the user’s name and password exist in 4D’s password table, the “Generic Web User” parameter is ignored. The user connects with his own access rights.