In a message dated 1/22/2003 5:38:18 PM Eastern Standard Time,
[EMAIL PROTECTED] writes:
Speaking of that, is 4.0 going to support at
least part of HTTP 1.1?
-Roberto
What portions do you think would make the most
sense to support, and what benefits would supporting those features provide?
I'd recommend thinking about these things in terms of a model where all static
content (images, _javascript_, css, etc.) is served from a separate process
leaving the AOLserver free to serve dynamic .adp pages.
-
Nathan
[Moss, Tim]
Even
in that situation (with which I completely agree by the way; it
enables you to tune those servers for the specific purpose and achieve
phenomenal performance - e.g. regularly rsync all the static content onto a
memory based file system, from which the server reads. Or give the
server huge amounts of RAM in which to cache all the static content, or both
perhaps)
...
even in that situation the HTTP/1.1 Keep-Alive features are of great benefit
both to the client and the server:
the
client only suffers from any network latency twice (once for the HTML and once
for all static objects in the page) - On a high latency
connection this can be significant in terms of page download
speed.
the
server has to deal with fewer (on average at least a factor of 10) incoming
connections which whilst not particularly costly on an individual basis, they
all add up,
Other than the Keep-Alives, I don't think any of the
other features HTTP/1.1 offers above 1.0 are anywhere near as significant in
practice, but it would be nice to be able to support them I
suppose.
The
fact that a Host header is required simplifies some things, and some of
the Cache-Control and ETag headers are nice ideas, but in practice there's no
guarantee that the clients, (or indeed the proxies, caches etc between the
client and the server) respond to them in a sensible way, if at
all.
