4D v16.3Web/Options (I) page |
||
|
4D v16.3
Web/Options (I) page
Web/Options (I) page
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. The cache is shared between all the Web processes. You can set the size of the cache in the Preferences. By default (starting with 4D v14 R5), 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. 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. 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). Note: You can also use the special URL /4DCACHECLEAR. Allows you to set the maximum timeout before closing for inactive Web processes on the server. 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(*). (*) The stack size allocated by 4D for a Web process is around 512 KB for 64-bit versions and around 256 KB for 32-bit versions (indicative values, which may vary based on context). Enables or disables the internal mechanism for automatic handling of user sessions by the 4D HTTP server. This mechanism is described in the Web Sessions Management section. By default, this mechanism is enabled in databases created with 4D v13 and later versions. However, for compatibility reasons, it is disabled in databases converted from previous versions of 4D. You must enable it explicitly in order to benefit from this functionality. When this option is checked, the "Reuse Temporary Contexts" option is automatically checked (and locked). 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. Enables preemptive web processes in your compiled applications (64-bit applications only). 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. In the Database Settings, you can set the access control system that you want to apply to your Web server. Two authentication modes are provided: BASIC mode and DIGEST mode. The authentication mode concerns the way the information concerning the user name and password are collected and processed.
For the user, the use of either authentication mode is transparent. Notes:
You can now define, in the Database Settings dialog box, the access control system you want to apply to your Web server. To do this, choose the Options (I) page of the Web theme: In the "Passwords" area, three options are available to you:
Notes:
Here are the different resulting systems: The “Passwords with BASIC protocol” option is selected and the “Include 4D Passwords” option is not selected.
Note: If the user name sent by the browser is an empty string and if the On Web Authentication Database Method doesn’t exist, a password dialog box is sent to the browser. The “Passwords with BASIC protocol” and “Include 4D Passwords” options are selected.
Unlike BASIC mode, the DIGEST mode is not compatible with standard 4D passwords: it is not possible to use 4D passwords as Web IDs. The “Include 4D passwords” option is dimmed when this mode is selected. The IDs for Web users must be managed in a customized manner (for example, via a table). When the DIGEST mode is activated, the $6 parameter (password) is always returned empty in the On Web Authentication Database Method. In fact, when using this mode, this information does not pass by the network as clear text (unencrypted). It is therefore imperative in this case to evaluate connection requests using the WEB Validate digest command. The operation of the 4D Web server's access system is summarized in the following diagram: 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:
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:
See also
|
PROPERTIES
Product: 4D
HISTORY
ARTICLE USAGE
4D Design Reference ( 4D v16) |