| The most important change is that HTTP 1.0 assumed that each IP had a unique hostname. The HTTP request just got sent to the IP that resulted from the DNS lookup with no indication of what hostname was fed to DNS. HTTP 1.1 (1999, so way postdating Netscape 1.0) has a Host header that's sent with every request, which allows the client to communicate to the server which hostname the client thinks it's talking to. That allows today's world, with multiple hostnames colocated on the same IP, to work properly. But if you leave out the Host header the server doesn't know which of those sites you meant and will do ... something. For example, this explains the defcon.org failure in their screenshots. In fact, you can try this at home in your favorite command-line: 1) Type telnet www.defcon.org 80
You get output like: Trying 162.222.171.206...
Connected to www.defcon.org.
Escape character is '^]'.
2) Type: GET / HTTP/1.0
and hit enter twice. See what it responds with.3) Repeat, but in step 2 type (or paste, since it closes the connection quickly): GET / HTTP/1.1
Host: www.defcon.org
followed by two newlines. Observe the difference.Same thing for www.whitehouse.gov (which is in fact a cname for www.whitehouse.gov.edgesuite.net which is a cname for www.eop-edge-lb.akadns.net which is a cname for a1128.dsch.akamai.net which you can bet needs the Host header to know which site you were accessing!). And same thing for news.ycombinator.com, which is a cname for news.ycombinator.com.cdn.cloudflare.net which then resolves to an IP but doing a reverse DNS lookup on that IP says it's got at least "ns1.cloudflare.com" and "dns.cloudflare.com" as domain names that resolve to it... so it's clearly going to be looking at the Host header to see what you actually think you're talking to. You can even see this if you compare http://news.ycombinator.com.cdn.cloudflare.net/ to https://news.ycombinator.com/ even though one is a cname for the other. |