Smarter Clients Via ReverseHTTP and WebSockets 235
igrigorik writes "Most web applications are built with the assumption that the client / browser is 'dumb,' which places all the scalability requirements and load on the server. We've built a number of crutches in the form of Cache headers, ETags, and accelerators, but none has fundamentally solved the problem. As a thought experiment: what if the browser also contained a Web server? A look at some of the emerging trends and solutions: HTML 5 WebSocket API and ReverseHTTP."
A problem that I can see. (Score:5, Insightful)
A problem that I can see is that web browsers already contain enough security holes, imagine if they contained a web server ;-)
Re: (Score:2)
Re: (Score:3, Interesting)
Are you trusting the site you connect to. That is the Active X mentality. If you went to the site then it is OK.
Re: (Score:2)
Re: (Score:2)
So lets have it create a 120gig file called "-rf /" And lets see how many amateur Linux users will whip out their drives.
Re: (Score:2, Insightful)
And pray tell me how exactly you're going to encode a "/" [wikipedia.org] in the file name?
Re: (Score:2)
How is it a server if it is the one requesting a connection? This is semantic abuse! I'm calling the definition police.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
A problem that I can't see. (Score:2)
Why is this any different from the classic thing?
All it does is enables the "server" to send data even if the "client" doesn't request them each time (doesn't refresh). Instead of trusting AJAX code gotten from the server and "refreshing" parts of pages in set intervals, why not just trust the socket which will provide the info necessary for the "refresh"? I don't see any new problem introduced here.
Please explain if you do.
Re: (Score:2)
> Please explain if you do.
Keeping the connection alive (keep alive) enables you to do just that without running a server (e.g. listening socket) in your web browser. Yet, people do not use it much. Allowing the server to connect back to you is even more complex and I do not think it would fly that much, you would now need more complex server applications. Paying the almost costless price to establish a new connection every time is the privileged option nowadays and most applications are built with that
Re: (Score:2)
Connection, yes. Server, no. (Score:5, Insightful)
There's nothing wrong with a browser establishing a persistent connection to a server which uses a non-HTTP protocol. Java applets have been doing that for a decade. That's how most chat clients work. Many corporate client/server apps work that way. In fact, what the article is really talking about is going back to "client-server computing", with Javascript applications in the browser being the client-side application instead of Java applets (2000) or Windows applications (1995).
But accepting incoming HTTP connections in the browser is just asking for trouble. There will be exploits that don't require any user action. Not a good thing. Every time someone puts something in Windows clients that accepts outside connections, there's soon an exploit for it.
Re:Connection, yes. Server, no. (Score:4, Interesting)
Re: (Score:3, Informative)
Any kind of 'fundamental change' that happens on the Internet needs to accept that NATs part of good architecture. You really want your toaster on the same address space as your Cray?
Re: (Score:2)
No, they're really not. They don't add any security except a tiny bit of obscurity.
Re: (Score:2)
Re: (Score:2)
Good point, security through obscurity. Place a Linux (or any) gateway machine behind a rather cheap router, with default paranoia settings. Someone wants to run some services from the LAN to the intartubez, but he's not discoverable. Since the cheap router is very limited in it's configuration, one might spend days trying to get everything to their liking.
Alternatively, one can do wan --disable firewall then configure everything on the Linux gateway machine. Firestarter does exactly what we ask it to d
Re:Connection, yes. Server, no. (Score:5, Insightful)
NAT is a bona fide security feature, not just a consequence of having a LAN.
What security does it provide that a REJECT ALL firewall rule wouldn't?
Re:Connection, yes. Server, no. (Score:4, Insightful)
> What security does it provide that a REJECT ALL firewall rule wouldn't?
The security that most users don't have any idea about how to configure a REJECT rule, even if they have a firewall at all.
Re: (Score:2)
Consistent and Manditory Ruleset. (Score:5, Insightful)
I actually do think that NATs have been a boon to end-user security, more so than firewalls would have been, because they created a (relatively) consistent ruleset that software developers were then forced to accommodate. Hear me out.
Imagine an alternate universe where IP6 was rolled out before before broadband, and there was never any technical need for NAT. In that case the consumer routers would have all come with firewalls rather than NAT. First off it is very possible that router manufacturers would have shipped these with the firewall off to avoid confusion and misplaced blame: "I can't connect to the internet, this thing must be broken". If they were enabled by default, with common ports opened up, there would still be applications (server and P2P) that would need to have incoming ports manually configured to be open in order to work. Most users wouldn't be able to figure this out, and the common advice between users would become "If it doesn't work disable the firewall".
And the fact of the matter is that requiring a novice user to configure his router just to use an application is not a good approach. There needs to be some sane form of auto-configuration. Even if the firewall tried to implement this internally, you would run into problems with different "smart firewalls" behaving differently, which would create even more headache for application developers.
With NAT you have the same problem in that manually configuring port forwarding is confusing to users. The difference is that there is no option to disable NAT. So it became the application developers' problem by necessity, and this is a good thing, because they are better suited to handle technical problems than the end user is. It was a major pain in the ass, but eventually all the router manufactures all settled on similar heuristics on how to fill the NAT table based on previous traffic, and we learned strategies to initiate P2P traffic that didn't require user intervention.
In end, default behavior of NAT (outgoing traffic always allowed, incoming only in response to outgoing) gave us the auto-configuration ability that we needed, and the result was something much more secure than would have existed if the firewall was optional.
Re: (Score:3, Insightful)
> outgoing traffic always allowed, incoming only in response to outgoing
thus began the end of the world wide web. in it's place we have the next gen *cable* with producers and consumers. no wonder comcast is looking to buy disney or other "content producers".
just what is so horrid about having my computer serve content by allowing connections to it? someday we will be so damn secure that no one will be able to talk to anyone else.
Re: (Score:3, Insightful)
YOU can, because you know what NAT is and how to port-forward and various other things.
Most people don't. Leave them in their little walled gardens, it's safer for them there.
Re: (Score:2)
Nothing whatsoever, if that's what you choose. But 99% of users don't want to do that, and don't know how to configure things to allow it safely. In your case you can get a static IP or three, or even with NAT it's easy to setup port forwarding. I really don't see the loss unless you want every machine on your network to be a port 80 web server and don't want to pay for the static IPs, which is a pretty marginal case.
Re: (Score:2)
Exactly. The only thing NAT gives you that a default policy of REJECT or DROP doesn't is extra latency and higher CPU load on the firewall.
NAT also makes it harder to figure out who the badguy is if one of the internal machines attacks a remote machine (for example, because it got a virus or some employee is running something they shouldn't be).
Re: (Score:2)
Re: (Score:2)
NAT provides exactly the same security as a connection-tracking firewall -- there is no further benefit to address translation over a dynamic firewall with the same rules. Dropping the NAT part makes it about 11,000 times easier to run services on the inside, particularly if they use multiple connections (e.g. FTP, SIP) in the course of a session, and it removes the "only 1 person can run a service on the default port" limitation introduced when you put more than one system behind a single address.
Re: (Score:2)
Re: (Score:3, Interesting)
> But accepting incoming HTTP connections in the browser is just asking for trouble.
Exactly, transparent caching proxies would seem to solve issue in a simpler and easier to manage way. Then again, providers trying to implement caching proxies that I know of have all abandoned the idea after trying it. Their customers complained to much and it brings all sort of problems with the transactional behavior of an application.
So people do not like caching proxies, why would they like one in their browser ? Wh
Re: (Score:2)
How would this peer2peer like static content propagation be really useful in a modern web application ? It is not worth the security implications (basically the same as running any p2p client)
Most web applications have dynamic content nowadays you know.
Would you rather to get stale Slashdot articles from the browser running in your neighbor's computer or to get them fresh from Slashdot ?
Again, nothing here that caching proxies don't already do, and people do not like caching proxies as I explained above in
Re: (Score:2)
I understand your point, you are basically saying that we should incorporated fancy p2p capabilities into web browsers ;-)
My point is that it is a bad idea security wise. I use p2p clients/servers to do p2p ( Note: p2p clients are also servers). I admire p2p algorithms just as much as you might do but let's use right tools for the right job.
A lot of people, especially big corporations, won't like the idea of having their employees running p2p clients/servers incorporated in their web browsers either ;-)
Peop
TCP, by any other name, would thou smell as sweet? (Score:2)
This is yet another stupid patch for the fundamental design flaw of HTTP: I was never supposed to used to mimic a persistent connection. Why keep running through ever more complicated mazes, and just build a freakin browser that maintains a connection with the host? (rhetoric, I'm not really asking this as a question...)
if you wa
Re: (Score:2)
It's also a stupid, stupid idea. On top of the security concerns, it's a waste of resources, both along the network route, and at the endpoints (mmmm... even more sockets for the web server OS to keep track of). And it's a huge hassle for firewalls.
Honestly, I've been a defender of the whole thick-ish-web-client revolution, but this is just getting ridiculous. HTTP is a request-response protocol. If you need something interactive, use a frickin' interactive protocol. Why the hell would you shoehorn it
Re: (Score:2)
Well, I already did persistent JavaScript-only connections in 2003-2005. I used an object tag, and then requested a page. that page did never end, and continued to include new JSON snippets which immediately executed. When it got too big, the response ended with a location.refresh().
A second object tag included a form with a "never ending" POST.
But it did not work so great, so I changed it to single "packets" (form submissions and receivings). Which also allowed them to be done in a single object tag.
Then I
Problem? (Score:5, Insightful)
Re:Problem? (Score:5, Funny)
Ah, but the young 'uns have forgotten that anybody did anything before they came along. So "the network" is synonymous with "the web" and if you want to send any information it better be over HTTP. So bidirectional HTTP means you can communicate in both directions!
Next they're going to figure out that if you move the web app out of the browser you can have a much richer GUI experience.
Re: (Score:2)
This wouldn't be so funny if it weren't so true :D
At least I no longer have to use a teletype for my batch output...
Re: (Score:2)
You know, I've heard this cool idea being kicked around of using a printer to automatically produce a hard copy of the console output. Sort of like a log, but on paper. It seems it might just be the next big thing!
Re: (Score:2)
That would be especially useful whenever the system has a problem - then you would be able to read back the whole issue, and it wouldn't get deleted on reboot!
Re: (Score:2)
Re: (Score:2, Funny)
Yes, but they were disguised as mere keyboards [wikimedia.org] to fool you toddlers.
Re: (Score:2)
Wait, there were computers before the Internet??!1
Re: (Score:3, Informative)
I've seen good developers try to use UDP instead of TCP to save a few bytes of overhead, and they failed. How will web developers without any concept of network p
Re: (Score:3, Insightful)
I once had a PhD supervisor who had a problem. He was setting up a database for this group who needed to be able to enter a few very simple bits of information for a clinical trial. I told him it would be no problem - whip up a little app in Python using Wx or QT that does nothing but display a few fields and create a new row in the database when you hit submit. Maybe do a little bit of checking and pop up a dialog box if it was a duplicate.
But no... it had to be a web app. So after hiring a database gu
Re: (Score:3, Informative)
That just shows he doesn't know what he's doing. The exact same little python script could have generated a simple web form and submitted to the DB.
Re: (Score:2)
That still means writing a script, setting up a database AND setting up (and maintaining) a web server with the extras to both run Python and talk to the database. Just so you can type a URL into your web browser instead of double clicking on an icon.
move the web app out of the browser (Score:2)
Too late.
http://labs.mozilla.com/prism/ [mozilla.com]
http://www.adobe.com/products/air/ [adobe.com]
http://silverlight.net/ [silverlight.net]
http://www.zimbra.com/products/desktop.html [zimbra.com]
http://desktop.google.com/plugins/ [google.com]
http://widgets.yahoo.com/ [yahoo.com]
http://www.apple.com/downloads/dashboard/ [apple.com]
http://www.microsoft.com/windows/windows-vista/features/sidebar-gadgets.aspx [microsoft.com]
http://www.screenlets.org/index.php/Screenshots [screenlets.org]
Re: (Score:2)
Next they're going to figure out that if you move the web app out of the browser you can have a much richer GUI experience.
Either that, or they move the browser into the webapp... (Seriously, I give it a year until someone writes a full-size GUI toolkit using the HTML canvas as a display device, and the GUI toolkit comes with an HTML rendering engine)
Is this a follow-up to the previous story? (Score:4, Funny)
Going backwards (Score:2)
The whole point of 'the web' was to move processing out to the 'cloud' ( sorry for the buzzword use ). Ideas like this only would continue the backwards trend of moving the processing back onto the client, which personally i feel is the wrong direction.
Re: (Score:3, Insightful)
Re: (Score:2)
I mostly agree, however I believe much of the initial push to move processing out to the 'cloud' was because clients likely had limited hardware. Now days client hardware is rather beefy and could handle some more of the load that the server doesn't need. That said, I think a web browser that opens ports and is listening for connections on my computer would make me more than slightly wary.
I disagree. The re-centralization of computing did not happen because of a lack of client horsepower. If anything, the aggregate client power to server power ratio has skyrocketed, and never stopped since decentralizing in the first place. I really do not understand the intent of the last decade or so of re-centralization. It makes zero sense to me. The only reason I have come up with is the browser is a mostly cross platform platform. Still, the number of webapps that run on a single browser on a sin
Re:Going backwards (Score:4, Insightful)
The point of the web was not to move processing out to the cloud, it was to build a multi-way communications medium (hence web) that anyone on the Internet could participate in. Moving processing to "the cloud" (i.e., someone else's computer) is the point of Google, not the web.
Re: (Score:3, Insightful)
Exactly. The original web was supposed to be read-write. A combination of companies that wanted to ream people for $50/month for hosting a simple hobby site and ISPs that wanted to upsell you a $100/month "business internet packa
Re: (Score:2)
By linking the processing power, and accessing it via terminals, as it was in the beginning, id say i'm correct in its intent.
Re: (Score:2)
Re: (Score:2)
Disagree all you want, but you are wrong :) Terminals for everyone.
I thought this was called Flash? (Score:2)
Flash 10 has the ability to do advanced client side things. For example, it can update the screen with information from a server by posting to a website, by XML, etc. It's pretty good at doing this. 8e6 and Surfcontrol utilize this type of capability in their admin GUIs for example.
Beyond just nice GUIs, one can serve up a special Flash document on a website. When the user opens the web page, a reverse proxy tunnel can be established allowing access into the clients LAN through Flash, bypassing any fire
Re: (Score:2)
It's also a proprietary, binary blob and an insanely buggy one at that. At least all versions that are currently usable in practice (Gnash/swfdec are only usable in theory).
Re: (Score:2)
HTTP isn't dumb, it's just minunderstood. (Score:5, Insightful)
So really....
HTTP isn't dumb, it's (mostly) Stateless. Instead of that, what about building net applications around stateful protocols instead of some stupid hack and likely security nightmare?
Re:HTTP isn't dumb, it's just minunderstood. (Score:4, Insightful)
Re: (Score:2)
Here's the thing: stateless works everywhere there is any internet connectivity. Imagine having to define a long-lasting stateful protocol around slow and unreliable internet connections.
That's exactly what TCP was designed for: persistent 2-way connections over possibly unreliable networks. But I agree with your basic point, given that firewalls may be configured to only allow HTTP and other basic protocols through.
Re: (Score:2)
I've wondered recently how come we can't get a protocol like HTTP, but 1) not based on 'pages' but arbitrarily small/large and recursively nestable chunks of data, and 2) not pull and client-driven but publish/subscribe and persistent, where you'd attach to a data chunk and then be notified with the new value whenever that chunk changes. The rise of social services like Twitter and Facebook (and particularly the use of both by applications as a sort of generic publish-subscribe information bus) seems to be
Re: (Score:2)
Actually, you're mostly describing XMPP, which Google Wave is built upon. It's already there and it's in active use, although mostly for IM for now.
Re: (Score:2)
HTTP isn't built around pages. HTTP can already do that.
That's a pretty simple application of any asynchronous messaging protocol (most such protocols aren't built around that pa
The web-application-forever-trend? (Score:2, Interesting)
May I politely ask WHY anyone would one to continue making browsers "heavier" and "thicker" all the time, instead of simply making a good old fashioned rich client (thick client if you prefer)???
I am not looking to start a "Wep-app-vs-client-app" war here. I think there is a time and place for both thick client applications and web applications. And I am a very happy G-Mail user (among other web-app-things). But sometimes I am REALLY amazed when I see the lengths some web-developers will go to, in order to
Re:The web-application-forever-trend? (Score:4, Insightful)
With thin clients, people already have a (somewhat) standardized client. You don't have to worry about deployment issues, software updates, system compatibility issues, etc. It's there and it mostly works. If you can develop your application within the constrains of a thin client, you have already bypassed a huge pile of potential headaches. Even more, your users won't have to go through the trouble of installing yet another piece of software, just to try your app.
Re: (Score:2)
I totally disagree. Respectfully :-)
Your view is typical of a techie or CTO responsible for a software roll-out. The basic thought seems to be avoiding rich clients at all costs in order to make the whole thing "simpler".
But there are a ton of disadvantages for web clients. And in many (bot not all) cases they outweigh the advantages!
- They require MUCH more advanced back-end infrastructure to work, often including several servers and lots of monitoring/management
- much more complicated maintenance and upgr
Re: (Score:2)
Don't get me wrong, I agree with many of the points you're making. As a matter of fact, I am currently involved in the development of a rich client/server architecture.
However, I still maintain that the costs of dealing with server side deployment/scalability/upgrade issues is lower than dealing with rich clients in many instances.
I admit that my stance is biased by the fact that we use only basic open source building blocks for our deployments and we code the rest in house. We don't have to deal with vario
Re: (Score:2)
LOL.
Mjeah. Right. :-D
6 months later all the end-users are still happy with the application which provides them with the exact same and rich user experience as their favourite (rich) office application. Right? And they just LOVE the idea of paying monthly fees in order to use their software. Sure. And have no problems with the fact that their data are crossing the internet every time they access it. While not minding at all that the whole solution is nearly impossible to integrate with anything else. Poor p
Re: (Score:2)
With a given OS and an app, people already have a (somewhat) standardized client. You don't have to worry about compatibility issues, browser differences, etc. It's there and it mostly works. If you can develop your application within the constraints of an OS, you have already bypassed a huge pile of potential headache. Even more, your users won't have to go through the trouble of downloading the right browser, installing it, starting it, and navigating to your site, just to try your app. Also, you won
Re: (Score:2)
If you are a web developer, you pretty much have the choice of switching careers or doing your best to bludgeon as much functionality out of your toolset as possible.
More generally, though, "web" apps do have advantages, they are just almost universally in areas outside of their power as programs(and, to be fair, areas where conventional client apps could be made to match, if a whole lot of groundwork were done).
Assuming you haven't already, looking at some user's h
FAT CLIENT is NOT the right FIX (Score:3, Interesting)
What's needed is a "GUI Browser" standard that is meant for C.R.U.D. screens (business screens and forms) instead of what HMTL is: An e-brochure format bent like hell to fit everything else. You can only bend the e-brochure model so far. We don't need "fat clients" really to solve most of the problem, but really just a better GUI browser so that we are not sending over 100,000 lines of version-sensitive JavaScript just to emulate (poorly) a combo-box, data grid, or folder/file outline tree widget. That's li
Re: (Score:2)
So why not make a client/server solution, and make good clients for each of the platforms you want to support?
Compared to the absolutely massive resources needed to build an advanced web application with roughly the same capabilities as rich clients on those same OS'es it should not be too hard to do!
Why do we need a "GUI browser"? How would you describe such a thing anyway? The presentation layer of any modern OS already has all the things we need PLUS a ton of very useful local integration with with other
Re: (Score:2)
Because people don't want the "install" step, for both time and security reasons.
Kind of like HTML, but with more widgets, more declarative "events" for common actions, standard ess-expression-based field validation, an MDI option, and a "stay until removed" aspect of drawing screens instead of redraw-page-per-post of regular HTML.
So does the Tk-kit-family and Java for the most pa
Re: (Score:2)
I am sorry but I still don't understand the concept of this "GUI browser". It sounds like you are focusing a lot on the presentation layer and ignoring all the other aspects a rich client has.
What about 3rd party integration? Or a visual layout which matches the operating system? Or hotkeys and interactive behavior matching the OS? Or the ton of rich functionality provided by the OS to all local applications (security features, networking, local system access, core functionality like cross-application objec
Re: (Score:2)
"So does the Tk-kit-family and Java for the most part. A "generic" GUI-browser could probably be built with them."
Yes, you've described a Java applet.
Re: (Score:2)
Actually, I think he's describing MS Access. Including the "generic" part.
Re: (Score:2)
Congratulations.
Re: (Score:2)
"That sounds a lot like XUL which Firefox has supported for a while and nobody uses (except for Firefox extensions)."
Obviously not. XUL was a very founded idea: that both developers and users want a standard deployment platform. Whenever a 'de facto' standard rises, you get to see its success aggregating developer efforts being it Windows at the OS level, Access at the DB frontend, "the browser" at the Internet level, etc.
Users like it because they find it an easy concept to grasp; developers like it beca
Re: (Score:2)
True and false.
It is a success for the things it was originally created to solve.
It is a failure (although very widespread) for the more modern things it is used for in advanced web applications... ;-)
Re: (Score:2)
3 words: Java Web Start.
Re: (Score:2)
"NOBODY BUT COMPUTER TECHIES KNOW WHAT A CLIENT IS, NEVERMIND A RICH ONE."
Still they use them everyday, which is what counts.
"Sorry to be a bit of a dick about it, but if you couldn't see such a simple reason, then god help you."
Don't be so sorry. You are a dick because you are a dick -with an absolute lack of imagination on top of that. That you are able to regurgitate the last info you got from a "tech blog" makes you an informed dick, not an knowledgeable expert.
FTP anyone (Score:2)
Instant SETI (Score:2)
Could be neat. Just browser to the SETI site. click on volunteer some cycles and right away your browser (and computer) are peers working away on the problem. Nothing to install. When you are done, just navigate away.
Why HTTP? (Score:3, Insightful)
If you want a browser to be able to send and receive asynchronous messages, rather than work on a request/response model, why not just build browsers that use a protocol designed for that use (like XMPP), rather than trying to torture HTTP into serving in that role? Its not like HTML, XML, JSON, or anything other data the browser might need to handle cares what protocol its transported over.
Re: (Score:3, Informative)
Scenario: I'm pointing my browser at a server I run at home. In my browser I run a small webserver that can access a commandshell. Cool, now I can work from home despite a firewall and lack of software :) Sorry dear sysadmin, your firewall just got a few new holes in it :)
I used to do that on my University's network with a reverse SSH tunnel. You could even do it over port 80 if they blocked outgoing 22. The only issue would be if you could install that webserver on a locked-down machine that has no SSH client.
Re: (Score:2)
Please explain ... (Score:2)
Re: (Score:2)
I think I understand it. I will admit that I am not a network expert, just plain and simple business app developer.
And I still don't understand why I would want my own machine to answer HTTP calls of any form, or why I should allow my (hardware) firewall to allow incoming requests of that nature. The security implication alone is a nightmare.
I would never want to give any outside party the ability to execute "remote CGI" on my machine(s) nor would I want them to have the properties of a webserver.
Can you ex
Re: (Score:2)
It sounds like a kick-ass method for making stuff than can bypass police-state/dictator censor crap and web filtering. Absolutely!
I still don't see any use that would be beneficial for normal users like myself, my girlfriend, daughter, mom, dad, ... etc. :-)
Re: (Score:2)
TOnce that's done suddenly asynchronous notification of events is within reach of any program [...], and protocols and services layered on top of HTTP no longer have to contort themselves to deal with the asymmetry of HTTP. They can assume that all the world's a server, and simply push and pull content to and from whereever they please."
I'm missing the part where this is a good idea. I want to trust unknown server(s) that I happen to visit to do more than provide HTML for consumption? Why on earth would I want to expose myself that way?
If you want true interactivity, code a "thick client" designed to work with the servers or services in question. Don't try to shoehorn it a web browser using HTTP transactions- and creating a whole new platform for security risks.
Re: (Score:2)
Thanks, but I'd rather slit my wrists. Why not learn Java and build a real application, where you don't have to deal with the browser at all?
Re: (Score:2)
Your ISPs may not allow home users to do this, mine allows web servers, mail servers, the whole shooting match on their home accounts. They'll even allocate you a block of 8 static IPs to do it properly.
Re: (Score:3, Interesting)
Does this mean we're finally getting proper sockets, instead of having to do everything through HTTP requests? I've been advocating this for years ...
Yes. And no. The HTML5 spec includes a sockets-like API. However, it's intentionally crippled so that you can't use it to communicate with an application that hasn't been specifically enabled to communicate with it (i.e. it uses its own handshake protocol to ensure it's talking to a system that's designed to talk to it).