Information about the Web Site

4D allows you to obtain information about the functioning of your 4D Web site.

• You can control the site by using particular URLs (/4DSTATS, /4DHTMLSTATS, /4DCACHECLEAR and /4DWEBTEST).
• You can generate a log of all the requests.
• You can obtain information regarding the Web Server in the Watch page of the Runtime Explorer window.

4D Web Server accepts four particular URLs: /4DSTATS, /4DHTMLSTATS, /4DCACHECLEAR and /4DWEBTEST.

• /4DSTATS, /4DHTMLSTATS and /4DCACHECLEAR are only available to the Designer and Administrator of the database. If the database’s 4D password system has not been activated, these URLs are available to all the users.
• /4DWEBTEST is always available.

The /4DSTATS URL returns several items of information in an HTML table (displayable in a browser):

• Cache Current Size: Current size of Web server cache (in bytes)
• Cache Max Size: Maximum size of cache (in bytes)
• Cached Object Max Size: Maximum size of each object in the cache (in bytes)
• Cache Use: Percentage of cache used
• Cached Objects: Number of objects (pages, picture files, etc.) found in the cache.

(*) For more information about the cache of static pages and pictures, please refer to section Web Server Settings.

This information can allow you to check the functioning of your server and eventually adapt the corresponding parameters.

Note: The command WEB GET STATISTICS allows you to also obtain information about how the cache is being used for static pages.

The /4DHTMLSTATS URL returns, also as an HTML table, the same information as the /4DSTATS URL. The difference is that the Cached Objects field only counts HTML pages (without counting picture files). Moreover, this URL returns the Filtered Objects field.

• Filtered Objects: Number of objects in cache not counted by URL, in particular, pictures.

The /4DCACHECLEAR URL immediately clears the cache of the static pages and images. It allows you to therefore “force” the update of the pages that have been modified.

The /4DWEBTEST URL is designed to check the Web Server status. When this URL is called, 4D returns a text file only with the following HTTP fields filled:

• Date: current date at the RFC 822 format
  For example: “Mon, 16 Jan 2012 13:12:50 GMT”
• Server: 4D_version/internal version number
  For example:  “4D_v12/12.3.0”
• User-Agent: name and version @ IP client address
  For example: “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 @ 127.0.0.1

4D allows you to obtain a log of requests.

This file is named “logweb.txt” and is automatically located:

• with 4D in local mode and 4D Server, in the Logs folder located next to the database structure file.
• with 4D in remote mode, in the Logs subfolder of the 4D client database folder (cache folder).

The activation and configuration of the log file contents is carried out in the Database Settings on the Web/Log (type) page:

Note: The activation and deactivation of the log file of requests can also be carried out by programming using the SET DATABASE PARAMETER (4D v12) or WEB SET OPTION (4D v13 and higher) commands.

The log format menu provides the following options:

• No Log File: When this option is selected, 4D will not generate a log file of requests.

• CLF (Common Log Format): When this option is selected, the log of requests is generated in CLF format. With the CLF format, each line of the file represents a request, such as:
  host rfc931 user [DD/MMM/YYYY:HH:MM:SS] "request" state length
  Each field is separated by a space and each line ends by the CR/LF sequence (character 13, character 10).
  
  • host: IP address of the client (ex. 192.100.100.10)
  • rfc931: information not generated by 4D, it’s always - (a minus sign)
  • user: user name as it is authenticated, or else it is - (a minus sign). If the user name contains spaces, they will be replaced by _ (an underscore).
  • DD: day, MMM: a 3-letter abbreviation for the month name (Jan, Feb,...), YYYY: year, HH: hour, MM: minutes, SS: seconds

The date and time are local to the server.

• request: request sent by the client (ex. GET /index.htm HTTP/1.0)
• state: reply given by the server.
• length: size of the data returned (except the HTTP header) or 0.

Note: For performance reasons, the operations are saved in a memory buffer in packets of 1Kb before being written to disk. The operations are also written to disk if no request has been sent every 5 seconds.
The possible values of state are as follows:
200: OK
204: No contents
302: Redirection
304: Not modified
400: Incorrect request
401: Authentication required
404: Not found
500: Internal error
The CLF format cannot be customized.

• DLF (Combined Log Format): When this option is selected, the request log is generated in DLF format. DLF format is similar to CLF format and uses exactly the same structure. It simply adds two additional HTTP fields at the end of each request: Referer and User-agent.
  
  • Referer: Contains the URL of the page pointing to the requested document.
  • User-agent: Contains the name and version of the browser or software of the client at the origin of the request.

The DLF format cannot be customized.

• ELF (Extended Log Format): When this option is selected, the request log is generated in ELF format. The ELF format is very widespread in the world of HTTP browsers. It can be used to build sophisticated logs that meet specific needs. For this reason, the ELF format can be customized: it is possible to choose the fields to be recorded as well as their order of insertion into the file.

• WLF (WebStar Log Format): When this option is selected, the request log is generated in WLF format. WLF format was developed specifically for the 4D WebSTAR server. It is similar to the ELF format, with only a few additional fields. Like the ELF format, it can be customized.

Configuring the fields
When you choose the ELF (Extended Log Format) or WLF (WebStar Log Format) format, the “Weg Log Token Selection” area displays the fields available for the chosen format. You will need to select each field to be included in the log. To do so, use the arrow buttons or simply drag and drop the desired fields into the “Selected Tokens” area.

Note: You cannot select the same field twice.

The following table lists the fields available for each format (in alphabetical order) and describes its contents:

Note: Dates and times are given in GMT.

Since a Web log file can become considerably large, it is possible to set up an automatic archiving mechanism. The triggering of a backup can be based on a certain period of time (expressed in hours, days, week or months), or based on the file size; when the set deadline (or file size) is reached, 4D automatically closes and archives the current log file and creates a new one.

When the Web log file backup is triggered, the log file is archived in a folder named “Logweb Archives,” which is created at the same level as the logweb.txt file (that is, next to the database structure file).

The archived ile is renamed based on the following example: “DYYYY_MM_DD_Thh_mm_ss.txt.” For instance, for a file archived on September 4, 2006 at 3:50 p.m. and 7 seconds: “D2006_09_04_T15_50_07.txt.”

The automatic backup parameters for the request log are set on the Web/Log (backup) page of the Database Settings:

First you must choose the frequency (days, weeks, etc.) or the file size limit criterion by clicking on the corresponding radio button. You must then specify the precise moment of the backup if necessary.

• No Backup: The scheduled backup function is deactivated.
• Every X hour(s): This option is used to program backups on an hourly basis. You can enter a value between 1 and 24 .
  
  • starting at: Used to set the time at which the first back up will begin.
• Every X day(s) at X: This option is used to program backups on a daily basis. Enter 1 if you want to perform a daily backup. When this option is checked, you must indicate the time when the backup must be started.
• Every X week(s), day at X: This option is used to program backups on a weekly basis. Enter 1 if you want to perform a weekly backup. When this option is checked, you must indicate the day(s) of the week and the time when each backup must be started. You can select several days of the week if desired. For example, you can use this option to set two weekly backups: one on Wednesdays and one on Fridays.
• Every X month(s), Xth day at X: This option is used to program backups on a monthly basis. Enter 1 if you want to perform a monthly backup. When this option is checked, you must indicate the day of the month and the time when the backup must be started.
• Every X MB: This option is used to program backups based on the size of the current request log file. A backup is automatically triggered when the file reaches the set size. You can set a size limit of 1, 10, 100 or 1000 MB.

Note: In the case of scheduled backups, if the Web server was not launched when the backup was scheduled to occur, on the next startup 4D considers the backup as failed and applies the appropriate settings, set via the Database Settings.

The Watch page (“Web” heading) in the Runtime Explorer displays information related to the Web Server, more particularly:

• Web Cache Usage: indicates the number of pages present in the Web cache as well as its use percentage. This information is only available if the Web server is active and if the cache size is greater than 0.
• Web Server Elapsed Time: indicates the duration of use (in hours:minutes:seconds format) of the Web server. This information is only available if the Web server is active.
• Web Hits Count: indicates the total number of HTTP requests received since the Web server boot, as well as an instantaneous number of requests per second (measure taken between two Runtime Explorer updates). This information is only available if the Web server is active.

Note: For more information about the Runtime Explorer, refer to 4D Design Reference manual.