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!"

Comments

Well Duh...

[pridkett]

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).

What the title _should_ read:

[PureFiction]

"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...

NAT & Firewalls

[mikeee]

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...

Re:NAT & Firewalls

[mikeee]

If you don't have a real, static IP, no, you aren't really on the internet.

If you are behind a firewall that only allows HTTP, no. If it only allows outgoing connections, not really. All you can do is what HTTP can do, which is much less than IP can.

It would be really sad if the net were reduced to the web. "You say you need IP connectivity? Are you some kind of hacker?"

Re:NAT & Firewalls

[GSloop]

Yeah, let me run and open every port to every caller! I guess I was completely crazy to close off all those ports and limit connections for any and every service...

[Sheesh] Security and Convience will ALWAYS play off against each other. If you have locks on your house, you're not really getting the full benefit of a house!? Sure, locks make life more "inconvenient." But you trade some convenience for security. I close off all those ports because I don't know what might be used to exploit the openings.

Now, we'll get to arguing about packet filtering vs. proxy filtering and how proxies are better...blah blah blah.

In short, I want a BALANCE of convenience and security. Blocking some content (ports/hosts) is a way to do that. That's a good thing in a system that's setup right. Does your company let anyone into the building that wants to get in, and only disallow those that it activly sees doing mischief? No (at least for your sake I hope) they don't. They say, do you have some purpose here? Are you explicitly allowed. Then you get in.

Frankly you can argue about NAT and unblocked connections all you want. What my clients want is functionality. The functionality of the network is compromised by too open a security (too much functionality) of the internet. They want the machines to work, the data to get processed, and to spend as little money as possible fighting battles. The solution is only to open that which needs to be open to acomplish the business objectives.

Cheers!

not so sure about that...

[Narcocide]

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.

Re:not so sure about that...

[dkemist]

You still have to conceed the point that http evolved to where it is today, and if one had to design something from scratch, it would likely be far different.

I mean, let's take a connection oriented protocol like TCP and add a text based stateless protocol on top of it. Ok, that makes sense so far.... but wait, we want to be able to maintain state, so lets introduce this new concept called "cookies" and we'll use ASCII strings to identify things. And, it would be nice to be able to make multiple requests per TCP session, so let's put together some keep-alive mechanism. Ohh, and I want to be able to talk to multiple servers on a given IP, so let's add a host header field.... But wait, all of this is transmitted in clear text! Let's engineer a set of encyrption protocols to stick between our HTTP layer and our TCP layer. Here we'll solve some of the same engineering problems, like adding an SSL session ID to maintain state. Now, instead of requesting simple documents, how about we design an extensible markup spec to request "web services?" Yeah, that should work.

It is a testament to the design of the protocol that it's still ticking with all these enhancements (aka hacks.) But, all the layers add bits of overhead that could likely be engineered out if one had the luxury of starting from scratch.

Stateful vs. stateless

[Salamander]

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.

What nonsense

[rseuhs]

Next, let's discuss Microsoft realizing that .NET is a "stupid idea." Microsoft doesn't care about setting up a scapegoat because they're 100% sure it will work, and they're probably right. The whole company has been restructured to work with .NET and it is not going away. Latest copy of Windows in development is Windows.NET, latest set of development tools is Visual Studio.NET, latest certification is MCSD.NET. Getting a trend here yet?

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:

.NET is essentially just the next incompatible-to-everything-but-itself Win32API with some Java-ideas and pseudo-language-independence thrown in.

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.

.NET is nothing new, it's just the next API Microsoft *HAS* to push, otherwise nobody upgrades. And it could be Microsoft's biggest mistake if it runs on Linux.

Protocols never die

[metoc]

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.

Re:Yeah, but

[saintlupus]

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