Davmagic .Com said:
I would appreciate any comments on this HTTP Server Request-Reply
Process, which I have included on this page of mine for newbees, to help
explain the process... keep in mind it is simplified for general
understanding:
http://davmagic.com/PAGES38.html#ex10
Item 3 is terribly geborken. The request is not forwarded to a DNS
server, and DNS servers don't speak HTTP at all. HTTP is conducted over
TCP/IP rather than UDP -- UDP is much faster than TCP/IP, but, by
design, it's not as reliable.
You undoubtedly already know how the process works, but for those who
don't:
If the client (in this case probably a web browser) doesn't already
know the IP address of the remote host, e.g. davmagic.com, on the first
request for a resource from that host it will consult DNS (Domain Name
Service) to discover it (66.175.21.39). Then it initiates an HTTP
connection to that remote host over TCP/IP, and, if HTTP/1.1 is in use,
tells the remote server, essentially, "I'm looking for davmagic.com".
Regardless of the HTTP version in use, it then says, "I'm requesting
the resource /foo/bar/html". Most web browsers will also tell the
server what kinds of files it knows how to deal with, its name and
version, which character encodings it can deal with, and maybe which
(human) language it prefers, and possibly that it would like to keep
the connection open for future requests that will come along shortly.
The client might also return a cookie, if one exists and rightfully
should be sent to that domain and path, regardless of whether or not
the server is going to do anything with it. (The client cannot know if
the server is going to actually bother to use the cookie... that's just
how it works.) There may be some other stuff sent along that is usually
ignored by the server -- some browsers even send along the monitor's
currently configured display size in pixels.
On all subsequent connections, the client already knows the IP address
of the remote host, so it skips the DNS lookup. All DNS lookups come
with a "time to live" after which clients are supposed to check for
fresher information, so if that time passes while the information is
still in the browser's pea brain, the browser, if it's behaving
correctly, will do another lookup if it needs to talk to that host
again.
The "I'm looking for davmagic.com" part is what allows us to use
name-based virtual hosting. The actual header sent by the client is
"HTTP_HOST: davmagic.com" Without it, we'd end up seeing whatever's
configured on the server as the default domain, which is almost never
the one we want because it probably is that of the web hosting provider
or one of his earliest clients.
The headers that tell the server the server that we'd like to keep the
connection open for future requests looks like:
HTTP_CONNECTION = keep-alive
HTTP_KEEP_ALIVE = 300
.... where the '300' is how long, in seconds, we'd like to keep the
connection open. This one can cause problems for servers that see a lot
of traffic, so the server is free to select a shorter interval in order
to free up the connection socket sooner. Keep-alive speeds things up by
getting us around the need to build a new connection for every request,
but it can also slow things down on a very busy server. Maybe someday
the whole thing will get a much-needed rethink. I'm not holding my
breath!
You might consider making the DNS server a terminal node connected to
the "PC or WebTV" to more accurately reflect reality.
