Slashdot Mirror

← Back to Stories (view on slashdot.org)

HTTP's Days Numbered

Posted by ryuzaki0 on from the big-number-or-small-number-is-the-question dept.

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

7 of 505 comments (clear)

  1. What the title _should_ read: by PureFiction · · Score: 5, Insightful

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

  2. NAT & Firewalls by mikeee · · Score: 5, Insightful

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

    1. Re:NAT & Firewalls by mikeee · · Score: 5, Insightful

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

    2. Re:NAT & Firewalls by GSloop · · Score: 5, Insightful

      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!

  3. not so sure about that... by Narcocide · · Score: 5, Insightful

    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.

  4. Stateful vs. stateless by Salamander · · Score: 5, Insightful

    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.
  5. What nonsense by rseuhs · · Score: 5, Insightful
    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.