Posted by
ryuzaki0
on from the what-already? dept.
fabbe writes "The HTTP 1.1 protocol has been approved by the W3C and IETF. CNET article is here. "
Both bodies apparently showed ruthless efficiency getting
these standards out there... speeds that make even glaciers
jealous.
78 comments
old news
by
Anonymous Coward
·
· Score: 0
This is not "ruthless efficiency" it is incompetence. It is a prime example that rule by consensus does not work since the market has already decided that http 1.1 is the standard, so this decision is irrelevant. It's about as meaningful as Microsoft finally deciding that mp3 is the standard for audio files. Duh. Http 1.1 has been in use for at least a year. Hundreds of hosts have been supplying ipless hosting for at least a year, probably longer. I think it pretty much shows that w3c and whoever that other group is are about as relevant as Bill Clinton - the lame duck president.
-eric upgrade@netdoor.com No user id because i can't find it:P
The previous draft versions of HTTP 1.1 are flawed and are not fully standardized. Implementations of draft HTTP 1.1 are inconsistant and partial. The standardization of HTTP 1.1 is the actual full, standard, final version of HTTP 1.1. It addresses many issues ignored by RFC 2068 (draft HTTP 1.1).
-- DES Khaddafi KGB genetic jihad Uzi Rule Psix Qaddafi cryptographic Peking Mossad Legion of Doom Albanian Serbian Saddam
There's a reason they've issued some 6-7 draft revisions of HTTP 1.1, so I'm glad they took their time and got it right.
Everyone supports it already anyway, so what's it to you.
Wrong!
by
Anonymous Coward
·
· Score: 0
That is hte case for http 0.9. Http 1.0 has the multidomain behavior, but some W3 browsers dont impliment all of 1.0.
There are lots of web providers doing multiple domains on one IP already.
Re:Wrong!
by
Anonymous Coward
·
· Score: 0
It's not a required feature - in HTTP/1.0 it is intended for proxies only. You can make perfect valid HTTP/1.0 requests without the leading http://domain.name/
When a browser makes an HTTP/1.1 request, it sends along a Host: header which specifies the domain name it wants. The server sees this and responds accordingly.
In the case you're describing, the header would say Host: 123.123.123.123. If the server adminsitrator had anticipated this and set up a virtual host for the hostname 123.123.123.123, that's what the user would see. Otherwise, I guess it's undefined. Apache just directs it to whichever virtual host is defined first in the configuration file.
Apache just directs it to whichever virtual host is defined first in the configuration file. Actually, you can also select a "Default" NameVirtualHost in the apache.conf file (and it can be something "completely different" than any other NameVirtualHost if you want it to be)
It doesn't necssarily. I think in most server setups you choose what the default host is, and that is the one that the IP will map to. In practice it's not a big problem, since most people don't go typing or linking IP addy's in their web pages.
That's all fine and dandy... What happens if someone requests http://123.123.123.123 and there are 4 domains registered to it? I don't understand how that would work. If there's a kid's cartoon and a porn site on the same IP, how does the server send the proper page back to the browser? Anyone wiling to offer an explanation?
-- "It compiles, SHIP IT!" -Overheard at Microsoft's development lab
Re:Speeding up?
by
Anonymous Coward
·
· Score: 0
Apache has been using http/1.1 for some time now, and has the ability to host multiple domains on the same ip. This is not a new protocol, its been in use for quite some time, but W3C/IETF are so damn slow in ratifying standards that it's just now getting approved. In Apache 1.3.x you simply put the following lines to host multiple domains on the same ip.
Repeat for www.domain1.com/www.domain2.com. Both domain1.com/domain2.com can be on the same ip and display different pages. This standard has been in use for so long, that even the text based lynx browser supports it. The W3C/IETF need to get their shit together.
Re:Speeding up?
by
Anonymous Coward
·
· Score: 0
How HTTP/1.1 will speed up Joe Public's connection:
Let's say you go to a page on slashdot.org that contains 5 elements of data; the page itself and 4 graphics. For each one of those elements, under HTTP/1.0, a browser must open a separate connection to download that element. This means, the client machine must open a separate TCP connection to the server. 5 elements on the page, 5 connections to the server. Each one of those connections is actually quite a bit of traffic, as you have to request the connection from the server, the server has to acknowledge it, then the client sends back to the server that it's ready for data. Very inefficient, when you're downloading a 100k slashdot page-filled-with-comments.
Enter HTTP/1.1. Because you can re-use the connection for multiple objects, you only need to open _one_ TCP connection to the server to download everything. Less overhead means faster downloads, period.
Now, keep in mind that this is a very hypothetical example. Real-world, browsers still open four connections (or however many you have in that Netscape config tab) to the server, so if you're only talking about a page with five elements on it, the savings is minimal. How many web pages these days only have five elements or less, though? Now you see how HTTP/1.1 can help with those bloated 60-graphics-on-a-page music sites.
As for multi-domains, I'm still not entirely clear how it's going to work, but I have an idea. Let's say slashdot.org resides on 10.0.0.1. yoda.blockstackers.net wants to be a virtual host on slashdot.org, but Rob decides that he's going to implement HTTP/1.1 virtual hosting (previously known as "Software Virtual Hosts" in Netscape Enterprise Server). He simply CNAMEs yoda.blockstackers.net to slashdot.org, or he makes an A record to 10.0.0.1 and then fires up his HTTP/1.1-compatible browser.
His request, instead of looking like GET/index.html, would look more like GET http://slashdot.org/index.html -- the request includes the domain name. An HTTP/1.1-familiar server (most all of them, these days) interprets that request and serves up the correct page. If he wants a page from yoda.blockstackers.net, his request looks something like GET http://yoda.blockstackers.net/index.html and the correct page is served.
HTH. Please keep in mind that this may not be how the spec actually works; I'm talking out of my ass in terms of how the request actually goes. It may be on another line in the request, I don't know.
--M
Re:Speeding up?
by
Anonymous Coward
·
· Score: 0
slashdot cropped out my directives the directives were as follows
working right VS lessened value.
by
Anonymous Coward
·
· Score: 0
>They HAVE to work perfectly because if they don't, the pilots will > probably be killed and their strategic value will be lessened.
Come now. Micro$oft ships products that are not perfect...and look at how well they doing in economic terms.
Re:working right VS lessened value.
by
Anonymous Coward
·
· Score: 0
Yeah, but would you get into an airplane that can supercruise at Mach 2 that was run by Microsoft software?
Hell, I won't even get on an Airbus because of their software.
Re:working right VS lessened value.
by
Anonymous Coward
·
· Score: 0
>>Hell, I won't even get on an Airbus because of their software.
Sorry, didn't mean to imply that it was written by Microsoft. It wasn't, but I still won't get on an A340:) .
Re:working right VS lessened value.
by
Anonymous Coward
·
· Score: 0
If we calculated how much money was lost in lost productivity and time/cost to fix by shoddy software, how much do you think it would add up to?
I wonder how many YF-22's could I buy for that much money?
he was being sarcastic.
by
Anonymous Coward
·
· Score: 0
i'd think the line about their speed making glaciers jealous (seeing as glaciers move very SLOWLY, get it?) would have given it away.
but hey!
when will netscape have this?
by
Anonymous Coward
·
· Score: 0
i want to know when i can get a version of netscape that supports this..
Re:when will netscape have this?
by
Anonymous Coward
·
· Score: 1
Gee, I dunno...
You might have to wait until a couple of years ago.
Re:Speeding up?
by
Anonymous Coward
·
· Score: 0
That is not entirely accurate. The requests look like that when the request is sent directly to the server in question. The requests look like what the poster you replied to suggested whenever you use a proxy.
Re:Speeding up?
by
Anonymous Coward
·
· Score: 0
Actually, your comments about efficiency with large slashdot comment pages is flawed. The major speed up is with pages that contains lots of inlined graphics. It's connection setup and reset that demand extra traffic - the larger the file, and the fewer the amount of requests, the less HTTP/1.1 will give you (but it will never be worse that HTTP/1.0) in improved performance.
does apache support this?
by
Anonymous Coward
·
· Score: 0
Well? Does it? And where is it mentioned in the documentation?
Re:does apache support this?
by
Anonymous Coward
·
· Score: 0
Snails Pacing and Exponentials Growing ...
by
Anonymous Coward
·
· Score: 0
Seriously, can such an organization keep up with the explosive growth of the Internet?
Hmmmm.....
Perhaps you are being ironic. If so, consider me a target to hit with the clue stick.
Perhaps, though, you mean what you say. If so, perhaps you should look at it this way: these organizations are the explosive growth of the Internet. (An attempt to divide the evolution of the Internet into an IETF pile and a non-IETF pile is pointless.)
Humans (like me and you) always have difficulty in fully appreciating the nature of exponential growth.
There's always this temptation to say "Oh sure... it was growing exponentially back then, but now it's really growing exponentially! It's different now."
Re:Snails Pacing and Exponentials Growing ...
by
Anonymous Coward
·
· Score: 0
The point is that as IETF attendence figures grow, it's not clear that the amount of work coming out grows at the same rate.
Re:Snails Pacing and Exponentials Growing ...
by
Anonymous Coward
·
· Score: 0
Yes, I see that is the point that was "made".
But when the Internet had 100,000 hosts and was growing exponentially --- how can they keep up?
And when the Internet had 10,000,000 hosts and was growing exponentially --- how can they keep up?
It may be "not clear" that they are "keeping up", but that's an awfully vague argument, isn't it? It's shallow to say "yeah, but now it's really big and growing really fast -- how can they keep up" when it's always been true that the Internet has been bigger and growing faster than anyone anticipated.
Re:Virutal hosts and authentication
by
Anonymous Coward
·
· Score: 0
Thank you, that was very helpful.
(BTW: since when are pornographic and educational mutually exclusive terms?:)
NOT NT, the problem was in custom code
by
Anonymous Coward
·
· Score: 0
This one should go up on the urban legends page with Craig Shergold.
One more time: NT didn't have a problem, it was the ship control app the Navy was running on it that failed.
Sorry to crush your adolescent anti-MS fantasy.
Re:NOT NT, the problem was in custom code
by
Le+douanier
·
· Score: 1
"That caused the database to overflow and crash all LAN consoles and miniature remote terminal units, the memo said." (from the article at http://www.gcn.com/gcn/1998/July13/cov2.htm)
Both the ship control app and NT had a problem :
The control app had the problem with a division by 0, which is quite dumb IMHO.
NT had a problem with instability, otherwise the consoles wouldn't be crashed isn't it?
And further in the article you can read:
"But according to DiGiorgio, who in an interview said he has serviced automated control systems on Navy ships for the past 26 years, the NT operating system is the source of the Yorktown's computer problems."
So is this an Urban Legend? We may have a response in a century;)
-- "The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers."
Bill Gates,
I was watching a show called "Flightpath" on Discovery channel last night and they were showing all sorts of nifty things about the new YF-22 fighter aircraft. This is the new hybrid stealth fighter that is going to replace the F-15 for general figter missions.
This plane has been under development more or less for the past 19 or 20 years. Although there are 9 or so flight ready versions of this plane which exist TODAY, there will not be any in actual military service for about 5 more years. Some people have described these planes as the most complex machines ever built. They HAVE to work perfectly because if they don't, the pilots will probably be killed and their strategic value will be lessened.
When much of the software being used today is labelled "mission critical" don't you think it should be well thought out and done PROPERLY as well? Perhaps not 25 years, but don't you find it amazing how stupid is it to spend so much money on software that only partially works?
The notion of "internet time" is complete and utter BS, invented solely to give software companies excuses for shoddy software and to make "lazy programmers" seem more productive.
I seem to recall hearing something a while back about NT-based systems on a Navy missile boat crashing and the ship being basically defenseless as a result. I'd love to hear the captain calling MS tech support and being told to download a patch. Heh.
Although I don't disagree with your statement that software companies should be focusing on bulletproof software for mission critical applications...when is the last time a mission-critical piece of software cost 100s of millions of dollars (not to mention 20 years of R&D funding), had the capability of defending/attacking a nation, and whose bugs couldn't be fixed with a downloadable patch? There's sort of a difference. Although, as with Moore's Law, just because they CAN get away with it, doesn't mean they SHOULD.
But now among the headers that the browser sends in the request, you'll find one like:
Host: www.foo.com
That's what the web server uses to determine which virtual host to use. Apache has supported this for a long time; have a look at the NameVirtualHost directive.
One thing I do like about it is the ability to use multiple names per IP address. But this sort of kills the elegance of design of domains going from TLD, First level domain, and so on.
That's up to the administrator:-). You could also use this to host www.foo.domain.org, www.bar.domain.org, and www.baz.domain.org from the same physical machine.
I wonder what the speed difference is with the fact of concatenating packets into streams rather than placing 1 packet per 1 stream. I'd guess that for small servers it would be trivial but for large ones the change would be enormous.
By "packet", I think they're referring to individual files. If that's the case, then it may provide a noticeable improvements for people with higher-speed connections. It tends to be a lot faster to do one big transfer that can build up some speed than a bunch of little transfers, even for the same number of bytes.
-- \\'
Persistent connections ("pipelining")
by
Alex+Belits
·
· Score: 1
HTTP 1.1 persistent connections allow "pipelining", so new request can be sent while previous ones aren't answered yet. HTTP 1.0 Keep-Alive extension doesn't allow that, and this is why it doesn't allow nasty DoS attack that is possible with HTTP 1.1 -- sending request that definitely will take a lot of time to be processed, then sending large number of requests for large responses (possible large ones by themselves) expecting HTTP server to overgrow its either input or output buffers to ridiculous size.
Since there is no flow control in HTTP 1.1 other than one in TCP, and TCP one can't be used because requests should be received without blocking the client, and server can't send responses to later requests before the response to earlier one, server can either buffer everything in the input and delay processing, or process them simultaneously and buffer the output -- in either way buffers will grow. The alternative is to discard the requests, however just like with other DoS cases there are no "definitely safe" conditions for this.
HTTP 1.0 with Keep-Alive requires as many TCP connections as the number of requests that are in progress simultaneously (so the routers along the way and kernel buffers in the sender may not like it), but the end result is healthier for the server -- while server didn't say anything, client won't try to reuse the same TCP connection and leave server wondering, what to do with the new request.
I don't know, which servers actually support "pipelining" in HTTP 1.1, but this DoS was the main reason why I was unable to add HTTP 1.1 support to my fhttpd -- while I have found what I consider to be reasonable solutions to other DoS in HTTP, for this one every cure that comes to my mind looks worse than the disease.
HTTP 1.1 could solve this by introduction of higher-level flow control or by multiplexing simultaneous replies (first one will create reasonable safeguards against overloading, second one will eliminate the source of the problem), however HTTP 1.1 developers in their infinite wisdom did neither.
And this is not the only flaw in HTTP 1.1.
-- Contrary to the popular belief, there indeed is no God.
Re:In praise of glaciers
by
Alex+Belits
·
· Score: 1
HTTP is a transfer protocol, it's mostly ortogonal to HTML or any other document format. Comapre the difference in results from number of ways, one can use to retrieve email (unix mail files, mh mailboxes, every possible mailbox format up to Hudson and Squish, POP, IMAP, M$ Exchange) and the result of differences in standards in email message format (RFC822 with plain text, MIME in all of its incarnations, widely accepted deviations and possible encodings, HTML in email, windoze-specific file formats in email attachments, etc.).
-- Contrary to the popular belief, there indeed is no God.
For each packet of data the web browser itself sends, a new stream of data had to be opened.
Since the web browser itself doesn't do ACK's on packets, all data which the web browser sent were requests.
Of course, that doesn't change the fact that they did use the wrong terminology throughout the article:)
--
-- The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Yup, HTTP 1.1 is old news. Being a standard isn't.
by
cduffy
·
· Score: 1
All major web servers implemented HTTP 1.1 looong ago. It's only now, however, that the bodies have actually approved of them as standards. Which raises the question... What use are standards when everyone's using a newer version the standards body hasn't yet ratified?
This is not all that secure.
by
Paul+Crowley
·
· Score: 1
If this is, as you describe, a standard challenge-response protocol, then it isn't all that secure.
First, the server has to store your password so that it can work out the "correct" answer to your challenge. Compare this to Unix passwords: an attacker can read everything on your hard drive and still not know what to present in order to log in.
Worse, if I can intercept just one exchange with the server I can start trying to guess your passphrase. Passphrases tend not to be very well chosen, so guessing attacks are rather too effective and it's important to make them as difficult as possible.
Anyone who needs to use networked passwords should implement both of the following techniques if at all possible:
secure transfer of passwords?
by
pixel+fairy
·
· Score: 1
"Version 1.1 also allows for the secure transfer of passwords"
hows uncle sam going to take to this? is it a munition? crypto laws suck...
Re:secure transfer of passwords?
by
Bwah
·
· Score: 1
It's not strong crypto. It's a MD5 based thingy. It DOES beat the hell out of the piece of crap base 64 wannabe encoinf used right now. I wrote a server that supported it a while back... but for some reason cannot remeber how it works right now. Bummer. Go get the RFC.
/dev
-- "There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
Re:secure transfer of passwords?
by
artdodge
·
· Score: 1
It's a kinda neat trick using MD5 hashes. The client has to find the MD5 fingerprint of a string that includes the username, password, and an arbitrary string the server provides. The result? Passwords never pass in cleartext, replay attacks are short-lived (since the server changes that arbitrary string regularly), and no strong crypto is needed since all you're using is a strong hash function which is only useful for authentication anyway (hence Uncle Sam doesn't try to treat it like a munition). See RFC2617 for details.
Re:secure transfer of passwords?
by
Alex+Zepeda
·
· Score: 1
Incidentally, I haven't seen too many servers that support this method of authentication, but the http kioslave supports it.
What's wrong with HTTP 0.9? All I really *need* is "GET/" anyhow...:)
-- pb Reply or e-mail; don't vaguely moderate.
This is why open standards suck
by
YuppieScum
·
· Score: 2
Commitment to open standards is all very well, but the standards bodies themselves need to commit to ratifying those standards while there is still a business case to use them.
Products and markets won't wait if a 'proprietry' solution gets the job done now - budgets need to be spent.
If that's the case, then it may provide a noticeable improvements for people with higher-speed connections.
It can help slow connections even more by saving the latency of the three way handshake and by not having to do slow start (with more latency) for each file transfer.
HTTP 1.0 required a new stream for each packet of data sent. But HTTP 1.1 can send multiple packets along the same stream, speeding the flow of information on the Web.
A new TCP stream for each packet? No wonder the world wide web is so slow!:P
I wonder if it's hopeless to think the media in general can get terminologies correct.
Can somebody comfirm this? I sort of assumed they really meant every file. Or am I confusing stream and connection?
Are most web servers already using HTTP 1.1?
by
timur
·
· Score: 2
I'm confused - I thought HTTP 1.1 was old news. Don't a bunch of servers and web browsers already support this? I know IE 4.0 does - under the advanced options, you can select whether it uses HTTP 1.1. Timur Tabi Remove "nospam_" from email address
Re:Are most web servers already using HTTP 1.1?
by
artdodge
·
· Score: 2
The problem is there are 8 version of HTTP/1.1, including RFC2068, six IETF drafts, and RFC2616. Lots of implementations are against RFC2068, and there are a LOT of problems with that version that are addressed the later ones (expect and TE request header, even MORE excrutiating cache-control detail, etc.)
Also, since HTTP/1.1 isn't being exercised very well by most current clients, the 1.1 support code in most servers is only lightly exercised and often is buggy/incorrect/broken.
Re:Are most web servers already using HTTP 1.1?
by
windshield
·
· Score: 2
Most servers do, but most clients don't. IE40 says that it does in the advance settings, but it just seems to be another microsoft interface element that wasn't wired up to any actual code. I've tested IE40 with 1.1 on, and my server log the requests as 1.0.
They comment on how this new standard will speed up transfers, but does anyone have an idea of how much? Considering many consumers are still limited by bandwidth on their end, it generally won't get faster for them, but mostly more efficent transfers before it ends up with them. Correct? Or am I just entirely missing the point. =] Yes:) It's not about bandwidth, it's about latency (mostly, let's explain); Each connection needs to be initialized (the tcp "3 way handshake" is time consuming), then "tcp slow start" gets in the way, and in the end small objects (pages or small gfx) never reach the full speed of your connection. Browsers try to hide the problem, opening many connections at a time so that connection establishments can be overlayed with transfers, and that transfer speeds sum up. The point of HTTP/1.1 is to transfer many objects back-to-back using a single tcp connection, so you pay connection time and slow start only once for all those objects. Browsers will still be allowed to open many connections at once, but only up to two per server, to be nice with others:)
Also, does anyone know how it's going to allow multi-domains on single IPs? Almost sounds like a redirect of some complex (or lack of compexity) sort. Mayhaps the daemon will take the domain requested, and devide from there? The domain of the URL you requested will be sent in the HTTP request. It is already done right now (with HTTP/1.0 ?), but will be _required_ by HTTP/1.1.
What if you just typed in the IP address? Will it default to some domain? I find this pretty confusing, but I'm no expert. That's up to the server.
But sense connections are made to IPs, not really domains (Or so I thought), I'm just slightly lost on this one. You're correct, and that's why it needs to be specified in the HTTP request headers.
Btw, how new is all this ? Last time I checked, Apache 1.3.x is already HTTP/1.1 compliant, no ?
It takes a few roundtrips to set up a socket, plus some more roundtrips to get the window size > 1, so the server can send more than one packet before waiting for an ack. Until that happens, you're essentially in half-duplex mode.
-- ----
"If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
Re:Virutal hosts and authentication
by
Ben+Hutchings
·
· Score: 1
But under HTTP/1.1, it looks more like
GET / HTTP/1.1 HOST www.example.com
That should actually be "Host: www.example.com"
With HTTP/1.1 we get MD5 encoding.
Are you thinking of Digest authentication? Unfortunately I have yet to see a browser that implements it. I have implemented it in my own client that uses the PUT command, but I cannot yet switch the server to use it because no other client knows how to do it.
You don't understand how it works
by
jsm
·
· Score: 1
(Not sure this post really merits a response, but:)
These are the people that invented HTTP/1.1 in the first place. It has been in development for years, and software developers have implemented what's been ready so far, but all the details hadn't been finalized. Those years were spent ironing out every last little contradiction, ambiguity, and other problem that could be found in the spec, so that we'll be able to use it as long as possible into the future. Your "market" has been looking to these people to make the decisions, because anyone who writes network software knows we need standards, and anyone who's developed much software at all knows that underlying systems must be planned carefully, or they'll fall apart sooner rather than later. The people who made HTTP/1.1 include connections with all the major players in the "market".
By the way, if you think the W3C and IETF are irrelevant, you don't know much about the Internet. And random, vague political bashing doesn't score much in the brains department.
'IPv5' was called ST2 - a connection-oriented protocol that supported QoS. However I don't think anyone really uses it now with a few specialised non-Internet exceptions.
One thing I do like about it is the ability to use multiple names per IP address. But this sort of kills the elegance of design of domains going from TLD, First level domain, and so on. But if I'm interpretting it correctly, it should kill alot of the refer jumps. I wonder what the speed difference is with the fact of concatenating packets into streams rather than placing 1 packet per 1 stream. I'd guess that for small servers it would be trivial but for large ones the change would be enormous.
-- Suddenly, the hairy finger of a familiar monkey tapped me on the shoulder. It was time.--G. T.
For anyone wondering how this works, basically the browser has to request the entire URL on a GET, e.g. - GET http://www.yourdomain.com/ as opposed to just GET/.
That's not how it works. The browser sends a seperate "Host" header:
GET/foobar Host: www.somedomain.com
The "GET http://www.somedomain.com/foo" form is used only if talking to a proxy server.
One thing I do like about it is the ability to use multiple names per IP address.
Apache already has support for this, and a lot of the content providers out there are using it to save on IP addresses. For anyone wondering how this works, basically the browser has to request the entire URL on a GET, e.g. - GET http://www.yourdomain.com/ as opposed to just GET/.
I wonder what the speed difference is with the fact of concatenating packets into streams rather than placing 1 packet per 1 stream. I'd guess that for small servers it would be trivial but for large ones the change would be enormous.
Just in case there's still any confusion.. it's one file per TCP connection in the HTTP 1.0. HTTP 1.1 adds a "Keep Alive" feature that can be sent to keep the connection open.
Andwer to: "allow multi-domains on single IPs?" Currently, under HTTP 1.0, an HTTP request does not include the hostname as part of the request. The requests look like:
'GET/foo.html HTTP/1.0'
Becuase the hostname is not included, the web server that responded to the socket request on that port/IP combination would have to serve pages from it's default htdocs root directory. With HTTP 1.1, the reqests are going to include the hostname. Don't quote me on the syntax, but they might look something like this:
'GET http://www.foo.com/foo.html HTTP/1.1'
With this format, the web server knows the request for was a website named 'www.foo.com', and can look into the appropriate htdocs root directory. And all of this can be one using a single port/IP combination.
-jason
HTTP/1.1 performance and other issues...
by
jg
·
· Score: 5
It wasn't quite as glacial as one might think. The draft standard was approved in March; the RFC issued recently when the RFC editor caught up on backlog. The internet drafts have not had a significant change for nearly a year. Most vendors have been working to the ID's for a long time.
HTTP/1.1 has already been pretty widely deployed: this was the approval of the draft standard, rather than the proposed standard.
As to performance stuff, see: http://www.w3.org/Protocols/HTTP/Performance/
As to recovering IP addresses, most clients have been sending the host name as part of the request using the HOST header for a long while. This means you can distinguish different web sites without depending on the IP address to distinguish them. - Jim Gettys HTTP/1.1 editor.
The people behind IETF & W3C amaze me. Seriously, can you imagine how hard it is to get a world-wide collection of people, some of which don't even speak the same language, to actually agree on technical issues? It has to be damn difficult. Thus the slow painful process of getting the standards passed through.
I wonder if those organizations are built using the same ideas of the original routing protocols:) Route around trouble, with no built-in solution to thrashing.
Seriously, can such an organization keep up with the explosive growth of the Internet? Will IPv6 get out before I need my toaster to have an IP address? And does anyone know where IPv5 went?
I assume this means that Netscape 4.6 supports HTTP 1.1, if everybody has had it, and this is just an official pat on the head. Am I right?
Just curious,
Joe
...Software Programmers are constantly trying to come up with the next best idiot proof software. The Universe, in the meantime, is trying to come up with the best idiot. So far the Universe is winning.
It really is all about latency. This matters even more if you are behind a firewall like I am all day.
Virutal hosts and authentication
by
Chronoforge
·
· Score: 3
I'll try to answer a couple of the big questions I've seen here from RFC 2616 (HTTP/1.1) and the Apache docs.
Virtual hosts: Currently, a request looks something like GET / HTTP/1.0
But under HTTP/1.1, it looks more like GET / HTTP/1.1 HOST www.example.com
This way, the webserver knows what domain to serve the request from.
Now, this assumes that you referred to the webserver by name. If you refer to it by IP, the request looks like: GET / HTTP/1.1 HOST 192.168.12.27
Or, if you're using an HTTP/1.0 browser, the request would be GET / HTTP/1.0
In either case, Apache (I don't know about other servers cause I don't use them) will serve the request from the first VHost that matches that IP -- see http://www.apache.org/docs/vhosts/name-based.html
Thus, If you're running a children's educational site and a pr0n site on the same IP, not only are you an idiot, you should have the server direct older browsers and non-DNS users to a page that says 'Oops' (and possibly a list of the sites you serve).
Authentication: Under HTTP/1.0, the only supported authentication mode was basic. The username and password were base64 encoded for transmission, but not encrypted.
With HTTP/1.1 we get MD5 encoding.
This whole message will make a lot more sense if you read the Apache docs, RFC 1945 (HTTP/1.0, it's shorter than 2616[HTTP/1.1], and good for the basics), and RFC 2617 (Basic and Digest HTTP Authentication).
HTTP 1.1 supports request pipelining, so that the browser could (conceivably) make one big request for everything on a page, and the server would then start sending data as soon as it can. This is similar (possibly the same?) as "keepalive"
I think it takes 3 packets to setup a TCP connection (correct me if I'm wrong), and since you don't have to open a new socket for each request, you can save quite a few packets.
Also, I'm not sure, but I think that with pipelining, the browser only needs to send the request headers once for all the requests in a given pieline. If this is true, it could significantly cut down on traffic.
It's nice to see that "governing bodies" in cyberspace suffer from the same problems as governing bodies in meatspace... particularly insane slowness.
-nate
Re:Yup, HTTP 1.1 is old news. Being a standard isn
by
mistabobdobalina
·
· Score: 1
right and i think that w3c/ietf etc. needd to address this. while they are in quorum arguing, standards get set by vendors, including standard which may be designed to benefit CERTAIN platforms. the standards bodies need to streamline and speed up the process - look at whats happened to xml: multiple competing standards, no clear direction, and vendors creating weirdo solutions such as wddx to work around the snail's pace of the w3c
The long ratification times can be annoying, but it's better than the alternatives. We're all frustrated at the Netscape and MSIE "extensions" to HTML. Imagine now that the HTTP was also changing as frequently.
How much time do shops waste getting "compliant" MSIE browsers and "compliant" Netscape browsers to render the same source document into reasonably close fascimiles? How many shops give up and have separate MSIE and Netscape trees?
Now multiply that by the HTTP 1.0 server, the 1.1 server, the 1.1b server, the 1.2 server, the 1.3 server, and the 2.0 server. You would either see development slow to a crawl, or a lot of shops simply announcing that they would support a single server/client pair. The one that is bundled with every PC sale due to it's unquestionable (*not* 'unquestioned!') technical excellence. *cough*
Gee, maybe Microsoft is right and having a strong Imperial hand *does* help competition. King Bill could have simply announced that everyone shall use HTTP 1.1 (after paying another $200 for the privilege of serving his liege, of course) years ago, and by now we would be running HTTP 1.4 complete with 'Microsoft' 'innovations' such as push technology, dedicated "channels", and Lord Bill knows what else.
-- For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Sure, they're doing quite well - because everybody else is paying the cost of lost productivity from MSWord macro viruses, Win95 crashes, et cetera - and that's for non-critical applications (no one with any sense should be using MSWord or Win95 for critical applications.)
The net economic value of Micro$oft's crappy software is certainly negative. Unfortunately, PHB's buy into the marketing.
-- Tom Swiss | the infamous tms | my blog You cannot wash away blood with blood
HTTP/1.1 must have been around FOREVER before becoming a standard now, because without reading any RFCs, I've been building a proxy which is based on parsing
GET http://some.domain.or.ip:port/
from the HTTP request (otherwise, how the heck does a proxy know who to connect to to "get" stuff??)
At least Netscape always formats requests like this...
Berkeley's TranSend service is a cluster of workstations working together to act as a massive HTTP proxy. This proxy "transforms" Web pages based on clients settings. Was the basis of the ( now-commercial) Top Gun Wingman Web browser for the PalmPilot.
The Anonymizer acts as a proxy that strips out all the unwanted/unneeded header lines that your Web browser sends.
I had started hacking together an HTTP/1.1-compliant proxy in perl that did on-the-fly compression if the client supported it, but I never got around to completing it. Initial results were impressive, especially when it was paired with a caching proxy like Squid or a CacheFlow box. Of course, with DSL and cable modems getting more widespread use, people like myself that are still pinned to a 33.6k connection are being left behind.
Caching/compressing/proxying is still in widespread usage outside North America (most notably Australia and European countries). Their problem was (is!) outrageous access prices and relatively slow overseas connections, so they've been using caching for a long time to help solve it. The US and Canada have solved their "problem" of Web pages not instantaneously loading by throwing more bandwidth at it...
They comment on how this new standard will speed up transfers, but does anyone have an idea of how much? Considering many consumers are still limited by bandwidth on their end, it generally won't get faster for them, but mostly more efficent transfers before it ends up with them. Correct? Or am I just entirely missing the point. =] Also, does anyone know how it's going to allow multi-domains on single IPs? Almost sounds like a redirect of some complex (or lack of compexity) sort. Mayhaps the daemon will take the domain requested, and devide from there? What if you just typed in the IP address? Will it default to some domain? I find this pretty confusing, but I'm no expert. But sense connections are made to IPs, not really domains (Or so I thought), I'm just slightly lost on this one.
Enter HTTP/1.1. Because you can re-use the connection for multiple objects, you only need to open _one_ TCP connection to the server to download everything. Less overhead means faster downloads, period.
Actually less overhead will mean webservers will become more scalable for high trafficked websites.
HTTP 1.1 requires the browser to transmit the domain name it has requested information from in the GET header detail. Therefore, with every connection from a browser the browser is actually telling the webserver what domain it should be serving. This is distinct from HTTP 1.0 which did not have this requirement.
I believe that Apache has had the capability to use this principle for some time.
If you just type in the IP address, then that is what your browser will report to the webserver which can then act accordingly.
That's my two penneth anyway!
--
Tally-ho, yippety-dip, and zing zang spillip. Looking forward to bullying off for the final chukka?
Slashdot Mirror
This is not "ruthless efficiency" it is incompetence. It is a prime example that rule by consensus does not work since the market has already decided that http 1.1 is the standard, so this decision is irrelevant. It's about as meaningful as Microsoft finally deciding that mp3 is the standard for audio files. Duh. Http 1.1 has been in use for at least a year. Hundreds of hosts have been supplying ipless hosting for at least a year, probably longer. I think it pretty much shows that w3c and whoever that other group is are about as relevant as Bill Clinton - the lame duck president.
:P
-eric
upgrade@netdoor.com
No user id because i can't find it
That is hte case for http 0.9. Http 1.0 has the multidomain behavior, but some W3 browsers dont impliment all of 1.0.
There are lots of web providers doing multiple domains on one IP already.
Apache has been using http/1.1 for some time now, and has the ability to host multiple domains on the same ip. This is not a new protocol, its been in use for quite some time, but W3C/IETF are so damn slow in ratifying standards that it's just now getting approved. In Apache 1.3.x you simply put the following lines to host multiple domains on the same ip.
/home/domain1/public_html
/home/domain2/public_html
NameVirtualHost 192.168.1.1 #use IP of machine
DocumentRoot
ServerAdmin webmaster@domain1.com
ServerName domain1.com
DocumentRoot
ServerAdmin webmaster@domain2.com
ServerName domain2.com
Repeat for www.domain1.com/www.domain2.com. Both domain1.com/domain2.com can be on the same ip and display different pages. This standard has been in use for so long, that even the text based lynx browser supports it. The W3C/IETF need to get their shit together.
How HTTP/1.1 will speed up Joe Public's connection:
/index.html, would look more like GET http://slashdot.org/index.html -- the request includes the domain name. An HTTP/1.1-familiar server (most all of them, these days) interprets that request and serves up the correct page. If he wants a page from yoda.blockstackers.net, his request looks something like GET http://yoda.blockstackers.net/index.html and the correct page is served.
Let's say you go to a page on slashdot.org that contains 5 elements of data; the page itself and 4 graphics. For each one of those elements, under HTTP/1.0, a browser must open a separate connection to download that element. This means, the client machine must open a separate TCP connection to the server. 5 elements on the page, 5 connections to the server. Each one of those connections is actually quite a bit of traffic, as you have to request the connection from the server, the server has to acknowledge it, then the client sends back to the server that it's ready for data. Very inefficient, when you're downloading a 100k slashdot page-filled-with-comments.
Enter HTTP/1.1. Because you can re-use the connection for multiple objects, you only need to open _one_ TCP connection to the server to download everything. Less overhead means faster downloads, period.
Now, keep in mind that this is a very hypothetical example. Real-world, browsers still open four connections (or however many you have in that Netscape config tab) to the server, so if you're only talking about a page with five elements on it, the savings is minimal. How many web pages these days only have five elements or less, though? Now you see how HTTP/1.1 can help with those bloated 60-graphics-on-a-page music sites.
As for multi-domains, I'm still not entirely clear how it's going to work, but I have an idea. Let's say slashdot.org resides on 10.0.0.1. yoda.blockstackers.net wants to be a virtual host on slashdot.org, but Rob decides that he's going to implement HTTP/1.1 virtual hosting (previously known as "Software Virtual Hosts" in Netscape Enterprise Server). He simply CNAMEs yoda.blockstackers.net to slashdot.org, or he makes an A record to 10.0.0.1 and then fires up his HTTP/1.1-compatible browser.
His request, instead of looking like GET
HTH. Please keep in mind that this may not be how the spec actually works; I'm talking out of my ass in terms of how the request actually goes. It may be on another line in the request, I don't know.
--M
slashdot cropped out my directives
/home/domain1/public_html
/home/domain2/public_html
the directives were as follows
VirtualHost domain1.com
DocumentRoot
ServerAdmin webmaster@domain1.com
ServerName domain1.com
/VirtualHost
VirtualHost domain2.com
DocumentRoot
ServerAdmin webmaster@domain2.com
ServerName domain2.com
/VirtualHost
>They HAVE to work perfectly because if they don't, the pilots will
> probably be killed and their strategic value will be lessened.
Come now. Micro$oft ships products that are not perfect...and look at how well they doing in economic terms.
i'd think the line about their speed making glaciers jealous (seeing as glaciers move very SLOWLY, get it?) would have given it away.
but hey!
i want to know when i can get a version of netscape that supports this..
That is not entirely accurate. The requests look like that when the request is sent directly to the server in question. The requests look like what the poster you replied to suggested whenever you use a proxy.
Actually, your comments about efficiency with large slashdot comment pages is flawed. The major speed up is with pages that contains lots of inlined graphics. It's connection setup and reset that demand extra traffic - the larger the file, and the fewer the amount of requests, the less HTTP/1.1 will give you (but it will never be worse that HTTP/1.0) in improved performance.
Well? Does it? And where is it mentioned in the documentation?
Seriously, can such an organization keep up with the explosive growth of the Internet?
Hmmmm .....
Perhaps you are being ironic. If so, consider me a target to hit with the clue stick.
Perhaps, though, you mean what you say. If so, perhaps you should look at it this way: these organizations are the explosive growth of the Internet. (An attempt to divide the evolution of the Internet into an IETF pile and a non-IETF pile is pointless.)
Humans (like me and you) always have difficulty in fully appreciating the nature of exponential growth.
There's always this temptation to say "Oh sure ... it was growing exponentially back then, but now it's really growing exponentially! It's different now."
Thank you, that was very helpful.
:)
(BTW: since when are pornographic and educational mutually exclusive terms?
This one should go up on the urban legends page with Craig Shergold.
One more time: NT didn't have a problem, it was the ship control app the Navy was running on it that failed.
Sorry to crush your adolescent anti-MS fantasy.
I was watching a show called "Flightpath" on Discovery channel last night and they were showing all sorts of nifty things about the new YF-22 fighter aircraft. This is the new hybrid stealth fighter that is going to replace the F-15 for general figter missions.
This plane has been under development more or less for the past 19 or 20 years. Although there are 9 or so flight ready versions of this plane which exist TODAY, there will not be any in actual military service for about 5 more years. Some people have described these planes as the most complex machines ever built. They HAVE to work perfectly because if they don't, the pilots will probably be killed and their strategic value will be lessened.
When much of the software being used today is labelled "mission critical" don't you think it should be well thought out and done PROPERLY as well? Perhaps not 25 years, but don't you find it amazing how stupid is it to spend so much money on software that only partially works?
The notion of "internet time" is complete and utter BS, invented solely to give software companies excuses for shoddy software and to make "lazy programmers" seem more productive.
GET /foo.html HTTP/1.1
But now among the headers that the browser sends in the request, you'll find one like:
Host: www.foo.com
That's what the web server uses to determine which virtual host to use. Apache has supported this for a long time; have a look at the NameVirtualHost directive.
\\'
\\'
HTTP 1.1 persistent connections allow "pipelining", so new request can be sent while previous ones aren't answered yet. HTTP 1.0 Keep-Alive extension doesn't allow that, and this is why it doesn't allow nasty DoS attack that is possible with HTTP 1.1 -- sending request that definitely will take a lot of time to be processed, then sending large number of requests for large responses (possible large ones by themselves) expecting HTTP server to overgrow its either input or output buffers to ridiculous size.
Since there is no flow control in HTTP 1.1 other than one in TCP, and TCP one can't be used because requests should be received without blocking the client, and server can't send responses to later requests before the response to earlier one, server can either buffer everything in the input and delay processing, or process them simultaneously and buffer the output -- in either way buffers will grow. The alternative is to discard the requests, however just like with other DoS cases there are no "definitely safe" conditions for this.
HTTP 1.0 with Keep-Alive requires as many TCP connections as the number of requests that are in progress simultaneously (so the routers along the way and kernel buffers in the sender may not like it), but the end result is healthier for the server -- while server didn't say anything, client won't try to reuse the same TCP connection and leave server wondering, what to do with the new request.
I don't know, which servers actually support "pipelining" in HTTP 1.1, but this DoS was the main reason why I was unable to add HTTP 1.1 support to my fhttpd -- while I have found what I consider to be reasonable solutions to other DoS in HTTP, for this one every cure that comes to my mind looks worse than the disease.
HTTP 1.1 could solve this by introduction of higher-level flow control or by multiplexing simultaneous replies (first one will create reasonable safeguards against overloading, second one will eliminate the source of the problem), however HTTP 1.1 developers in their infinite wisdom did neither.
And this is not the only flaw in HTTP 1.1.
Contrary to the popular belief, there indeed is no God.
HTTP is a transfer protocol, it's mostly ortogonal to HTML or any other document format. Comapre the difference in results from number of ways, one can use to retrieve email (unix mail files, mh mailboxes, every possible mailbox format up to Hudson and Squish, POP, IMAP, M$ Exchange) and the result of differences in standards in email message format (RFC822 with plain text, MIME in all of its incarnations, widely accepted deviations and possible encodings, HTML in email, windoze-specific file formats in email attachments, etc.).
Contrary to the popular belief, there indeed is no God.
Well it's actually pretty close.
:)
For each packet of data the web browser itself sends, a new stream of data had to be opened.
Since the web browser itself doesn't do ACK's on packets, all data which the web browser sent were requests.
Of course, that doesn't change the fact that they did use the wrong terminology throughout the article
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
All major web servers implemented HTTP 1.1 looong ago. It's only now, however, that the bodies have actually approved of them as standards.
Which raises the question...
What use are standards when everyone's using a newer version the standards body hasn't yet ratified?
If this is, as you describe, a standard challenge-response protocol, then it isn't all that secure.
First, the server has to store your password so that it can work out the "correct" answer to your challenge. Compare this to Unix passwords: an attacker can read everything on your hard drive and still not know what to present in order to log in.
Worse, if I can intercept just one exchange with the server I can start trying to guess your passphrase. Passphrases tend not to be very well chosen, so guessing attacks are rather too effective and it's important to make them as difficult as possible.
Anyone who needs to use networked passwords should implement both of the following techniques if at all possible:
Key stretching: http://www.counterpane.com/low-entropy.html
SRP:
http://srp.stanford.edu/srp/index.html
These papers make clear the problems that arise if you *don't* use these techniques...
http://srp.stanford.edu/srp/index.html
--
Employ me! Unix,Linux,crypto/security,Perl,C/C++,distance work. Edinburgh UK.
Xenu loves you!
"Version 1.1 also allows for the secure transfer of passwords"
hows uncle sam going to take to this? is it a
munition? crypto laws suck...
Hey, that was completely *on* topic.
...at least if we're still talking about the need for making the web faster for everyone. *sigh*
PEBKAC...
pb Reply or e-mail; don't vaguely moderate.
What's wrong with HTTP 0.9? All I really *need* is "GET /" anyhow... :)
pb Reply or e-mail; don't vaguely moderate.
Commitment to open standards is all very well, but the standards bodies themselves need to commit to ratifying those standards while there is still a business case to use them.
Products and markets won't wait if a 'proprietry' solution gets the job done now - budgets need to be spent.
This sig left unintentionally blank.
If that's the case, then it may provide a noticeable improvements for people with higher-speed connections.
It can help slow connections even more by saving the latency of the three way handshake and by not having to do slow start (with more latency) for each file transfer.
A new TCP stream for each packet? No wonder the world wide web is so slow! :P
I wonder if it's hopeless to think the media in general can get terminologies correct.
NetBSD: the cathedral vs the bizzare.
I'm confused - I thought HTTP 1.1 was old news. Don't a bunch of servers and web browsers already support this? I know IE 4.0 does - under the advanced options, you can select whether it uses HTTP 1.1.
Timur Tabi
Remove "nospam_" from email address
Yes
Browsers try to hide the problem, opening many connections at a time so that connection establishments can be overlayed with transfers, and that transfer speeds sum up.
The point of HTTP/1.1 is to transfer many objects back-to-back using a single tcp connection, so you pay connection time and slow start only once for all those objects. Browsers will still be allowed to open many connections at once, but only up to two per server, to be nice with others
Also, does anyone know how it's going to allow multi-domains on single IPs? Almost sounds like a redirect of some complex (or lack of compexity) sort. Mayhaps the daemon will take the domain requested, and devide from there? The domain of the URL you requested will be sent in the HTTP request. It is already done right now (with HTTP/1.0 ?), but will be _required_ by HTTP/1.1.
What if you just typed in the IP address? Will it default to some domain? I find this pretty confusing, but I'm no expert.
That's up to the server.
But sense connections are made to IPs, not really domains (Or so I thought), I'm just slightly lost on this one.
You're correct, and that's why it needs to be specified in the HTTP request headers.
Btw, how new is all this ? Last time I checked, Apache 1.3.x is already HTTP/1.1 compliant, no ?
It takes a few roundtrips to set up a socket, plus some more roundtrips to get the window size > 1, so the server can send more than one packet before waiting for an ack. Until that happens, you're essentially in half-duplex mode.
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
That should actually be "Host: www.example.com"
Are you thinking of Digest authentication? Unfortunately I have yet to see a browser that implements it. I have implemented it in my own client that uses the PUT command, but I cannot yet switch the server to use it because no other client knows how to do it.
These are the people that invented HTTP/1.1 in the first place. It has been in development for years, and software developers have implemented what's been ready so far, but all the details hadn't been finalized. Those years were spent ironing out every last little contradiction, ambiguity, and other problem that could be found in the spec, so that we'll be able to use it as long as possible into the future. Your "market" has been looking to these people to make the decisions, because anyone who writes network software knows we need standards, and anyone who's developed much software at all knows that underlying systems must be planned carefully, or they'll fall apart sooner rather than later. The people who made HTTP/1.1 include connections with all the major players in the "market".
By the way, if you think the W3C and IETF are irrelevant, you don't know much about the Internet. And random, vague political bashing doesn't score much in the brains department.
'IPv5' was called ST2 - a connection-oriented protocol that supported QoS. However I don't think anyone really uses it now with a few specialised non-Internet exceptions.
One thing I do like about it is the ability to use multiple names per IP address. But this sort of kills the elegance of design of domains going from TLD, First level domain, and so on. But if I'm interpretting it correctly, it should kill alot of the refer jumps. I wonder what the speed difference is with the fact of concatenating packets into streams rather than placing 1 packet per 1 stream. I'd guess that for small servers it would be trivial but for large ones the change would be enormous.
Suddenly, the hairy finger of a familiar monkey tapped me on the shoulder. It was time.--G. T.
http://www.gcn.com/gcn/1998/July13/cov2.htm
-- Don't Tase me, bro!
Andwer to: "allow multi-domains on single IPs?" Currently, under HTTP 1.0, an HTTP request does not include the hostname as part of the request. The requests look like:
/foo.html HTTP/1.0'
'GET
Becuase the hostname is not included, the web server that responded to the socket request on that port/IP combination would have to serve pages from it's default htdocs root directory. With HTTP 1.1, the reqests are going to include the hostname. Don't quote me on the syntax, but they might look something like this:
'GET http://www.foo.com/foo.html HTTP/1.1'
With this format, the web server knows the request for was a website named 'www.foo.com', and can look into the appropriate htdocs root directory. And all of this can be one using a single port/IP combination.
-jason
It wasn't quite as glacial as one might think.
The draft standard was approved in March; the
RFC issued recently when the RFC editor caught
up on backlog. The internet drafts have not had
a significant change for nearly a year. Most
vendors have been working to the ID's for a long
time.
HTTP/1.1 has already been pretty widely deployed:
this was the approval of the draft standard,
rather than the proposed standard.
As to performance stuff, see:
http://www.w3.org/Protocols/HTTP/Performance/
As to recovering IP addresses, most clients
have been sending the host name as part of the
request using the HOST header for a long while.
This means you can distinguish different web sites
without depending on the IP address to distinguish
them.
- Jim Gettys
HTTP/1.1 editor.
I wonder if those organizations are built using the same ideas of the original routing protocols
Seriously, can such an organization keep up with the explosive growth of the Internet? Will IPv6 get out before I need my toaster to have an IP address? And does anyone know where IPv5 went?
So many questions.... --Mid
I assume this means that Netscape 4.6 supports HTTP 1.1, if everybody has had it, and this is just an official pat on the head. Am I right?
Just curious,
Joe
...Software Programmers are constantly trying to come up with the next best idiot proof software. The Universe, in the meantime, is trying to come up with the best idiot.
So far the Universe is winning.
It really is all about latency. This matters even more if you are behind a firewall like I am all day.
I'll try to answer a couple of the big questions I've seen here from RFC 2616 (HTTP/1.1) and the Apache docs.
Virtual hosts:
Currently, a request looks something like
GET / HTTP/1.0
But under HTTP/1.1, it looks more like
GET / HTTP/1.1
HOST www.example.com
This way, the webserver knows what domain to serve the request from.
Now, this assumes that you referred to the webserver by name. If you refer to it by IP, the request looks like:
GET / HTTP/1.1
HOST 192.168.12.27
Or, if you're using an HTTP/1.0 browser, the request would be
GET / HTTP/1.0
In either case, Apache (I don't know about other servers cause I don't use them) will serve the request from the first VHost that matches that IP -- see http://www.apache.org/docs/vhosts/name-based.html
Thus, If you're running a children's educational site and a pr0n site on the same IP, not only are you an idiot, you should have the server direct older browsers and non-DNS users to a page that says 'Oops' (and possibly a list of the sites you serve).
Authentication:
Under HTTP/1.0, the only supported authentication mode was basic. The username and password were base64 encoded for transmission, but not encrypted.
With HTTP/1.1 we get MD5 encoding.
This whole message will make a lot more sense if you read the Apache docs, RFC 1945 (HTTP/1.0, it's shorter than 2616[HTTP/1.1], and good for the basics), and RFC 2617 (Basic and Digest HTTP Authentication).
--
Dave Richardson
HTTP 1.1 supports request pipelining, so that the browser could (conceivably) make one big request for everything on a page, and the server would then start sending data as soon as it can. This is similar (possibly the same?) as "keepalive"
I think it takes 3 packets to setup a TCP connection (correct me if I'm wrong), and since you don't have to open a new socket for each request, you can save quite a few packets.
Also, I'm not sure, but I think that with pipelining, the browser only needs to send the request headers once for all the requests in a given pieline. If this is true, it could significantly cut down on traffic.
It's nice to see that "governing bodies" in cyberspace suffer from the same problems as governing bodies in meatspace... particularly insane slowness.
-nate
right and i think that w3c/ietf etc. needd to address this. while they are in quorum arguing, standards get set by vendors, including standard which may be designed to benefit CERTAIN platforms. the standards bodies need to streamline and speed up the process - look at whats happened to xml: multiple competing standards, no clear direction, and vendors creating weirdo solutions such as wddx to work around the snail's pace of the w3c
-- your knees hurt, don't they?
The long ratification times can be annoying, but it's better than the alternatives. We're all frustrated at the Netscape and MSIE "extensions" to HTML. Imagine now that the HTTP was also changing as frequently.
How much time do shops waste getting "compliant" MSIE browsers and "compliant" Netscape browsers to render the same source document into reasonably close fascimiles? How many shops give up and have separate MSIE and Netscape trees?
Now multiply that by the HTTP 1.0 server, the 1.1 server, the 1.1b server, the 1.2 server, the 1.3 server, and the 2.0 server. You would either see development slow to a crawl, or a lot of shops simply announcing that they would support a single server/client pair. The one that is bundled with every PC sale due to it's unquestionable (*not* 'unquestioned!') technical excellence. *cough*
Gee, maybe Microsoft is right and having a strong Imperial hand *does* help competition. King Bill could have simply announced that everyone shall use HTTP 1.1 (after paying another $200 for the privilege of serving his liege, of course) years ago, and by now we would be running HTTP 1.4 complete with 'Microsoft' 'innovations' such as push technology, dedicated "channels", and Lord Bill knows what else.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The net economic value of Micro$oft's crappy software is certainly negative. Unfortunately, PHB's buy into the marketing.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
HTTP/1.1 must have been around FOREVER before becoming a standard now, because without reading any RFCs, I've been building a proxy which is based on parsing
GET http://some.domain.or.ip:port/
from the HTTP request (otherwise, how the heck does a proxy know who to connect to to "get" stuff??)
At least Netscape always formats requests like this...
It's 10 PM. Do you know if you're un-American?
Here are a few more links for more information about HTTP and some neat things that are being done with it...
I had started hacking together an HTTP/1.1-compliant proxy in perl that did on-the-fly compression if the client supported it, but I never got around to completing it. Initial results were impressive, especially when it was paired with a caching proxy like Squid or a CacheFlow box. Of course, with DSL and cable modems getting more widespread use, people like myself that are still pinned to a 33.6k connection are being left behind.
Caching/compressing/proxying is still in widespread usage outside North America (most notably Australia and European countries). Their problem was (is!) outrageous access prices and relatively slow overseas connections, so they've been using caching for a long time to help solve it. The US and Canada have solved their "problem" of Web pages not instantaneously loading by throwing more bandwidth at it...
They comment on how this new standard will speed up transfers, but does anyone have an idea of how much? Considering many consumers are still limited by bandwidth on their end, it generally won't get faster for them, but mostly more efficent transfers before it ends up with them. Correct? Or am I just entirely missing the point. =]
Also, does anyone know how it's going to allow multi-domains on single IPs? Almost sounds like a redirect of some complex (or lack of compexity) sort. Mayhaps the daemon will take the domain requested, and devide from there? What if you just typed in the IP address? Will it default to some domain? I find this pretty confusing, but I'm no expert. But sense connections are made to IPs, not really domains (Or so I thought), I'm just slightly lost on this one.