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.
Note: For security reasons, starting with 4D v15 R2, the HTTP TRACE method is disabled by default in the 4D Web Server. This means that when an HTTP TRACE request is received, the 4D Web Server now returns a 405 error ("method not allowed"). If you want to explicitly enable the HTTP TRACE method, you must use the Web HTTP TRACE option with the WEB SET OPTION command.
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.
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
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:
Field
ELF
WLF
Value
BYTES_RECEIVED
X
Number of bytes received by the server
BYTES_SENT
X
X
Number of bytes sent by the server to the client
C_DNS
X
X
IP address of the DNS (ELF: field identical to the C_IP field)
C_IP
X
X
IP address of the client (for example 192.100.100.10)
CONNECTION_ID
X
Connection ID number
CS(COOKIE)
X
X
Information about cookies contained in the HTTP request
CS(HOST)
X
X
Host field of the HTTP request
CS(REFERER)
X
X
URL of the page pointing to the requested document
CS(USER_AGENT)
X
X
Information about the software and operating system of the client
CS_SIP
X
X
IP address of the server
CS_URI
X
X
URI on which the request is made
CS_URI_QUERY
X
X
Request query parameters
CS_URI_STEM
X
X
Part of request without query parameters
DATE
X
X
DD: day, MMM: 3-letter abbreviation for month (Jan, Feb, etc.), YYYY: year
METHOD
X
X
HTTP method used for the request sent to the server
PATH_ARGS
X
CGI parameters: string located after the “$” character
STATUS
X
X
Reply provided by the server
TIME
X
X
HH: hour, MM: minutes, SS: seconds
TRANSFER_TIME
X
X
Time requested by server to generate the reply
USER
X
X
User name if authenticated; otherwise - (minus sign).
If the user name contains spaces, they are replaced by _ (underlines)
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.