This function is usually used by modules to advertise themselves to the world. It's picked up by such statistics collectors, like netcraft.com, which accomplish that by connecting to various servers and grabbing the server version response header (Server). Some servers choose to fully or partially conceal that header.

This method should be invoked in the PerlPostConfigHandler phase, which will ensure that the Apache core version number will appear first.

For example let's add a component "Hikers, Inc/0.99999" to the server string at the server startup:

dir_config() called in a scalar context without the $key argument returns a HASH reference blessed into the APR::Table class. This object can be manipulated via the APR::Table methods. For available methods see APR::Table.

@values = $s->dir_config->get($key);

To receive a list of values you must use get() method from the APR::Table class.

$value = $s->dir_config($key);

If the $key argument is passed in the scalar context only a single value will be returned. Since the table preserves the insertion order, if there is more than one value for the same key, the oldest value assosiated with the desired key is returned. Calling in the scalar context is also much faster, as it'll stop searching the table as soon as the first match happens.

$s->dir_config($key => $val);

If the $key and the $val arguments are used, the set() operation will happen: all existing values associated with the key $key (and the key itself) will be deleted and $value will be placed instead.

$s->dir_config($key => undef);

If $val is undef the unset() operation will happen: all existing values associated with the key $key (and the key itself) will be deleted.

This method allows you to extend the HTTP protocol to support new methods, which fit the HTTP paradigm. Of course you will need to write a client that understands that protocol extension. For a good example, refer to the MyApache2::SendEmail example presented in the PerlHeaderParserHandler section, which demonstrates how a new method EMAIL is registered and used.

Remembering that Apache restarts itself immediately after starting, we can see that the restart_count goes from 1 to 2 during the server start. Moreover we can see that every operation forces the parsing of httpd.conf and therefore reinitialization of mod_perl (and running all the code found in httpd.conf). This happens even when the server is shutdown via httpd -k stop.

What conclusions can be drawn from this demonstration:

Apache2::ServerUtil::restart_count() returns 1 every time some -k command is passed to Apache (or kill -USR1 or some alternative signal is received).

At all other times the count will be 2 or higher. So for example on graceful restart the count will be 3 or higher.

For example if you want to run something every time httpd -k is run you just need to check whether restart_count() returns 1:

In this example, no memory allocation happens on the Apache-side and you aren't risking to get a memory leak.

The problem with server_root_relative is that Apache allocates memory to concatenate the path string. The memory is allocated from the pool object. If you call this method on the server pool object it'll allocate the memory from it. If you do that at the server startup, it's perfectly right, since you will do that only once. However if you do that from within a request or a connection handler, you create a memory leak every time it is called -- as the memory gets allocated from the server pool, it will be freed only when the server is shutdown. Therefore if you need to build a relative to the root server path for the duration of the request, use the request pool:

Moreover, you could have encountered the opposite problem, where you have used a short-lived pool object to construct the path, but tried to use the resulting path variable, when that pool has been destructed already. In order to avoid mysterious segmentation faults, mod_perl does a wasteful copy of the path string when returning it to you -- another reason to avoid using this function.

Apache2::ServerUtil also provides auto-generated Perl interface for a few other methods which aren't tested at the moment and therefore their API is a subject to change. These methods will be finalized later as a need arises. If you want to rely on any of the following methods please contact the the mod_perl development mailing list so we can help each other take the steps necessary to shift the method to an officially supported API.