 |
|
Newsletter |
|
|
Back issues |
|
||
|
|
Features |
|
||
|
|
Apache security |
|
||
|
|
Apache 2.0 |
|
||
|
|
Other features |
|
||
|
|
About Apache Week |
|
Copyright ©2020 Red Hat, Inc | ||
In this issue
Apache Status
Release: 1.1.3 (Released 14th January 1997)
Bugs fixed in next release:
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.1Apache 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 RequestsA 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 TransactionsThe 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. StandardsTransparent Content Negotiation Draft DocumentsThree 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:
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. CommercialStonghold for NTStronghold, 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 NewsThe 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. |
|
|