Slashdot Mirror
Smarter Clients Via ReverseHTTP and WebSockets
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 is that web browsers already contain enough security holes, imagine if they contained a web server ;-)
Everything I write is lies, read between the lines.
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.
I thought dumping the load on the server was the desired design feature. What is the problem they are trying to solve? Good old rich client model has been around for some time now.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
This seems to closely relate to the next story currently on the frontpage; Predicting Malicious Web Attacks
Imagine if IE contained IIS...that would be awesome!
imagine indeed...
only in the mind of microsoft
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.
---- Booth was a patriot ----
I've been reading the blog-article and the linked websockets API description. The websockets proposal specifically states the protocol does not give access to the raw network, and does not allow an IRC client without intermediate server. So where's the whole enthusiasm coming from? Even with websockets, it doesn't look all that different from the Opera implementation.
As far as I understand websockets from the description, you still have to point the browser to the right place to connect to. Once connected, you can then accept incoming messages from the other side. Well, color me pink and tie me down, but I'm not sure the rapture has just arrived already because of someone writing up an API.
Websockets shouldn't have much of a problem with firewalls though, since you could use the existing tunnel. I wonder what this would do for security inside the company.
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 :)
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
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 firewall restrictions. I think that was a previous /. article.
It's got a lot of features many folks don't use.
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?
Less Talk, More Beer.
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 achieve PRECISELY the same goals that thick clients has been able to do for literally several decades!
The platforms and standards for making web applications are continuously MOLESTED in order to give them primitives abilities which, at the end of the day, are STILL only a shadow of the power a rich client has.
Stuff like AJAX hits the scene, and people call it a "milestone" or a "revolution". Wow. Now a user can get his screen updated async without hitting a "submit" button. Big stuff there.
Next thing will be ... what? Better graphics? Actual integration between applications? Easy third-party data integration? Ah, wait, maybe it will be an continuous (and actually working) user session? No no ... wait ... I got it ... it will be model-based programming. Yes. The revolutionary new "model-view-controller" design will totally change the landscape of web applications. It will be ground-breaking stuff to any web developer! Yeah!
The finest achievement any web application can get, is being described like it is "just as good as a rich client". Hasn't anybody stopped a moment to think about WHY that is? Perhaps it would be better just to use web clients where they make sense, and rich clients where they make sense?
Why on earth do some people continue to abuse the thin (read: skinny and bone-rattling) web standards for tasks that are clearly more suited for a traditional rich client application?
This is an honest question - technical answers are more than welcome. I genuinely want to understand what is going on in the minds of all these "progressive" web developers who are seriously proposing the introduction of advanced server-processes as part of a browser...
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
The details of getting the requests through the gateway to the serving application are pretty trivial and interchangeable. The new idea is in registering endpoint names. UPNP and STUN cover some of the same space, but IP's addressing is fundamentally different to HTTP's URL-based addressing in that it's possible with URLs to have recursive delegations of portions of the namespace -- something that IP just can't do (because it's flat).
http://www.nocrew.org/software/httptunnel.html
If you're going to build an httpd into the browser, and also the NAT people need some fixed proxy out thre somewhere, then you might as well just make it Jabber.
Is that similar to INTERCAL's COME FROM instruction?
Here is a /. story about Opera's inclusion of a web server:
http://apache.slashdot.org/story/09/06/19/0227249/Opera-Unite-Web-Server-Benchmarked
You might want to look at RESTful Web Services, too.
Can you please explain WHY you would want to molest the primitive HTTP protocol in this way? Seriously: why not use another protocol that is actually suited for the task at hand, and then let the client initiate the connection (thereby automatically solving a gazillion security issues and technical challenges imposed by NAT based consumer routers)? Why - please - WHY do you want to take "web application concepts" and transmogrify them (read: totally molest them) into something they are not... while clearly ignoring that A LOT of existing technology has already solves most of these issues? Why choose a web/HTTP implementation BEFORE analysing the task at hand instead of getting a clear picture of the task and THEN choosing an appropriate technology afterwords? - Jesper
My security clearance is so high I have to kill myself if I remember I have it...
Regardless if you are maintaining a persistent connection via a non-HTTP protocol, or setting up a dual web servers to chatter back and forth, you are still missing the point.
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 want plain HTML, use a browser. If you want a TCP/IP connection, use a HTTP connection with AJAX, Java applets, server state, cookies, keep alive headers, hidden form values and viewstate to SIMULATE ONE...
HA! I just wasted some of your bandwidth with a frivolous sig!
...it's called a "Zombie".
Table-ized A.I.
This is the same concept as BitTorrent...where you spread the load out to anyone downloading the software. BitTorrent uploads the parts you downloaded, therefore spreading the load to the clients.
1) Bittorrent is already getting a lot of black listing from major cable companies, because people are downloading DVD movies and not paying for them using pay-per-view.
2) ISPs do not allow a home user to set up a web server and will block or ban your account if it finds port 80 or http/https (amoung others as well like ftp excessively used)
3) how is your browser going to access a Database like mysql with php, local on your machine? The pages would have to be cached and static or some other wizard way of doing it.
I am by no means saying that the idea isnt possible or even not a good idea. It sounds like a nice idea... however too many factors are at play, including co-location centers and the notion of a 'server' itself being discounted in favor of a 'super browser'.
The only reason this subject has come up is to try to combat DDoS attacks. Twitter and Facebook and the whitehouse.gov attacks.
No, what needs to happen is to get rid of the Microsoft Windows ZOMBIE botnet computers, which allow the DDoS attacks to happen with greater ease and frequency.
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 like inventing a cell-phone just to call your next-door neighbor.
Table-ized A.I.
Too late.
http://labs.mozilla.com/prism/
http://www.adobe.com/products/air/
http://silverlight.net/
http://www.zimbra.com/products/desktop.html
http://desktop.google.com/plugins/
http://widgets.yahoo.com/
http://www.apple.com/downloads/dashboard/
http://www.microsoft.com/windows/windows-vista/features/sidebar-gadgets.aspx
http://www.screenlets.org/index.php/Screenshots
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.
Doesn't anyone remember FTP? And why Passive-mode FTP was developed? All of the same reasons why this isn't a good idea. Your web browser ends up behind a NAT firewall and poof, this no longer works. (Without some deep packet inspection on the firewall to automatically open the ports, or UPnP, or SOCKS, or some other protocol for the web client to negotiate with the firewall to allow the connections).
CE-HTML 3rd party notifications. It's what this is.
Many ISPs prohibit running any kind of server on a home customer connection, and they will regularly port scan you and disconnect you if they find one.
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.
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.
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.
Sorry folks, old news:
Coopnet did it years ago, and HTTP(p2p) did it differently but more recently.
http(p2p)
OK, I was with you guys when you said lets make these hyper linked documents connected around the world. I was along for the ride when you said lets post the request stream to the CGI bin and let a binary dynamically generate the HTML response. I was even with you when you said that if we move the dynamic stuff to a scripting language and mixed it up with the HTML it would be more agile, I gave you a funny look but I went along. Then you told me I needed a MVC framework to manage the complexity and to get all of that mix of content and code away from each other from that scripting idea . I thought you where a little crazy, but I agreed that we may have not went down the right path with that asp, php type stuff, so I went along. They you told me that the MVC stuff was to restrictive and strongly typed and that I should do my front end in javascript and just use the back end for services and get rid of the page post model. The last time you where so dead on with a recommendation, was back in those days when you recommended the CGI posty thingy. The Ajax UI with the service backend actually worked, even though it looked like a hack to me, never the less it was really easy to be productive again, come to think of it the CGI thing was a hack too and it really was the last time I felt productive. Anyway, I don't want to hurt your feelings or anything, but I think that this one is a little crazy and kind of defeats the whole concept of the web and if you don't mind I think I want to get off of the internet now. No offense but I really am starting to get the impression that you guys HAVE NO FUCKING CLUE.
Java plugins in the Web browser may be considered as "Vulnerable software" because it provides the "system" API among many other APIs which enables your so-called "smarter client" which people in 1994 called "fat client". We had the power to use serversockets then but we didn't. Javascript BY-DESIGN is not permitted to use the "system" api because it is part of the "thin client" design. As a result, artsy web page designers got tools that could use javascript, but not java because everyone concerned agreed it was safe-enough. That's why Java/Javascript has been mostly disabled on my browser since 1994. The combination of these two enabled is quite dangerous on a localhost.
The primary reason for http has been and always will be simply a way to link web pages to other pages. Keeping the web browser design simple allows mostly everyone a better opportunity to learn how the tools work. When everything is obfuscated, you make everything about it look like magic and exclusive to the technocrats. With SMARTER CLIENT ideas like this proposed topic, firefox and all the web browsers are all risking slowly becoming like "MS-Internet Explorer" which is plastered with undocumented vulnerabilities/opportunities open to a select illuminated few.
Popularity for software depends on its merit. Since Linux has merits, it has become popular. The different packages in linux are different in popularity because there are "different strokes for different folks". Simple to use, but sophisticated software is popular like vi, emacs, gedit, postit-notes, calendar, evince, wget, firefox, thunderbird, mplayer, ffmpeg2theora, audacity, lame, apache, shorewall, gimp and openoffice. Vulnerably complex software is not popular like MPI, PVM, Plan9, SCALA, flash-plugins. I've experimented with flash/ming and discovered first hand the flash engine can crash not only the application, but also the OS. I understand the politics of flash being used is to somehow protect the media industry because it is proprietary technology geared to provide a pay per use intenet business model for the entertainment industry. It is important to be aware that flash technology is used on most movie DVD's sold today for the menu subsystems along with helping with the obfuscation to reduce the dvd-ripping piracy. I also understand that the movie industry does everything to undermine the trend to use open-source theora format video files and ogg format audio files. Thankfully theora/ogg are the defaults in all the current Linux distributions.
You have a take a leap of faith to use a lot of these more advanced pieces of software, but if you're in a position where you need to guarantee something works and you use internet explorer with java/flash and your so-called smarter client api plugins, GOOD LUCK with that and I'll be looking for news about your company's bankruptcy notice in the following months.
Think one tool, one job. Hammer the nail. Not everything is a nail. For example you search for stuff by starting your firefox, going to google and typing the key words. You expect a response with links to other pages. That's it. There's nothing in this recipe that demands a web server in your web browser. Not everything needs to be a hammer. Not everything needs to be in the cloud either.
The one tool is firefox being the client.
The other tool is google being the web page server.
An email agent sends/receives email to the email server. That's one tool for one job.
If you want a web page server, install apache. That's the one tool for the one job.
I'm a strong believer in a clear separation of concerns because my private family pictures, although I am very proud of them are none of anyone's concern and should not ever accidently find themselves on the net. If a web browser somehow becomes a web server with your ideas, my pictures might accidently fall into unintended audiences. It's not a big deal but the fact that this accident could happen because of a software vulnerability really would piss me off. I
For many modern companies, how they do what they do is their added value.
From a commercial perspective, one of the beauties of having your software on your own server (HTTP or otherwise) as opposed to distributing an executable application is that the distributed exe is much easier to reverse engineer than when it is on a black box many routers and a few firewalls away from the hopeful reversing engineer.
Make sure you're not delivering business logic/intellectual property/key processes to all of their web clients. /gg
What a fundamental lack of understaning you convey concerning programming in the real world. You can use many many different variations of interprocess communication and have as many various daemons that you would like on both sides of an internet session. You merely need to get your users to agree to run the various daemons. These daemons would open sockets with daemons on a server, and you would have your smart client side thing going on. But really, given your fundamental misunderstanding about networking, and that HTTP is but one of many possible protocols, you run a company?
Really? You are running a development effort? Seriously, dude, you are not qualified. You need to go back to clown college. Must be nice to be a member of the Builder-bergs.
I herd you like to browse the web so we put a web server and a proxy in your web browser so you can serve web pages while you browse!
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 ...
Please correct me if I got my facts wrong.
Remember the old days, when the browser was superior because it was a thin client? Maybe we need a term for the thickening of clients... Americanisation?
You can try a web server for your phone: http://www.mymobilesite.net/.
Some application will always rely on local computing power: something like GIMP, or even using PHP scripts in XAMPP on local machine for, say producing miniatures of larger photos.
But distributed business network application can realistically exist only via server-client model.
If they want rely on an installed software on client's side - let them try it. I've been there. It is insane. PCs get broken, installed EXE stop working for unexplainable reasons, and so on and so forth. All I had to do is: install and re-install, endlessly. Sometimes somebody got a good idea and they moved to thin clients at that office. I had to install EXE for 4 hours on the thin client! Searching missing DLLs all over Internet.
Now we moved to server-SSL-client model. I do not care what is going on locally. Here is your login and password and it's you life.
Besides even in the server-client model a lot of things are done on local PC: rendering pages, handling javascript.
Really. You can't be serious.
And the fact that you have chosen to post as "Anonymous Coward" but at the same time show the signs of a regular ./ reader which probably has a user account, says even more than your post.
More than 3/4 of the things end-users love about computers are from rich client experiences. I very much doubt that will change. Browser are playing a catchup-game in order to approximate the most primitive things that rich clients are already capable of. And at the same time (thankfully) man-machine interfaces are evolving into new and great areas which will never fit into a browser.
If you think browser will ever get on level with the rich client you would also have to assume that the rich clients stop at their current level of evolution. And I just don't see that hapening. :-)
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
works magnificently for politicians and bankers. Also if the client contained both a browser and a web server, wouldn't that be like playing with yourself ? Of course it would facilitate working offline.
The key word here is: decentralization. Get a fresh webapp from a website (say, an instant messenger), and then connect user-to-user, and avoid the middle man. Faster, more secure, more private.
I understand this seems an over-feature for web browsers at this point. But unless there is an objective reason why this should be deprecated, the fact that we're used to browsers the way they are now, doesn't mean that is better for software.
Granted, for most things long polling is sufficient, but for decentralization, a web server is a must. Rationalize to see if fear of the unknown is useful in this case. Try weighing 'security' and privacy, and established standards against the opportunities.
--paxcoder