Release: 1.1.3 (Released 14th January 1997)
Bugs reported in 1.2b6:
Beta: 1.2b6 (Released 26th January 1997)
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
Bugs fixed in next release:
Server occasional does not restart after a kill -HUP,
because one (or more) child processes do not die fast
Now does not log certain non-error conditions (such as
"Connection Aborted" during accept)
Various bug fixes in the way that connections are accepted
Default timeout reduced to 5 minutes, rather then 20
OS specific updates for IRIX, ConvexOS11, NCR
Auto-configure the Makefile in the support directory
Update auto-generated HTML to include
Fix big in proxy module which prevented compilation on some
Patches to fix some Apache 1.2b6 bugs are available in the 1.2b6
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.
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.
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
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.
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.
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
Transparent Content Negotiation covers the extensions to
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.
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.
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.