[Standards] XEP-0124: terminate
mridul at sun.com
Tue May 29 22:27:36 UTC 2007
Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> Peter Saint-Andre wrote:
>>> Someone just pinged me via IM about session termination in XEP-0124:
>>> In particular, the spec doesn't say what a CM should return to the
>>> client if there are outstanding requests (e.g., the client could
>>> include things in the terminate request and the CM might receive a
>>> response from the server or network but have nowhere to send them).
>> It seems that I misunderstood the person I was chatting with. He meant
>> that there are outstanding HTTP requests, not that there are
>> outstanding XMPP requests (this is at the BOSH level, not the level of
>> XMPP). So let's say that in the current session the BOSH client is
>> limited to two simultaneous requests (requests=2) and one held request
>> (hold=1). Now assume that there is already one request on hold. The
>> client sends a terminate request. Two questions arise:
>> 1. Does the CM accept the terminate request (rather than returning an
>> error because the client is over its number of held requests) or does
>> it return an error?
> Well we already have an answer to that question, there is an exception
> for type='terminate' requests here:
> (It's cool that we have this stuff spec'd out, now I just need to read
> the specs before posting to the list... ;-)
> So the remaining question is what to do with the outstanding held request:
>> 2. If the CM accepts the terminate request, what does it do with the
>> outstanding held request? Send it to /dev/null?
In our implementation, as soon as a subsequent request with next rid
comes in, we try to 'free' the current request.
This is done since typically webapps have very limited number of
connections they can make to the backend and even if hold > 1, it tends
to be practical to assume it is 1 (since they would be part of a larger
So to answer your question - a subsequent (terminate) request will
'free' the previous request and make it respond to client (possibly with
empty body). And the latest request would finally close the session.
Now, the other interesting question would be :
What happens for retransmit requests after session has been terminated.
We hold it around for 'some time' before kicking them off (not really
dependent on wait/inactivity time).
More information about the Standards