Slashdot Mirror
HTTP's Days Numbered
dlek writes: "ZDNet is running an article in which a Microsoft .Net engineer declares HTTP's days are numbered. (For those of you just tuning in, HTTP is the primary protocol for the world-wide web.) Among the tidbits in this manifesto is the inference that HTTP is problematic primarily because it's asymmetric--it's not peer-to-peer, therefore it's obsolete. Hey everybody, P2P was around long before Napster, and was rejected when client-server architecture was more appropriate!"
Anyone who has tried to understand the various "standards" for web services and their associated train wreck (I think I'm being gracious here) would realize that most of them are bolted on to a protocol that was never meant to serve them in such a way. HTTP is meant for quick requests, not monoloithic requests that take a long time.
Before you rush to say Mickeysoft is destroying the web, please realize that he's referring to web services, not your personal home page (although I'd imagine they'd like to make that proprietary too).
My Slashdot account is old enough to drink...
-- Ed Avis ed@membled.com
There are obvious reasons to replace HTTP - the most obvious being the creation of true stateful transactions. That said, there will be support for HTTP until 2025 at least, and ultimately legacy support for HTTP will be painful and necessary for coders.
"HTTP's days as an RPC transport are numbered"
HTTP works great for a large number of purposes. It will continue to work great for a large number of purposes. However, it is not so great when you are trying to build powerful RPC mechanisms like SOAP on top of it. It's the latter where HTTP will slowly loose favor.
Your web browser will still be making HTTP requests for HTML documents many years into the future...
The problem is, most machines aren't even really *on* the internet anymore, just on the Web. Which is not as powerful, so you end up with these godawful kludges trying to run applications over HTTP.
The Right Thing would be to get IPv6 out, make local client firewalls and sandboxing standard, and ditch NAT and central firewalls.
Yeah, right.
Instead we have SOAP, a RPC-over-HTTP kludge. We may as well run PPP-over-HTTP and have done with it...
So, will the new protocol help serve web pages from Mars, where the time delay a quite long?
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
Richard von Weizs
Oh yeah, and all operating systems besides Windows XP are obsolete.
ROFL.
By the way, the funniest quote in the article was:
Microsoft has some ideas (on how to break the independence on HTTP)
Now that was a Freudian slip... ;-)
299,792,458 m/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
HTTP does have it's problems, and it's one of the reasons that Jabber has it's own internal transport protocol to accomplish IM.
I've seen other proposals for HTTP replacements and have been less-than-pleased by their complexity and design. Based on what I've learned from Jabber, and great feedback from many in the open source and standards communities, XATP was born:
http://xatp.org/
XATP, the eXtensible Application Transport Protocol is very simplistic and geared to operate at a layer below content, identity, framing, and other application-level issues. Check it out and offer feedback or participate if your interested.
Jer
Didn't Cringely claim several months ago that they were going to try to do this? Well, not quite, but back in August he wrote:
So they decided to go up one level of abstraction. Hell why not, that way they break even more competing products.
Nope, no sig
Gee, I wonder WHAT shape will that holocaust take. Maybe it'll be a killer protocol that pursues and assasinates other protocols? Damn, Mr. Box, use the proper words, will you?
This works for small transactions asking for Web pages, but when Web services start running transactions that take some time to complete over the protocol, the model fails. "If it takes three minutes for a response, it is not really HTTP any more," Box said.
Well, of course it isn't. Is it, then, HTTP's fault that it doesn't work perfectly when used for stuff it wasn't designed to do? Hell, I'd love to see telnet-over-HTTP done while we're at this.
"We have to do something to make it (HTTP) less important," said Box. "If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days."
Maybe if we get back to use the proper protocols (say, why don't we rely on ftp for transferring files, for example?), we wouldn't have the current "problem".
Another problem with HTTP, said Box, is that it is asymmetric. "Only one entity can initiate an exchange over HTTP, the other entity is passive, and can only respond. For peer-to-peer applications this is not really suitable," he said.
Of course it isn't, HTTP is designed with a client-server model in mind.
In my humble opinion, this is just the first step from Microsoft for a new FUD campaign against HTTP: "First, we show everyone how HTTP isn't any good, then we roll over our brand new protocol that supports all of HTTP's capabilities, and lacks its limitations. Buy it from us, your beloved Microsoft!".
"Microsoft has some ideas (on how to break the independence on HTTP), IBM has some ideas, and others have ideas. We'll see," he said. But, he added, "if one vendor does it on their own, it will simply not be worth the trouble."
This, of course, implies that Microsoft won't control the new protocol on its own... not at first. They'll just "embrace and extend" it later.
"Trust me - I know what I'm doing."
- Sledge Hammer
while it's certainly true that http was never originally ENVISIONED as a protocol to serve shoutcast/icecast streams, for example, it's usefulness to that purpose is a tribute to how well the spec was thought out. the simple fact remains that it's an incredibly versatile protocol which can be (and is) used for nearly every data/media transport/request over the internet. microsoft is going to have to do something FAR more impressive to convince me they have a good reason to scuttle the most re-purposeable protocol on the internet.
ever wonder why 99% of ANY urls you see start with an http? ever wonder why flash webpages don't start with something like mmfttp and shoutcast streams don't start with plsttp?
wonder.
seem to remember that some time in the past MS claimed that the Internet was obsolete and the MicroSoft Network was the future. I think Unix is also obsolete according to MS.
And of course I am obsolete since I refuse to view MS products as anything else than toys. Admittedly by now toys that actually have some level of stability and can be used for some (limited) tasks without too much hassle. But as long as they insist on sitting on their island (admittedly a large one, but instable and plagued by document-rot), I will not consider their products "professional" in any sense.
Incidently the only argument in the article (aside from the "argument" that P2P is better than client-server, given as dogma) is that there are problems with transactions that have several minutes connection time. I am sorry, but I don't see how that makes http obsolete. First these long transaction are not that common and second they work fine. Or are we going towards an Internet where a telnet/ssh connection will be terminated after 3 minutes, because the backbone cannot cope?
Pure FUD, as far as I can tell.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Using TCP is a shortcut, and lazy.
Until you end up reimplementing half of it on top of UDP. Badly. And yes, I've seen this multiple times.
Enough with the NIH, please? There are many years of effort in the common TCP stacks, and many subtle things they do right that you'll miss the first dozen implementations.
For the love of god, if you need a substancial subset of TCP's features, and can live with the overhead, use TCP!
Who in the world would want to administer seperate client firewalls? Sure, sounds great at home with 5 machines, now do it with 5000. No way that will ever happen.
A good centrally administered firewall won't stop you from doing what you need to do. If a protocol is well thought out NAT will not cause a problem.
Put the data you need to track in a database table or two and use hidden form vars to build the query to grab what you want.... Instant serverside cookies... No muss... Just another fscking query....
The problem with HTTP, as with any stateless protocol, is that there often are (or should be) relationships between requests. Ordering relationships are common, for example, as are authentication states. Stateless protocols are easier to implement, and thus should be preferred when such "implicit state" is not an issue, but in many other situations a protocol that knew something about state could be more efficient. All of this session-related cookie and URL-munging BS could just go away if the RPC-like parts of HTTP were changed to run on top of a generic session protocol.
Another error embodied in HTTP - and it's one of my pet peeves - is that it fails to separate heartbeat/liveness checking from the operational aspects of the protocol. Failure detection and recovery gets so much easier when any two communicating nodes track their connectedness using one protocol and every other protocol can adopt a simple approach of "just keep trying until we're notified [from the liveness protocol] that our peer has died". This is especially true when there are multiple top-level protocols each concerned with peer liveness, or when a request gets forwarded through multiple proxies. As before, having the RPC-like parts of HTTP run on top of a generic failure detection/recovery layer would give us a web that's much more robust and also (icing on the cake) easier to program for.
I don't know if any of this is what Don Box was getting at, but in very abstract terms he's right about HTTP being a lame protocol.
Slashdot - News for Herds. Stuff that Splatters.
Capabilities like chunked-encoding allow HTTP to not know how long the response will be before transmission begins. Explicit instructions for weather the connection is to remain open or closed after the request is complete. Support for acknowledgment before large data chunks are sent to server. Mandatory backward compatibility certainly hasn't taken anything away from the party. All of this is perfect for Client-Server, yes even "monolithic" actions.
Now if you want to use HTTP to do P2P, then most likely you're only doing it so corporate users can flow out from behind their various firewalls without getting special permission from the IS department. Perhaps, HTTP isn't right in those situatins, but that doesn't mean something is wrong with HTTP. Put the blame where its due.
I knew it was only a matter of time before Microsoft realized it didn't need HTTP anymore. Granted, that isn't *exactly* what this article is talking about, but I think they're just warming up. If you read carefully, they're not just attacking HTTP as an RPC transport, but HTTP because it is an RPC protocol.
Why bother with HTTP, FTP, SMTP, POP, IMAP, etc when they control most of the clients and almost half the servers on the Internet. They could replace all those with their own set of protocols or, more likely, a single MS-specific protocol. They say they're already working on some new RPC solution right here in this article. It isn't too hard to imagine them introducing this WindowsProtocol on the server and in some beta of MSIE. Then MSIE starts to try to use WindowsProtocol for any network communications before falling back to the standard protocols. In 3-5 years when they're up to 60% or 70% of the server market, server side Windows has an option that is default "on" that disables non-WindowsProtocol connections and client-side Windows starts asking the user if they want to enable connections to "legacy" services, while warning them that it isn't Microsoft so it can't be good. After that, who would run a server that can't accept connections from 90% of consumer computers?
Of course I don't want this to happen, but what's to stop them? I doubt the <5% of us that realize its wrong will be able to.
Maybe I'm just getting a little George Carlin- grumpy lately, maybe it's because I'm writing a eulogy for a friend's funeral, maybe it's because I'm sick of people at MS attempting to form competent sentences (please, stick with those inspired dance routines!), but please tell me: What's days aren't numbered?
HTTP has its issues, but referring to it as "the cockroah of the internet" and saying its days are numbered, and then saying that MS has a P2P solution!, just goes to show that not only are they power hungry in Redmond but seriously power-tripping...
Arrgghhhh....
1. As everyone knows, the WWW is the Internet.
2. Since the web runs using HTTP, http runs the Internet.
3. HTTP can't do everything the Internet can offer.
4. While there are other protocols out there (like ftp, p2p, telnet), only hackers and pirates use them, so they must be insecure.
5. Therefore, we must change http or the Internet is doomed.
The Internet is generally stupid
Try sending an email to MS customer support
-- It's better to be pissed off than pissed on.
MSTP .Net
.Net which will be used by the WWN (World Wide .Net) for anything from ms-mail (sending electronic messages to friends and family) to paying your ms-mortgage.
Microsoft will be anouncing Microsoft Transfer Protocol
I have a website. It's about Macs.
"If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days."
If I am reading his statement correctly, Box feels HTTP is not suitable for processes that take long period to get a response. Even if you remove HTTP layer from SOAP, you would still have a problem. Say some one decides to by pass HTTP, use raw sockets and establish persistent connections. This means a stateful application has to be built on top of SOAP. I'm just guessing, but if Box is saying RPC has to have sessions and be stateful, that isn't a full solution. If a process like "place a stock order for MSFT when the price is less than 50.00 buy," a stateful application may not be the best solution. It might take 1 day or 2 months for the price to drop below $50.00.
Microsoft is a supporter of XLang which tries to address the problem of stateful transactions. One of the problems of this approach that I can see is it is limited in scalability and timeout. Once you say all transactions need to be stateful, what is an acceptable timeout? Do all transaction require the same timeout period? What are the rules governming timeout, persistence, and garbage collection of invalid/expired states?
Why not use event based protocol with rules to provide a higher level of abstraction than XLang. The way XLang treats transaction is with case statements. On the surface that sounds fine, until you realize for every company you do business with, you will have to add cases to handle new situations, which rapidly makes the system harder to maintain. EBXml in my mind uses a better approach, which divides business and functional logic and suggests rules as a possible mechanism. HTTP isn't really the problem for long processes (as in weeks and months). A better solution is event based protocol, so using HTTP isn't a big deal. This doesn't mean there are cases where HTTP is really bad for transactions. Cases where response time is a huge factor in processing a transaction, a persistent connection would be more suitable. Things like day trading applications where response time affects the price, you would be better off using persistent connections for RPC. It would suck for a day trading application to loose a buy order because there was a sudden spike in requests and the system couldn't reconnect to send confirmation. Having a persistent connection in this case is the best solution, because response time has to be rapid.
Mr. Box was not saything that HTTP is not good as a Hyper Text Transfer protocol, he was stating that it's being manipulated to perform RPC, which is true. The theme of the artical was on how HTTP is bad for RPC, which you seem to also agree with.
Simply because this guy now works at Microsoft does not mean he has an agenda for evil. As a matter of fact before working for Microsoft Mr. Box started a little company called DevelopMentor, He's also written a few books One of which is concedered "The" book on COM, Essential COM, ask any COM developer worth their salt if they own a copy, they do.
I've known of Mr. Box for years now and trully recpect him as a technical writter and developer and I honestly don't think that he would shill for Microsoft.
-Jon
this is my sig.
Yeah, I know with the Linux-hype over, some people feel very "objective" when they treat Microsoft's marketing schemes like the word of god.
However:
Will it become the standard on Windows? Sure, just like the Win32API - just like any api Microsoft pushes.
Will it harm or endange other operating systems? No. Worst case is that everything stays the same and Linux can't run Windows-programs. Best-case is that Mono allows Windows-compatibility which would benefit Linux greatly.
Sure both have flaws. But they are so entrenched, they'll never be displodged.
"But, he said, we can't stay on HTTP forever, despite all the investment and engineering that have gone into it. Among the problems with HTTP, said Box, is the fact that it is a [Not Owned By Microsoft] Remote Procedure Call (RPC) protocol; something that one [Non-MS] program (such as a [Netscape] browser) uses to request a [Potentially Unlicensed] service from another program located in another [NOT WINDOWS] computer (the server) in a network without having to understand [Proprietary] network details.
"We have to do something to make it (HTTP) less important," said Box. "If we rely on HTTP we will [Never Own The Internet Right Down To The Roots]. We at least have to raise the level of abstraction, so that we have an industry-wide [Monopoly] way to do long-running requests--I need a way to [Make Money Writing Books On How To Use Our Protocol].
that may or may not exist.
Just because I get an email from some machine, doesn't mean that it really originated there or that it wasn't maliciously crafted or altered by some sleeper virus.
You know why M$ wants to get rid of the TCP/IP stack don't you. They didn't write it, and it works. It replaced their own, which didn't work.
They want to stamp out any trace of non M$ code in their OS.
Maybe BelCore or Multics organization, or even IBM should sue them for copyright or patent violation on the use of recursive structures like sub-directories.
If they rip out the stack, I predict a wave of new virus exploits the likes of which hasn't been seen yet.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
"I need a way to send a request to a server and not the get result for five days."
No doubt so the server can be rebooted three or four times...
i know! how about letting microsoft embrace and extend HTTP and make a new protocol that they control.
they can start implementing it in IE and Windows first, then over time completely remove support for things like HTTP.
i think i just threw up in my mouth.
HTTP is a protocol that was developed as a solution to a problem. That didn't mean we stopped using POP, FTP, Gopher, Telnet, KERMIT, etc., as they were developed to solve different problems. Now the new problem is Web Services, and the solution should not mean that we will stop using HTTP it to deliver web pages, or FTP to move files. We should not fear a new protocol (assuming it is good & worthy). As long as the solution has an IETF RFC number, with all the consultation and work required, it can be implemented by anyone. Remember HTTP wasn't invented by Microsoft, Netscape or even Linus. If you don't want Microsoft, AOL, Oracle or the MPAA developing the next solution, then come up with a great idea and start submitting RFCs.
HTTP is old and needs to be replaced, as soon as we can figure out what the best replacement is.
Er, why? Am I not being advertised to in the most efficient, flashy manner?
Fuck, the majority of what I use the web for could be handled by Gopher, let alone this fancy pants HTTP protocol.
--saint
ADMISSION: This post is the result of original ideas added to shameless [plagiarism | merciful summation] of other posts on this topic.
.)
:)
From the article:
I need a way to send a request to a server and not the get result for five days.
How about email?
As so many people have said, the whole problem comes from an over-reliance of HTTP. If you need the request in 5 days, you probably need some other kind of service.
However, his complaint about the time-frame of HTTP requests has deeper implications than he perhaps realizes. For example, if your request takes 5 days, you'd better be ready to compensate your content provider for machine usage, because it must be extremely resource intensive. (Maybe MS passport could help out.
If I'm requesting a reply over a 5-day time frame, ideally I would not need to have my machine powered up to receive the replay, as most machines are turned off daily. So, some kind of asynchronous protocol with intermediate storage -- like email -- would be required.
So, we need a service that checks for the latest server responses whenever you start it up, and automatically keeps track of how much you should be charged for each transaction. Actually, I think an HTTP/SMTP implementation would not be poorly suited, at least with a Free Software application server doing the heavy lifting. (See another posting on MS and intellectual "property" sharing.)
A new PHP function: do_5_day_request_and_charge_for_it($user, $args)
{
do_lots_of_stuff($args);
charge_lots_of_money($user);
}
I'll write that function if you promise royalties off each function call
Of course, if you wanted a seriously secure system, you would either require credit card info beforehand or require payment before issuing the response (at least for new users) to discourage fraud.
What I want to know is this; what is going to replace http? The article really doesn't say other than alluding to p2p as the way of the future.
Now, I may agree that p2p will be way cool as its uses are just barely beginning to be explored but I don't think we will see http disappear any time soon. I wouldn't be surprised if five years from now things are essentially the same as they are now in this respect and http is still a staple of many things web related.
And this;
Why? If you make a request and it takes you that long to respond... your clients will search for a different source for the data. How many customers do websites lose for loading slow in the first place? You might as well use snailmail for that kind of stuff.
So... mod me down if you must but somebody please explain what Box is talking about here.
Prospecting Stinks. Stop Wasting Time on Cold Calling.
As Bruce Schneier says, the cutting edge is always moving, but the low-end is here to stay.
Old standards have a way of hanging on, even when there are superior replacements. Look at all the strange, vestigial crap in PC hardware. Look at NTSC video, 8.3 filenames. You'd be amazed how many large companies keep important data in VSAM files instead of real databases. People might start using new standards for new applications, but the old standards will still cling in the old applications or eveb in new applications that must interact with old ones.
Are there exceptions where old technology was phased quickly? Sure. The cost of change can be high, and business people generally want technology that is Good Enough rather than following the latest and greates trends just for their own sake.
You should see the old tech that is still used in the finantial sector. In these parts, the rule of thumb is "If it ain't broke, don't fix it." When you are dealing with people's money (and government regulations therof), the cost of botching a change is very high.
--mkb
I've never heard Don Box described as just a .Net engineer. That'd be like calling Richard W. Stevens just a "C programmer."
/. is with the Windows world.
Thanks for the laugh. It's always good to be reminded just how out of touch
But how is MiscroSoft going to get .NET into the homes of the average computer user?
.NET into homes. Office has been their most recent candidate, but most users can either get by without it, or will use older versions (95, 97, 2000, XP) The latter having some, but not all, of the available infiltration functionality built in. Windows Media is a likely future choice, but if downloads become too bloated, user will likely turn elsewhere.
Most of them are still on Windows 98 -- and don't see any convincing reason to change. They've seen four "new" versions of windows and many have tried them and gone back to 98. MicroSoft's delivery mechanism has been the Windows Update (which most people without broadband or with a healthy sense of paranoia disable) and Internet Explorer. With IE 5.5 now fairly usable and standardized, they'll need a new app to get
Microsoft's only vehicle now seems to be new systems from OEMs. Unfortunately, hardware is no longer the limiting factor for most users.