Trigger Events On A Web Page From A Server

[Guest Recursive]

Hi, I was wondering if it is possible to have a server trigger JavaScript events on a web page in some way. I know that JavaScript can get information from the server using e.g. XMLHttpRequest like in AJAX, so I could do a setup where the script checks a file on the server at routine intervals (like every second), and the server updates this file in order to tell the script when to do certain events, but it seems like it would be very inefficient. It would be nice if there were a way where the script could passively wait for the server to trigger the event.

[Synook]

No, HTTP is a stateless pull-only protocol. Polling the server is the only option.

[Citydev]

You don't have to poll frequently. You can let the browser initiate the dialogue but make the server dictate when messages or sent. The browser issues a request but then waits until the server is ready to send anything. After it has sent something the browser makes another request and then waits again, and so on.See Reverse Ajax eg here

[Synook]

That's interesting - I wonder how they stop the connection just timing out... [bookmarks]

[boen_robot]

That's interesting - I wonder how they stop the connection just timing out... [bookmarks]

They are perhaps sending in some dummy headers... and they are perhaps using headers for the data itself too... since there is no Content-Length header, and no body, the client just keeps reading in new headers, and before it times out, it receives a new dummy header to keep it occupied.

[justsomeguy]

The browser issues a request but then waits until the server is ready to send anything. After it has sent something the browser makes another request and then waits again, and so on.

That sounds like a terrible idea. Servers have a maximum number of connections they can have open. If your server has a limit of 200 connections and you have 200 people sitting there with an idle connection open you've effectively DoS'd the server, it's not going to be able to respond to any new requests. In fact, there's a vulnerability for IIS using that very method that was recently patched.Something like that might work for a small personal site, but it's not an option for any site that is expecting a decent level of traffic.

[Citydev]

Servers have a maximum number of connections they can have open.

But presumably you can increase that limit if you know the bandwith usage per connection is low. I would have thought a connection is just a relatively tiny amount of memory plus a tiny amount of CPU for checking the thread. And, anyway, with the Cloud, you just fire up a few more boxes.

[justsomeguy]

Regardless of how many resources each connection uses, each server does have a maximum number of simultaneous connections. Normally the connection closes after the transfer ends so you don't hit the server cap. If you have all of the connection stay open you're essentially introducing a new requirement that every user needs a separate connection, so you're limiting traffic by how many connections the server can have open at one time. It seems a little silly to throw more than one server at a site that doesn't do much except keep a bunch of idle connections open, or to have a server with 10,000 threads running in order to serve 10,000 users. You should be able to serve several users with each thread, not just one per thread.More information about this kind of attack:http://ha.ckers.org/blog/20090617/slowloris-http-dos/http://www.theregister.co.uk/2009/06/20/apache_dos_flaw/The way to protect against this is to set the connection timeout on the server to a decently low number. Obviously this breaks the model of having the browser keep a connection open for whenever the server decides to push out an update.