Is there a real server push over http?

Question

I know there are ways to fake it, polling (or long polling) but is there any way to have the server contact the browser to push out information?

Either polling option wastes resources on the server and depending on the server can lock it up (apache and iis for example).

Seems like a lot of sites are using long polling to fake a server-side push mechanism over http. Wouldn't it just be better to have a true push protocol built into a browser?

What options are there that are server friendly to push (fake or otherwise) information to web browsers?

Sweetheart

Answer 1

I know there are ways to fake it, polling (or long polling) but is there any way to have the server contact the browser to push out information?

The connection must be first established by the client to the server. There's no way of a server contacting a web client.

Either polling option wastes resources on the server and depending on the server can lock it up (apache and iis for example).

That's correct. Frequent polling is inefficient which is one of the reasons we are moving to a push world with persistent connections. WebSockets will be the best solution for this. I work for Pusher, a hosted realtime WebSocket solution, and we've seen a massive uptake in this technology driven by a community that believe it's the best solution to the resource and realtime communication problem.

Seems like a lot of sites are using long polling to fake a server-side push mechanism over http. Wouldn't it just be better to have a true push protocol built into a browser?

Yes, that's why we now have WebSockets. HTTP solutions to web browsers are ultimately a hack and don't work consistently (in the same way) between browsers.

What options are there that are server friendly to push (fake or otherwise) information to web browsers?

• HTTP Long-Polling: The connection is held open until the server has new information. Note: this is different to standard polling where requests for new information can be a complete wast of time.
• HTTP Streaming: This is probably the solution you are looking for (answering the HTTP question). Using this technique the connection is held open and new pieces of information can be pushed over that existing connection, from server to client, without the connection being closed and re-opened as it is with HTTP Long-Polling.
• HTTP/2 Server Push: Another standardised mechanism for pushing from server to client. These are known as "pushed responses" and the browser may cache these.
• WebSockets: Full bi-directional and full duplex communication over a single TCP connection within a web browser (or any web client).

Related information and resources:

1. You can think Server-Sent Events (the EventSource API) as a standardisation of of HTTP Long-Polling and HTTP-Streaming.
2. HTTP/2 Server Push

Shiah

Answer 2

Um, no.

Your browser doesn't listen for incoming connections.

Nor would you want it to be able to. We have enough exploits as it is.

Tokay

What about RIAs? (i.e. true RIAs like Flex, Silverlight, JavaFx--not huge browser JavaScript libs mimicking RIA behavior) – Pepita

What about them? Even if they could bind to an IP:port and accept socket connections (which AFAIK, they can't), nothing from the outside could get to them (provided the user isn't doing something silly like not using a firewall). Trying to support such nonsense would be a nightmare a company/project silly enough to do it. – Tokay

It's been a while since I've looked into this and honestly I forget some of the details, but I'm pretty sure they keep an open connection for the server to push messages to the client. They can't accept additional connections (socket listen) like a server of course (unless running in AIR in Flex's case), but that's something different. – Pepita

"LCDS brings true push messaging to the table because it uses Adobe's proprietary Real Time Messaging Protocol (RTMP) to create a constant connection between itself and the client..." (LCDS is only one way, there's also GraniteDS w/Flex, Red5, and BlazeDS supports a form of push) – Pepita

Yes, and you've been able to do the same basic thing in Java with applets since 1996. There's no real magic there, and they certainly aren't built into the browser. Using javascript and a long poll (comet) is pretty much the defacto standard for doing this sort of thing, and it just plain works - no plugin or bloated adobe-ware required. The fact that you have to reconnect every once in a while really isn't that big of deal. – Tokay

And to be clear - THe OP's question was about the server contacting the browser so as not to "waste resources" (he also talks about long polling crashing web servers ... so your mileage may vary of course ... ) – Tokay

Bloated? Bias aside (which you're making clear at this point), the question is about a "real" push. AJAX stuff doesn't always "just work", is much slower, and cannot do a "real" push. A true RIA client does have this capability. Downplaying technological facts does nobody any good. Also I forgot to mention WebORB supports RTMP with Flex. (A "real" server push.) – Pepita

The OP uses the term "contact the browser", but seriously, he simply means "send data to the browser". Nothing to do with opening connections by having the browser (or an RIA running in the browser) listen for new connections. The spirit of the question is addressed via "true" RIA technology. – Pepita

@Crusader, given his push-back on the answers, I'm not actually sure *what the OP means. There's an odd fixation on the term "real" which is starting to make the whole subject meaningless, but I agree with you that Brian's position feels somewhat fanboyish, and I'm not clear on what the overal reluctance on the part of the JS community has been to add a true socket to the mix. – Wrap

"Real" is certainly fuzzy. I'm defining it as "client does not poll the server checking for updates", and Flash does have a better or "more real" way of doing this. I'm just tired of the anti-plugin crowd's irrational Apple-fed FUD and propaganda denigrating arguably better (than browser) technology (i.e. software platform virtualization: Flash, Silverlight, Java). I don't understand the hostility to browser plugins. Instead of trying to standardize standards that never reach the actual goal of standardization, perhaps browser plugin "platform delivery" should be standardized and improved? – Pepita

@Crudaser - the only "fanboy" here would be you. I'm not a web developer. I'm what's called an end user when it comes to the web, and am equally hostile to any number of bloated technologies deployed as plugins, Java included. My hopes (again, as an end user) is that HTML5 and further javascript advancements make these proprietary "rich" technologies go the way of the dodo. Oh and by the way - SO has a system in place to detect serial downvoting. – Tokay

Answer 3

If you're using RIA technology like Adobe Flex, I believe the Flex version of a "server push" (AMF messaging) would meet your definition of a server push.

Of course you can also do the primitive ajax-y (hacky) polling method too, but there's no reason unless you're forced to.

Pepita

Answer 4

You don't need to "fake" anything. Flash has a really nice and well fleshed out Socket object that works brilliantly, and you can write a tiny little Flash app that talks out to the web page, so you don't have to do anything in Flash other than the communication with the server (if you would prefer to build the page in HTML). You'll need a server side socket listener, of course, but those are pretty easy to throw together as well. Lots of documentation on-line for how to implement the whole thing.... Here's the first example I found (didn't look it over too closely, but looks like it would work nicely). http://www.giantflyingsaucer.com/blog/?p=205

Wrap

I don't see that this solves the problem: the Flash app is client-side and connects to the server, not vice versa. What the question is after is a way for the server to contact the client. – Collarbone

Well... the client in absolutely every situation has to contact the server first. But after it connects it stays connected (as long as the user is on the page) and continues to receive communication from the server. What situation are you trying to solve? The user has to arrive at the web page at some point, right? That's the moment where the client connects. And until they leave, the socket stays opened (unless something goes wrong). How are you envisioning this? (meaning... what were you hoping for?) – Wrap

You have been able to do the same thing with a Java applet since about 1996. It's still not "push" any more than a long poll (comet) is; the only difference is that a long poll has to reconnect every once and a while. – Tokay

@DrDredel Exactly. Flash/Flex apps, not to mention Java and probably Silverlight. I fail to see why Brian insists that since Java could do this for years, the fact that Flash can do this is not relevant. Clearly the "AJAX" anti-plugin special interest group is being well represented tonight. Fact of the matter is, regardless of who's opening the connections (Flash in this case), it's a "real" server push, and it's Flash. So Apple can take that fact and shove it. :) – Pepita

Answer 5

I would think WebSockets (see http://en.m.wikipedia.org/wiki/WebSocket) is real push, so the answer would be: it depends upon the browser. If you need wide compatibility, the best you can do today is JavaScript libraries that will choose the best available protocol for the browser it's running in (e.g. https://github.com/ffdead/jquery-graceful-websocket). But you wanted server-friendly, and supporting multiple protocols is not server friendly. The current state-of-the-art is that doing cool stuff that works across browsers is engineering-intensive.

Calcar

Websockets do not operate over HTTP though. That is one of the main advantages (no HTTP overhead) – Lemus

There is an initial HTTP handshake. Similar to HTTP Streaming actually - although in web browsers the buffer (XHR.responseText) does get very big and eventually the connection will need to be dropped and re-established. – Shiah

Answer 6

As others stated it is impossible for server to contact client without client request (on regular HTTP).

But if you looking for clean solution for push notificatinons, then look at Server-Sent Events. It is regular HTTP and works seamless with most of the browsers which support HTTP 1.1.

SSE works only in a single direction (server -> client), which is the main mechanic for push notifications. For client-> server communication you can always use Ajax. I made a summarize of this in Which technology for realtime communication for a web app?

Cotquean

Answer 7

May be technology has advanced from the time the question was asked ... I came across this one searching for something else.

WebPush is available in most of the browsers and there are several Push Notification providers that send information from the server to the browser. Other than few browsers like Safari, one can develop handlers which can be invoked when the notification arrives and perform some action on the client side browser.

Sig