6.2.6 Directives starting with M, N, O, P, Q, and R

(a) Contents

The MaxClients directive specifies the maximum number of clients that can be connected simultaneously.

When you start the server, the processes equivalent to the number specified in the StartServers directive start and wait for requests.

prefork MPM

When many requests occur simultaneously, multiple processes process these requests. When the remaining number of processes waiting for request is less than the number specified in the MinSpareServers directive, new processes are gradually generated. The processes are generated until the number of total processes is equal to the number specified in the directive. After that, if the request processing ends and the request waiting processes increase, the processes are terminated until the number of processes specified in the MaxSpareServers directive is reached.

worker MPM

If many requests occur simultaneously, multiple threads process these requests. When the remaining number of threads in the request waiting state becomes less than the number specified in the MinSpareThreads directive, new processes are generated until the number of threads reaches the number specified in this directive. After that, when the request processing ends and the threads in the request waiting state increase, the processes are terminated until the number of threads is equal to or less than the number specified in the MaxSpareThreads directive.

The value of the MaxClients directive is in the range from the value of the ThreadsPerChild directive to the value of the ServerLimit directive × value of the ThreadsPerChild directive. To change the upper limit for the number of server processes to increase the value specified in the MaxClients directive, change the value specified in the ServerLimit directive.

(b) Location where you can code

httpsd.conf

(c) Specification example

MaxClients 150

(a) Contents

This directive specifies the upper limit for the number of KeepAlive persistent connections. If the upper limit is not specified, it is set to 0. In KeepAlive, since specific clients occupy the server processes, and hence set the upper limit to give chance to other clients also to receive the services.

(b) Location where you can code

httpsd.conf

(c) Specification example

MaxKeepAliveRequests 100

(a) Contents

This directive specifies the request processing frequency of a server process. A server process ends after processing the specified number of requests. This has an advantage to prevent the failure due to memory leakage by the user-created applications. If the frequency is set to 0 the upper limit for the request processing frequency of a server process is not set. In such cases the server process does not end and waits for processing the next request.

(b) Location where you can code

httpsd.conf

(c) Specification example

MaxRequestsPerChild 10000

(a) Contents

This directive specifies the maximum number of server processes that are running in the request waiting state. For details on other directives related to number of processes, see 4.1 Relationship between processes and directives of HTTP Server.

If the value of this directive is less than the value of the MinSpareServers directive, a value of the MinSpareServers specification value + 1 is assumed.

You can specify this directive when using the prefork MPM.

(b) Location where you can code

httpsd.conf

(c) Specification example

MaxSpareServers 10

(a) Contents

This directive specifies the maximum number of server threads to keep on running in the request waiting state. If the number of server threads in the request waiting state exceeds this specified value, server processes are terminated until the number of those server threads is equal to or less than this specified value.

The value of the MaxSpareThreads directive is in the range from the sum of the values of the MinSpareThreads and ThreadsPerChild directives to the value of the MaxClients directive. If a value less than the sum of the values of the MinSpareThreads and ThreadsPerChild directives is specified, this sum value is assumed.

You can specify this directive when using the worker MPM.

(b) Location where you can code

httpsd.conf

(c) Specification example

MaxSpareThreads 75

(a) Contents

This directive specifies the minimum number of server processes that are running in the request waiting state. If number of server processes is less than the specified value, the Web server generates new processes. For details on other directives related to number of processes, see 4.1 Relationship between processes and directives of HTTP Server.

You can specify this directive when using the prefork MPM.

(b) Location where you can code

httpsd.conf

(c) Specification example

MinSpareServers 5

(a) Contents

This directive specifies the minimum number of server threads that are running in the request waiting state. If the number of server threads in the request waiting state becomes less than this specified value, new server processes are generated.

You can specify this directive when using the worker MPM.

(b) Location where you can code

httpsd.conf

(c) Specification example

MinSpareThreads 25

(a) Contents

The MultiviewsMatch directive specifies the extension types that are the targets of content negotiation.

NegotiatedOnly: Extensions that are related only to character sets, compression format, language code, and MIME type are the targets of content negotiation.

Handlers: In addition to the extensions specified in NegotiatedOnly, the extensions related to the handler are also the target of content negotiation.

(b) Location where you can code

httpsd.conf, <VirtualHost>, <Directory>, .htaccess

(c) Overwrite permission

FileInfo level

(d) Specification example

MultiviewsMatch Handlers

(a) Contents

Specify this directive for restricting the functionality that the user can use.

+: Permits the use of functionality specified in the option.

-: Prohibits the use of functionality specified in the option.

Important note

If you specify the directive multiple times without using +-, only the last specified directive is enabled.

(Example 1)

Options All
Options ExecCGI

As shown in this example, if you specify the directives in two lines without specifying the +- in the option, the user can use only the execution functionality of the CGI script. The functionality such as directory index functionality cannot be used.

(Example 2)

Specification of the httpsd.conf file

Options All

Specification of the access control file

Options ExecCGI

The access control file is referred to after the httpsd.conf file, and hence you can use only the execution functionality of the CGI script in the directory with the access control file.

(Example 3)

Options Indexes ExecCGI

As shown in this example, if you specify the options in one line without +- signs, you can use both the specified functionality.

(b) Location where you can code

httpsd.conf, <VirtualHost>, <Directory>, .htaccess

(c) Overwrite permission

Options level

(a) Contents

This directive specifies the evaluation order of the Allow directive and the Deny directive. You can specify the following in the directive. Earlier evaluated directives are overwritten by the later ones.

(b) Location where you can code

<Directory>, .htaccess

(c) Overwrite permission

Limit level

(a) Contents

You can specify an optional environment variable to pass on to the CGI script.

(b) Location where you can code

httpsd.conf, <VirtualHost>, <Directory>, .htaccess

(c) Overwrite permission

FileInfo level

(d) Specification example

PassEnv TMP

(a) Contents

This directive specifies a file name that stores control process ID. In file name, you can specify absolute path, or the relative path from the specified value of ServerRoot directive.

(b) Note

In Windows, changes to the values specified in the PidFile directive are not applied when you restart the server. If you have changed values specified in the PidFile directive, stop and then restart the Web server.

In UNIX, changes to the values specified in the PidFile directive are not applied when you restart the server. If you have changed values specified in the PidFile directive, use the kill command to stop the Web server, and then restart the Web server. The httpsdctl command cannot be used while the Web server is stopped.

If you create multiple environments, make sure that a different file path is used for each environment.

(c) Location where you can code

httpsd.conf

(d) Specification example

PidFile logs/httpd.pid

(a) Contents

The Port directive specifies the port number of the server that receives requests from Web browsers that use IPv4 addresses.

Requests from Web browsers that use IPv6 addresses are not received even if the Port directive has been specified. To use IPv6 addresses, specify the IPv6 addresses in the Listen directive. In addition, if you are simultaneously using IPv4 addresses, also specify the IPv4 address in the Listen directive.

(b) Location where you can code

httpsd.conf

(c) Specification example

Port 80

(a) Contents

The ProxyErrorOverride directive overrides the response header and response body when the backend server returns a three-digit status code beginning with 4 or 5. As a result, the reverse proxy sends a self-generated response to the client instead of the response from the backend server.

On: Overrides the response header and response body when the backend server returns a three-digit status code beginning with 4 or 5.

Off: Does not override the response header or the response body.

(b) Note

The mod_proxy and mod_proxy_http modules must be embedded to use a reverse proxy. For details on reverse proxies, see 4.7 Setting the reverse proxy.

(c) Location where you can code

httpsd.conf, <VirtualHost>

(d) Specification example

ProxyErrorOverride On

When the backend server returns a three-digit status code beginning with 4 or 5, the response generated by the reverse proxy is returned to the client.

(a) Contents

When using a reverse proxy server, the ProxyPass directive specifies the request received from the Web browser and the address used to forward the request.

path-name: Specifies the path of the reverse proxy that receives the redirect request as a URL that starts with a forward slash (/).

URL: Specifies the URL of the forwarding destination backend server in the format http or ws://IP-address-or-host-name[:port-number]/.

You can also specify an IPv6 address or the host name corresponding to an IPv6 address for URL.

Specify a URL starting with http:// to perform HTTP communication with the backend server.

Specify a URL starting with ws:// to upgrade the communication between the client and the backend server to WebSocket communication. However, the client and the backend server must support the WebSocket protocol.

!: Specify this symbol to exclude the requests that match the specified path name from the requests to be handled by the reverse proxy.

key: The following table lists the keys that you can specify:

You can specify the timeout key even if you specify a URL starting with ws:// for URL. In this case, however, the timeout key value does not function as the waiting time during sending and receiving between the backend server. The key value functions only as the default value when the connectiontimeout key is omitted.

You cannot specify a path name that is a duplicate of any of the following directive specification values:

• JkMount URL patterns in the redirector definition file

(b) Note

You must embed the following module to use the reverse proxy.

• mod_proxy module

  UNIX version

  LoadModule proxy_module libexec/mod_proxy.so

  Windows version

  LoadModule proxy_module modules/mod_proxy.so

In addition, you must embed one of the following modules according to the specified URL of the forwarding destination backend server:

If the specified URL begins with http://

• mod_proxy_http module

  UNIX version

  LoadModule proxy_http_module libexec/mod_proxy_http.so

  Windows version

  LoadModule proxy_http_module modules/mod_proxy_http.so

If the specified URL begins with ws://

• mod_proxy_wstunnel module

  UNIX version

  LoadModule proxy_wstunnel_module libexec/mod_proxy_wstunnel.so

  Windows version

  LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so

To specify !, make sure that ! comes before the ProxyPass directive that specifies the URL.

(c) Location where you can code

httpsd.conf, and <VirtualHost>

(d) Specification example

ProxyPass /abc/def/ !
ProxyPass /abc/ http://backend.example.com/

In this example, requests beginning with /abc/def/ are not handled as reverse proxy requests.

(a) Contents

When using a reverse proxy server, the ProxyPassReverse directive changes the URL coded in the Location header field in the redirect response sent from the backend server. To make the redirect request from the Web browser pass through the reverse proxy server, change the Location header to the value specified in this directive.

path-name: Specifies the path of the reverse proxy that receives the redirect request as a URL that starts with a forward slash (/).

URL: Specifies the backend server URL in the Location header that is to be changed, in the format http://host-name[:port-number].

You can specify an IPv6 address or the host name corresponding to an IPv6 address for URL. IPv6 addresses have various formats, so use care when specifying values. If the backend server URL differs from the specified value, the directive is not enabled. When specifying an IPv6 address, check the format of the IPv6 address in the Location response header that is sent from the backend server. You cannot specify characters after the ? sign (query string) for path-name and URL.

(b) Note

The mod_proxy and mod_proxy_http modules must be embedded to use a reverse proxy. The host name and port number used to change the Location header are determined from the value specified in the UseCanonicalName directive. For details on reverse proxies, see 4.7 Setting the reverse proxy.

(c) Location where you can code

httpsd.conf, <VirtualHost>

(a) Contents

When using a reverse proxy server, the ProxyPreserveHost directive specifies whether to forward the Host header value received from the client to the backend server without changes.

On: Forwards the Host header value received from the client to the backend server without changes.

Off: Changes the Host header value received from the client according to the value specified in the ProxyPass directive, and then forwards the changed value to the backend server.

(b) Note

The mod_proxy and mod_proxy_http modules must be embedded to use a reverse proxy. For details on reverse proxies, see 4.7 Setting the reverse proxy.

(c) Location where you can code

httpsd.conf, <VirtualHost>

(d) Specification example

ProxyPreserveHost On

The Host header value received from the client is forwarded to the backend server without changes.

(a) Contents

Specify this directive when you control the use of Via header with the proxy.

on: Adds the information of the local host to the Via header. The existing information does not change.

off: Does not add the information of the local host to the Via header. The existing information does not change.

full: Adds the information in which version of the local host is added as comment, to the Via header. The existing information does not change.

block: Does not add the information of the local host to Via header. Deletes the Via header in the request.

(b) Note

The mod_proxy and mod_proxy_http modules must be embedded to use a reverse proxy. For details on reverse proxies, see 4.7 Setting the reverse proxy.

(c) Location where you can code

httpsd.conf, <VirtualHost>

(a) Contents

The QOSCookieDomain directive specifies the domain where the cookies used in flow control functionality is enabled. This value is used in HWS creation mode, not in user creation mode. When multiple hosts are set, by specifying this directive you can use cookies between the hosts that share the domain. In the domain name at least two "." must be included.

Note that you can specify the domain name corresponding to an IPv6 address.

(Example)

When two hosts, a.example.com and b.example.com are set, if .example.com is specified in this directive, priority processing is performed even when you access any of the two hosts.

(b) Note

The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

(c) Location where you can code

httpsd.conf, and <VirtualHost>

(a) Contents

This directive specifies the validity period of the cookie that is used in the flow restriction functionality in seconds. This value is used in HWS creation mode, not in user creation mode.

(b) Note

The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Location>

(a) Contents

The QOSCookieName directive specifies the name of the cookie to be used in flow-restriction functionality. Semicolons (;), commas (,), and spaces cannot be used in the cookie name. For session management that uses different cookies between the host and the URL, a different name must be specified.

hws: Manages sessions by using cookies generated by HTTP Server. This is called HWS creation mode.

user: Manages sessions by using cookies generated in an external module other than HTTP Server. This is called user creation mode.

(b) Notes

• The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

• If the QOSCookieName directive is specified in a specific block, the QOSCookieName directive that is specified in a higher location is not inherited.

  (Example)

  QOSCookieName Cookie1 hws

  <Location /loc1>

  QOSCookieName Cookie2 user

  </Location>

  In this case, if a request starts with /loc1, the specification of the cookie name Cookie2 is valid. If a request does not start with /loc1, the specification of the cookie name Cookie1 is valid.

• Do not duplicate cookie names when specifying the QOSCookieName directive multiple times. If cookie names are duplicated, a startup error occurs.

  (Example)

  QOSCookieName Cookie1 hws

  QOSCookieName Cookie1 user

  In this case, a startup error occurs because of cookie name duplication.

• If you specify the QOSCookieName directive in HWS creation mode multiple times, the last specification is valid.

  (Example)

  QOSCookieName Cookie1 hws

  QOSCookieName Cookie2 hws

  In this case, the specification of the cookie name Cookie1 is invalid, and the specification of the cookie name Cookie2 is valid.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Location>

(a) Contents

The QOSCookieSecure directive specifies the setting such that cookies are sent to the client only during SSL access. This value is used in HWS creation mode, not in user creation mode. Note that the cookie is confirmed after the encryption process of SSL ends.

on: Specifies the setting such that the cookies are sent to the client only during SSL access.

off: Specifies the setting such that the cookies are sent to the client even when the access is not with SSL.

(Example)

If you set this directive when the hosts with enabled SSL and the hosts with disabled SSL are set, the cookies are sent only when accessing the hosts with enabled SSL.

(b) Note

The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Location>

(a) Contents

When the number of server processes in the request waiting state is decreased, this directive specifies the number of server processes used when processing only the requests that are received by sending cookies.

In Windows version, specify the number of server threads.

(b) Note

The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Location>

(a) Contents

Specify this directive when a process is denied by the flow control functionality, and the request from client is to be redirected to the specified path. In the new path, specify the URL path that includes "Protocol name://host name[:port number]". You can also specify an IPv6 address or the host name corresponding to an IPv6 address for new-path.

When a request is redirected to the old path, the server returns a response that contains status code 302 and the Location header with the new path. The response cannot be customized.

For details on the specification of the old path and new path, see Redirect directive.

(b) Note

The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Location>

(a) Contents

This directive specifies the value when the number of the server processes in the request waiting state is decreased and all the received requests are denied.

In Windows version, specify the number of server threads.

(b) Note

The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Location>

(a) Contents

When the process is denied by the flow control functionality, this directive specifies the contents to be returned along with the status code 503. The contents are cached in the server process, so you need to restart the server whenever there is a change.

file: Returns the specified file with the specified MIME type. When you omit the MIME type, "text/html" is set. In the file name, you can specify absolute path or the relative path from the specified value of the ServerRoot directive.

message: Returns the specified text. Specify the character string with quotation mark (") at the beginning for the text. In the MIME type, "text/html" is set.

(b) Note

The mod_hws_qos module must be embedded to use flow-restricting functionality. For details on flow-restricting functionality, see 4.9 Flow-restricting functionality.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Location>

(d) Specification example

QOSResponse file "text/html; charset=ISO-8859-1" htdocs/busy.html
QOSResponse message "Server busy.

(a) Contents

The ReadmeName directive specifies the file name (without the path information) of the file that describes the comment added as Readme, when the directory index is displayed. You can describe the comment in the HTML or plain text format. However, in the file specified with the AddType directive or the TypesConfig directive, the MIME type must be defined correctly. When you create command in plain text, <PRE> tag is added to the HTML of directory index display.

(b) Location where you can code

httpsd.conf, <VirtualHost>, <Directory>, .htaccess

(c) Overwrite permission

Indexes level

(d) Specification example

ReadmeName README.html

Display the contents of README.html file under the directory.

(a) Contents

Specify the directive when the request from the client for old path is (redirected) to the new path.

In the old path, specify the request URL path that starts with a forward slash (/). However, you cannot specify the characters after the ? sign (query string) in the old path.

You cannot specify an old path that is a duplicate of any of the following directive specification values:

• ProxyPass path name

• JkMount URL patterns in the redirector definition file

For example, the following paths cannot be specified:

  Redirect temp /aaa/bbb/ http://aaa.example.com/
  ProxyPass /aaa/ http://aaa.example.com/

In the new path, specify the URL path that includes "protocol name://host name[:port number]". You can also specify an IPv6 address or the host name corresponding to an IPv6 address as the URL specified for new-path.

When the request is received in the old path, the specified status code and the response with the new header path set in the Location header is returned. Normally, the Web browser that receives the status code 300, automatically redirects the request to the specified address in the Location header.

With the Redirect directive, you can redirect the request for a specific file to the specific file, or can specify to redirect the request for an optional path under a specific directory to the path with the same name under a different directory. Use the RedirectMatch directive when you want to redirect the request for an optional path under a specific directory to a specific file.

permanent: Responds with the status code 301 Moved Permanently.

temp: Responds with the status code 302 Found.

seeother: Responds with the status code 303 See Other.

gone: Responds with the status code 410 Gone. You cannot specify the new path.

status code: Responds with the specified status code. For details on values that you can specify, see Appendix A Status codes. However, when the status code other than 300 is specified, you cannot specify the new path.

(b) Location where you can code

httpsd.conf, <VirtualHost>, <Directory>, .htaccess

(c) Overwrite permission

FileInfo level

(d) Specification example

Redirect temp /index.html http://host-number:port-number/default.html

Redirect the request for /index.html to the "http://host-name:port-number/default.html" with the status code 302.

(a) Contents

Specify this directive when the request from the client to the path that satisfies the condition mentioned in the regular expressions is to be requested again (redirect) for the new path.

Specify the old path of the request URL that starts with a forward slash (/) in the regular expressions. Note that in old path, you cannot specify characters after the ? sign (query string).

You cannot specify a regular expression that is a duplicate of any of the following directive specification values:

• ProxyPass path name

• JkMount URL patterns in the redirector definition file

For example, the following regular expressions cannot be specified:

  RedirectMatch ^/aaa/bbb/(.*) http://aaa.example.com/$1
  ProxyPass /aaa/ http://aaa.example.com/

In the new path, specify the URL path that includes "protocol-name://host-name[:port-number]/". You can also specify an IPv6 address or the host name corresponding to an IPv6 address as the URL specified for new-path.

When the regular expressions are grouped using brackets ( ) , you can refer to the character string that matches with the group number i, using $i in the new path. Set the digits 1 to 9 for i. When a request to the path that satisfies the condition described in the regular expressions is received, the Web server responds with the specified status code and the Location header with new path set. Normally, the Web browser that receives the status code 300 automatically sends (redirects) the request to the address specified in the Location header.

For details on specifications of each status code, see Redirect directive.

(b) Location where you can code

httpsd.conf, <VirtualHost>, <Directory>, .htaccess

(c)  Overwrite permission

FileInfo level

(d) Specification example

(Example 1)

RedirectMatch ^/other/ http://www.example.com/

Redirect all the requests that start with /other/ to "http://www.example.com/" with the status code 302.

(Example 2)

RedirectMatch permanent ^/old/(.*) http://www.example.com/new/$1

Redirect the request for "/old/file name" to "http://www.example.com/new/file name" with the status code 301.

(a) Contents

Specify this directive when you customize the header value received from client.

set: Sets the header. When header exists, rewrite it with the specified header value.

append: Adds the header value to the existing header. A comma delimits the existing header values. Set the header if it does not exist.

add: Sets a header in another line if the header already exists. Use to specify the same header in multiple lines.

unset: If the specified header exists, deletes it.

env=environment-variable: Executes the contents specified in the RequestHeader directive when the specified environment variable is set.

env=!environment-variable: Executes the contents specified in the RequestHeader directive when the specified environment variable is not set.

If header-value contains spaces, you must enclose the value in double quotation marks ("). For header-value, you can specify a character string containing only characters, a character string containing format identifiers, or a character string containing both characters and format identifiers. The format identifiers are as follows:

(b) Note

The mod_headers module must be embedded to use header customization functionality. For details on header customization functionality, see 4.10 Header customization functionality.

(c) Location where you can code

httpsd.conf, <VirtualHost>, <Directory>, .htaccess

(d) Overwrite permission

FileInfo level

(e) Specification example

RequestHeader set Host www.example.com

(a) Contents

This directive specifies the timeout period in seconds from the beginning of request reception to the completion of request header reception. It also specifies the timeout period from the beginning to completion of request body reception. You can specify a value in the range from 0 to 2147483647. This directive is effective to prevent server resources from being occupied for a long time for requests with low-speed data sending. Note that if nothing is specified for type, 20 seconds is set for the timeout period. If 0 is specified for time, the timeout is not set for the corresponding type.

You can specify header and body for type as follows:

header: Monitors the time elapsed from the beginning of request reception to the completion of request header reception.

body: Monitors the time elapsed from the beginning to the completion of request body reception.

(b) Note

You must embed the mod_reqtimeout module to use this directive.

In UNIX version

LoadModule reqtimeout_module libexec/mod_reqtimeout.so

In Windows version

LoadModule reqtimeout_module modules/mod_reqtimeout.so

We recommend that you also specify the suppression of module trace output.

HWSSuppressModuleTrace mod_reqtimeout.c

(c) Location where you can code

httpsd.conf, <VirtualHost>

(d) Specification example

(Example 1)

RequestReadTimeout header=10 body=30

The timeout period from the beginning of request reception to the completion of request header reception is set to 10 seconds, and the timeout period from the beginning to completion of request body reception is set to 30 seconds.

(Example 2)

RequestReadTimeout body=0

The timeout period from the beginning of request reception to the completion of request header reception is set to 20 seconds. The timeout from the beginning to completion of request body reception is not set.

(a) Contents

Specify this directive along with the AuthName directive, AuthType directive, AuthUserFile directive (or AuthGroupFile directive). This directive defines the access control.

user: Among the users registered in the password file specified with the AuthUserFile directive, only the users that are specified in the user names can access.

group: Only the users belonging to the group specified in the registered group name in the group file specified with the AuthGroupFile directive can access.

valid-user: All users registered in the password file specified with the AuthUserFile directive can access.

file-owner: Among the users registered in the password file specified with the AuthUserFile directive, only the users that match with the owner of the system of the access target file, can access (can not specify in Windows version).

file-group: Among the users belonging to the group specified in the group names registered in the group file that is specified with the AuthGroupFile directive, only those users having a group name matching with the owner of the system of the access target file, can access (cannot specify in Windows version).

(b) Location where you can code

<Directory>, .htaccess

(c) Overwrite permission

AuthConfig level