www.sun.com is now reporting its server signature as "SunONE WebServer 6.0". We think that this is simply part of the rebranding of the web server away from Netscape-Enterprise, rather than a new product.

www.coke.com appears to have switched from AIX to Linux, but in fact this is a feature of it starting to use the Akamai network for its front page.

Some notable Netscape-Enterprise sites have switched to Apache based servers, including the Vatican, Kellogg's and NASA. Kellogg's also seem to have insourced their site back from IBM.

NASA are now running something called "NASA_Webserver/2003 (NASA) mod_jk/1.2.1-beta-1" on Novell Netware. We think that this is likely to be a locally modified Apache running behind a Novell ICS reverse proxy server. In contrast to Kellogg's, NASA appear to have moved the site off their own network to AT&T.

Meanwhile, www.walmart.com have made a change to their server signature to make it appear less obviously like a copy of Apache with a hand edited server header, and more like Microsoft-IIS. We speculate that forthcoming site enhancements at Walmart may include changing the name of the JServSessionId cookie.

Since we started the Web Server Survey in 1995, a longstanding theme of Netcraft's internet exploration work has been the issue of how best to reassure webmasters and systems administrators that requests they may see originating from Netcraft's network are benign, and do not in any way convey aggressive intent.

Earlier today an RFC was published by Internet pioneer Steve Bellovin which addresses this scenario. Bellovin's idea is that the sender's intentions, whether good or bad, should be stated directly in the TCP header information using a security flag [termed the "evil bit" by Bellovin]. It is intended that network protection devices such as routers, firewalls and Intrusion Detection Systems should defend their networks against packets where the evil bit is set, but otherwise assume that traffic is benign. Groups aligning themselves with RFC 3514 include the FreeBSD project, [who have already coded an implementation] and the nmap scanner.

Continue reading

• When we say "Upgrade!" you must do what we say, not do what we do
• We're still waiting for our order to be delivered
• It's not broke, and we dont need to fix it.
• We're less of a target for attackers. There's no kudos in hacking anything more than 5 years old.
• We've been evaluating Linux, and have not yet reached a decision.
• It's just the front end machines. Everything else has been running Windows 2003 for months. Honest!
• The cobblers children didnt have shoes, either.
• That site doesnt see a lot of traffic. It just redirects to www.euro.dell.com
• If you think that running NT4 doesnt do a lot for our product advocacy, then you haven't seen what our evil competitor runs

www.intel.com is one of a very small number of well known sites running both Windows 2000 and Windows 2003 in a load balanced pool, and has become a tempting target for people to use as a straw in the wind towards the relative performance of the two operating systems. One person mailed us saying he thought that the Intel site's response time had slowed since Intel started using Windows 2003, and asked for confirmation and explanation.

The performance of www.intel.com shows a saw tooth formation, with some responses consistently longer than others. Matching up the response times with the corresponding server signatures actually does confirm that the responses served by Microsoft-IIS/6.0 are consistently longer than those served by Microsoft-IIS/5.0.

Analysing the response time graph more carefully shows that the connection time and time to serve the first byte are consistent across the two sets of servers, but the time to serve the complete request is significantly higher on the Microsoft-IIS/6.0 servers.

It is important to appreciate that the difference need not be directly caused by the system software. Other plausible reasons could include;

• The hardware specification of the Microsoft-IIS/5.0 machines may be faster than those running Microsoft-IIS/6.0
• The configuration of the systems is likely to be different
• From looking at the tcp/ip characteristics, we think it is likely that the www.intel.com front page is served dynamically, and  the migration of the application that generates the dynamic content may have introduced a performance penalty
• The configuration of the local network at  Intel may have disadvantaged the Microsoft-IIS/6.0 machines in some way.