Hi, I think both behavior are acceptable depending upon bosh connection manager. Suppose a previous "ping" request is pending and another "terminate" request is sent. While processing the "terminate" request, I think it is entirely upto the jabber server how it will react:
1) Sees new request and release previous "ping" request by sending empty response <body xmlns="..."/>. Thereafter, it realize new request is for termination, end user session on server and reply back with appropriate "terminate" payload. (ideally this is what should happen) 2) Sees new request as "terminate", end user session on the server. Since previous "ping" request is still with the server, it responds back with appropriate "terminate" payload for "ping" request itself. (ideally this should not happen) "A server MUST send its responses to those requests in the same order that the requests were received.", from RFC 2616, Section 8.1.2.2. Server will respond to connected requests in the same order, only when it receives a payload from an external entity for the connected sid,jid,rid combination. In case of newly sent "terminate" request by connected user, server has no knowledge of what payload it should send for previous "ping" request, and hence case 1) is what ideally should happen. -- Abhinav Singh, Founder, Jaxl Inc. Bangalore, India http://abhinavsingh.com/blog ________________________________ From: Tobias Markmann <[email protected]> To: Bidirectional Streams Over Synchronous HTTP <[email protected]> Sent: Mon, September 6, 2010 8:44:11 PM Subject: Re: [BOSH] terminating a BOSH connection On Mon, Sep 6, 2010 at 16:38, Artur Hefczyc <[email protected]> wrote: > My understanding is that the whole Bosh workflow works this way. > The response should be always sent to the oldest connection, leaving > the most recent idling and waiting for for more data to send. This is especially true if pipelining is applied. "A server MUST send its responses to those requests in the same order that the requests were received.", from RFC 2616, Section 8.1.2.2. -- Tobias
