"There is an experimental W3 server for the SPIRES High energy Physics preprint database, thanks to Terry Hung, Paul Kunz and Louise Addis of SLAC. It's only just been put up, so don't expect perfection" (Tim Berners-Lee, www-talk mailing list, 13 December 1991, commenting on the setting up of the first web server in the U.S.).
<VirtualHost 216.114.150.12>
DocumentRoot /home/uww/html
ServerName www.unitedwaywindham.org
Options None
ErrorLog logs/unitedwaywindham_error_log
TransferLog logs/unitedwaywindham_access_log
</VirtualHost>
<VirtualHost marlboro.vt.us>
DocumentRoot /home/town/html
ServerName marlboro.vt.us
ErrorLog logs/town_error_log
TransferLog logs/town_access_log
ScriptAlias /cgi-bin/ /home/town/html/cgi-bin/
</VirtualHost>
; request apparently from a regular browser
GET /Images/paint.jpg HTTP/1.1
Accept: */*
Referer: http://www.marlboro.edu/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
Host: www.marlboro.edu
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Fri, 07 Dec 2001 17:34:54 GMT
Server: Apache
Last-Modified: Wed, 05 Dec 2001 17:14:07 GMT
ETag: "5874-bdd-3c0e55df"
Accept-Ranges: bytes
Content-Length: 3037
; "timeout" = timeout value for the connection; "max" = number of
; requests to accept over the connection; these values relate to
; the settings for KeepAliveTime and MaxKeepAliveRequests in Apache
Keep-Alive: timeout=15, max=93
Connection: Keep-Alive
Content-Type: image/jpeg
; request apparently from a search engine's crawler
; notice the 1.1 Host header in the 1.0 request
HEAD /~jamdalea/bicycle.au HTTP/1.0
Host: www.marlboro.edu
Accept: */*
User-Agent: Slurp.so/1.0 (slurp@inktomi.com; http://www.inktomi.com/slurp.html)
From: slurp@inktomi.com
HTTP/1.1 404 Not Found
Date: Fri, 07 Dec 2001 17:35:02 GMT
Server: Apache
Last-Modified: Tue, 27 Feb 2001 14:45:12 GMT
ETag: "31663-4aab-3a9bbd78"
Accept-Ranges: bytes
Content-Length: 19115
Connection: close
Content-Type: text/html


Notice that the redirecting device is now looking 'deeper' into the packet than it would be for simple packet-forwarding purposes. We'll see that routers acting as packet-filtering firewalls do this kind of thing all the time, nonetheless there's been a marked movement towards hardware devices that read ever further into packets.
Transparent caching is currently used extensively by ISPs. It's very controversial technology for both technical and political/legal reasons
Here's an example of transparent proxy setup on a Linux router, using the "netfilter" facility:
#!/bin/sh IPT=/sbin/iptables # Add a rule to the prerouting rule chain of the NAT rules table. If you see a packet # coming in on eth0 from an address other than that of the proxy device, and that # packet is heading to TCP port 80 somewhere, change the destination addressing of the # packet to that of the proxy device, TCP port 3128 $IPT -t nat -A PREROUTING -i eth0 -s ! 216.114.150.170 -p tcp --dport 80 -j DNAT --to 216.114.150.170:3128 # Now add a rule to the post-routing chain of the NAT table: if you see a packet with a # local address going to the proxy box, change its source address to that of the # router (i.e., if the router applies the first rule and changes the destination of a # packet to be the proxy, it wants the proxy to return the response packets to the router # (so it can "un-NAT" them). $IPT -t nat -A POSTROUTING -s 216.114.150.0/23 -d 216.114.150.170 -j SNAT --to 216.114.150.1 # Basically the same rule as the previous one, only for a different block of internal # addresses $IPT -t nat -A POSTROUTING -s 10.0.0.0/14 -d 216.114.150.170 -j SNAT --to 216.114.150.1