As more and more websites and applications start moving to using the AJAX paradigm , people are going to hit this problem of how to use HTTP as a transport 'reliably'.
What I mean is , HTTP is essentially similar to a one way datagram approach to communication.
You send request A , wait for response A - move on.
Since this need not be a direct connection from client to server (even if it was) , the request could fail to be delivered , response could be 'lost' , connection errors , etc could intervene.
If they are idempotent
methods being made , then you can reissue them in case the request fails for whatever reason.
If not , things are slightly trickier - but there is some sort of support in most frameworks on how to handle this currently.
Add HTTP/1.1 persistent connections to this mix and things get really interesting - one socket fails : and a whole bunch of requests are lost.
Also, AJAX typically issues POST in most cases - a non-idempotent method.
Add to it the requirement to 'poll' the backend for data or updates and you have a interesting problem : you are trying to simulate a HTTP client into being something similar to a bidirectional stream : simulate is a key word here , mind you !
So you have requirements to 'manage HTTP as a transport' coming both at the client side and at the server side.
In the XMPP world , when support for HTTP was initially added the first approach was a pure polling
As can be guessed , they later developed the HTTP Binding solution under JEP 124
This is a very very interesting extension and I believe is the key to solving most of the problems above.
Though defined for XMPP , it is a solution to essentially act as a transport for any xml based protocol : only requirement, one or more "full xml stanza's" are exchanged - not partial xml data.
It solves the problems of retransmission , session management (no need for cookie's , url rewriting , etc) , support against replay attacks , etc.
Heck , we have XMPP - a purely xml based streaming protocol working on top of this successfully !
How does this help AJAX ?
So , potentially you could have :
<your application> --> <jep 124 client side js library> --- HTTP ---> <HTTP Bind gateway> <-- Custom protocol --> <Your server>
With suitable modification (IF your app is not XMPP that is
... why not move to it? Read prev post
on some advantages) , you can use the ideas from JEP 124 to solve a whole bunch of problems with using HTTP as a reliable transport.
Add to it the fact that you already have server side and client side opensource component's available to support this - and you have the perfect solution just waiting to be used.
Happy coding !