HTTP push module - how to use

Ian Hobson ian at
Tue May 4 14:05:36 MSD 2010


I saw the HTTP push module and it looks like it might be ideal for my 
purposes, but I am not clear how best to use it. (Linux nubie).

It seems that I set up the  module and configure it to have a /publish 
and /subscribe url - each using ?id=<channel> parameter, so we can have 
more than one push stream at a time.

The javascript in the clients then use XMLHttpRequest to GET from the 
subscribe URL. When the reply arrives, it acts upon what arrived, and 
immediately issues the next GET.

Each client will also have a form which POSTs to another URL - lets call 
this chat.php that will
    a) Authenticate that this client may speak :)
    b) Filtering - not those words, but recognising requests for info, 
fetched on demand.
    c) Do Logging,
    d) Use the cURL library to POST what should be published to the 
/publish URL
    e) Return an empty 200 reply (so the page is not replaced).

I've had trouble in the past with Apache timing out long running 
processes after 600 seconds. Do I need some sort of heartbeat to avoid 
these problems?

The browser will time-out the subscribe request after a while. If there 
is nothing broadcast for a while and the HTTP stack times out then 
(IIRC) no event is called which means Javscript cannot re-issue the 
subscribe. How can I code round this?

My customer wants the clients to see when someone starts to type. This 
could be a message sent when the first character is entered into the 
input box. When it arrives the javascript will alter the icon 
representing that person. Sounds OK. Would it be fast enough?

My startup page must read the log and include all the history in the 
initial page. So I will have to pass message numbers (or timestamps?) 
through from the log to the initial page, to the first subscribe 
request. I am not clear what to pass to the subscribe URL to get the 
right messages. Note - some messages, such as the "typing" update, are 
not logged!

Using this module would be a major departure from the current design ( 
"long polling", with a timeout of 4 seconds), but could be MUCH more 

Comments and advice welcome.



More information about the nginx mailing list