In this issue

Release: 1.1.1
Beta: 1.2b2 (Released 9th December)

• httpd executable contains a number of large static strings, making it unnecessarily big

• Occasional 'assertion failed' when restarting the server and using Listens.

Apache is currently in a 'beta release' cycle. This is where it is made available prior to full release for testing by anyone interested. Normally during the beta cycle no new major features will be added. The full release of Apache 1.2 is expected at the end of December or early in January.

There have been some reports that after Apache has been running for a while there are lots of network connections in FIN_WAIT_2 state (as listed by netstat). This is a problem since the operating system only has a finite amount of space to store the details of these connections, which can become exhausted. It is not a bug in Apache, but is caused when the server does not receive the final packet of the connection closedown which could be due to the client (browser) not closing its end of the connection correctly, or possibly due to a network error. Given the number of connections in this state seen on some sites, the most likely cause is a particular browser or TCP stack.

The FIN_WAIT_2 state is the final state of a network connection shutdown. It means that the server is waiting for a final FIN packet from the browser which confirms the browser has closed down the connection. Unfortunately the TCP protocol does not require a timeout for the FIN_WAIT_2 state (unlike most other network connection states). Some operating systems do implement a timeout for this state, so they will be less affected by this problem. If your operating system implements a time out for FIN_WAIT_2 state, it should be set. If not, you might be able to increase the number of connections allowed in the kernel (by altering parameters related to 'mbufs'). The number of connections in FIN_WAIT_2 state can be seen by using netstat -f inet on most systems.

The configurable log module allows the time taken to service a request to be logged, using the %T directive. However this was including the time spent waiting for a new connection if this request reused an existing connection (a persistent connection or keepalive). In the next release this has been fixed so that is only logs the time actually spent processing the request.

Apache has a 'timeout' value which it uses to cancel transfers which are taking too long to complete. This could be because the client has gone away (due to a client or network problem). By default, this timeout is 400 seconds (6 minutes). When sending data to the client the timeout timer is reset after each bit of the transfer has been sent, so that the time out will only come into effect if no more data has been transferred in 400 seconds (or whatever value has been set for the time out with the TimeOut directive). So the total transfer could take longer than 400 seconds.

In Apache, file uploads also have a timeout. However this timeout applies to the entire transfer, not the time between each successful network read. Large transfers over slow links could take longer than 400 seconds, so the time out mechanism should be the same as when sending data.

In September, Apache's handling of PATH_INFO was updated so that it was set correctly if the URL was re-written, for example, if a ScriptAlias path included some PATH_INFO information. However that has had the effect of removing the PATH_INFO from an SSI "include virtual" (for example, <!-- #include virtual="/prog.cgi/path" > does not set PATH_INFO to "/path". In the next release, Apache will still use the new behaviour (which is correct), but to allow people to use hard coded path info in virtual includes it will set the path info from the include the new environment variable FILEPATH_INFO.

A program to automate and customise log rotation is now available for use with Apache (it is not part of the Apache distribution). This program, called cronolog, can be used to log requests from Apache. It logs to files with names based on the current date (e.g. the current day number, month, year etc.) which can be fully customised. A new logfile is changed each time the name of the file would change (e.g. if the current day number is used in the name of the file, a new log file will be created each day).

Since Apache 1.2b1 was released there have been reports that some AOL users have not been able to access Apache sites. They get a message saying

"The Web address you requested is not available in a version supported by AOL. This is an issue with the Web site, and not with AOL. The owner of this site is using an unsupported HTTP language."

This statement is not true: it is a problem with the AOL proxy. It seems that this is because their proxies are deliberating refusing to serve up responses from HTTP/1.1 compliant servers, such as Apache 1.2. It is quite clearly not a problem with the server, since the HTTP/1.1 specification says that servers can return a HTTP/1.1 response to a HTTP/1.0 request. Apache is correctly returning a HTTP/1.1 response, so that browsers can notice they are talking to a HTTP/1.1 server and use additional HTTP/1.1 features if they want. Without this facility it would be impossible for browsers to use the new HTTP/1.1 features.

The solution to this problem is for AOL to update their proxies so that they correctly implement the HTTP specification. In the meantime, Apache will be modified so that if it sees a request from a AOL proxy it reverts to responding with a HTTP/1.0 response. Note that in this case the only change would be to the status version number, the rest of the response will be exactly the same, which will show that the proxy can and should have accepted the same response when labelled as HTTP/1.1.

One of the main reasons why the basic Apache code does not contain SSL encryption is that the US government does not allow this encryption technology to be exported. This is despite that fact the SSL is already widely available outside the US (for example, the main freely available SSL library, SSLeay, was developed in Australia). A recent court case in San Fransisco has resulted in a judge defining computer source code as free speech protected by the First Amendment, potentially allowing the export of encryption programs in source code format.

The US government has a set of rules, called ITAR, which restrict the export of certain military goods, including encryption software. These rules define "export" to include publications as well as discussion, and "software" to include printed English descriptions and diagrams. This prevents authors of encryption algorithms from publishing their algorythms in books or journals which may get distributed outside the US. We wrote about the ITAR restrictions and how they affected Apache in Apache and Secure Transactions (since this article was written the Sioux server is no longer available, see below).

Daniel J. Bernstein, Research Assistant Professor at the University of Illinois at Chicago, wrote an encryption algorithm that he wanted to publish. He challenged the US government over the right to be able to publish his own invented encryption algorithm in journals and books arguing that the export restrictions were violating his First Amendment right to "free speech". The government responded that source code was not protected by the First Amendment, but Judge Marilyn Hall Patel rejected this in April and held that source code was classed as protected speech under the first amendment. This is the first time that computer source code has been recognised as protect speech.

This decision only applies to Professor Bernstein, and other companies and people still have to follow the export restrictions. However it is hoped that this case will set a precedent. If is does it will open that way for source code products, such as Apache, to include encryption in their source versions (but not in precompiled libraries or binaries).

Incidentally, the NCSA server used to have 'hooks' in the code to allow people to add PGP encryption. Despite they fact that this server never included actual encryption technology, they were made to remove these hooks by the US government. After this Apache also removed its similar hooks. Brian Behlendorf, an Apache developer, comments "No cryptographic source code was ever distributed by the Apache project. Despite this, the Apache server code was deemed by the NSA to violate the ITAR.".

Further details of the Bernstein case and its implications is available from the EFF Archive.

Our feature on Apache and Secure Transactions listed two commercial servers based on Apache which implement SSL, Sioux and Stronghold. These two servers have now merged under the single name Stronghold (as announced in this press release). Stronghold is not affected by the US ITAR rules because the encryption technology has been developed outside the US.

Apache has made it onto PC Week's top ten best products of 1996. They describe it as "fast, stable, supportive of multiple operating systems and almost infinitely scalable".

And finally, we wish all our readers a very merry Christmas and Apache, oops, a happy new year. The next Apache Week will be on the 10th January.