Apache Week
   
   Issue 53, 21st February 1997:  

Copyright 1996-2005
Red Hat, Inc.

In this issue


Apache Status

Release: 1.1.3 (Released 14th January 1997)
Beta: 1.2b6 (Released 26th January 1997)

Bugs reported in 1.2b6:
  • SSI arguments which include back-slashed spaces (i.e. "\ ") are treated like unescaped spaces.
  • In negotiation, Charset iso-8859-1 is always given highest preference rating, even if client indicates a lower preference

Bugs fixed in next release:

  • Server occasional does not restart after a kill -HUP, because one (or more) child processes do not die fast enough
  • Now does not log certain non-error conditions (such as "Connection Aborted" during accept)
  • Various bug fixes in the way that connections are accepted and established
  • Default timeout reduced to 5 minutes, rather then 20 minutes
  • OS specific updates for IRIX, ConvexOS11, NCR
  • Auto-configure the Makefile in the support directory
  • Update auto-generated HTML to include <HTML>...</HTML> tags
  • Fix big in proxy module which prevented compilation on some systems

Patches to fix some Apache 1.2b6 bugs are available in the 1.2b6 patch directory


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 in February.

Some Indexers Don't Like HTTP/1.1

Apache 1.2 beta is a HTTP/1.1 server, so it should always respond to requests with a HTTP/1.1 response, even if the request was from a HTTP/1.0 client. While this is the theory, there are browsers which cannot handle HTTP/1.1 responses, so Apache 1.2 allows the version number of the response to be set based on the User-Agent sent from the client.

As Apache 1.2 beta is deployed on the Web, a number of clients cannot handle HTTP/1.1 responses are being found. It appears that the Lycos indexer cannot index Apache 1.2 sites. So Apache has to be configured to give a HTTP/1.0 response when accessed by Lycos. A suitable directive to do this in Apache 1.2 will be

  BrowserMatch Lycos_Spider force-response-1.0

Current information suggests the AltaVista and WebCrawler do not have any problems with HTTP/1.1 responses.


HTTP/1.1 Network Performance and Multiple Requests

A paper from the W3C on Network Performance Effects of HTTP/1.1, CSS1, and PNG examines how these three technologies will after network response. For HTTP/1.1, it looks at the various methods for speeding up transfers that have evolved since HTTP/1.0 was designed.

In HTTP/1.0, every document had to be requested in a separate network connection. This means that to request a document which contains 10 inline images used eleven connections (the original document plus the ten images). Initially these were made one at a time. Then some browsers implemented a scheme where they would make a number of connections in parallel. The same number of connections overall were used (and the same amount of network traffic) but the apparent download time was reduced. Browsers typically make four connections in parallel. While this speeded up end-users' perceptions of download time, it did not benefit the underlying network since exactly the same amount of network traffic was generated, and the number of parallel connections for the images could actually increase the load on servers.

Another way of speeding up transfers was needed, and the first version of keep alives were developed. This was an extension to HTTP/1.0 that let a browser request multiple documents on the same TCP connection. These eliminated the overhead of having to establish a separate connection for each request. The keep alive extensions to HTTP/1.0 were extensively rewritten and incorporated into HTTP/1.1, where they are called persistent connections. The use of persistent connections makes downloads faster than doing them one at a time, and is better for the network and the server.

This paper shows that the fastest and most efficient way to implement a browser is to use pipelining. This is where a single persistent connection is used, but instead of waiting for each response before sending the next request, several requests are sent out at a time. This reduces the amount of time the client and server are waiting for requests or responses to cross the network. Pipelined requests with a single connection are faster than multiple HTTP/1.0 requests in parallel, and considerably reduce the number of packets transmitted across the network.

Apache supports both HTTP/1.0 keep-alives and HTTP/1.1 persistent connections. Pipelining is implement entirely at the browser end, using persistent connections.


Feature Update: Secure Transactions

The US government recently changed the rules for exporting encryption technology. While the change was a slight relaxation, it still does not allow Apache to incorporate SSL for non-US users, since Apache is housed on a server based in the US. We have updated our feature on Apache and Secure Transactions with information about the recent rule change and the requirement for "key escrow" in exported products. This feature also explains the different "ciphers" used in SSL (DES, RC4 etc), why SSL cannot be used in the US in a free product, and why it cannot be exported from the US.


Standards

Transparent Content Negotiation Draft Documents

Three new Internet Drafts are available covering "Transparent Content Negotiation". This is a proposed method for making negotiating between different versions of a document more efficient. At the moment servers such as Apache can use the information supplied by browsers (such as language preferences) to choose the most appropriate response. Transparent content negotiation would add some new features:

  • A list of available versions can be returned to the browser
  • Proxies can choose responses without having to contact the original server, if they have cached the right information
  • The information that browsers can supply can be extended to include things such as screen size, colour depth and so on

Transparent content negotiation is explained in three different draft documents: Transparent Content Negotiation covers the extensions to HTTP/1.1, while Remote Variant Selection Algorithm 1.0 explains a standardised algorithm for choosing between variants, and Feature Tag Registration recommends a scheme for registering browser capabilities.

All of these documents as well as other standards for HTTP, HTML, CGI, URLs and related protocols are available from the Apache Week links page.


Commercial

Stonghold for NT

Stronghold, a secure server based on Apache, is now available for Windows NT. This is the first widely available implementation of Apache on NT. Stronghold is a commercial product, but a time-limited alpha version of Stronghold for NT without encryption is available for download worldwide.


Apache in the News

The New York Times covered the W3C's Network Performance paper in an article entitled The World Wide Wait may be coming to an end (password required). It mentions that Apache is now HTTP/1.1 compliant.


Comments or criticisms? Please email us at editors@apacheweek.com