[Standards] XEP-0124: terminate
ian.paterson at clientside.co.uk
Wed May 30 00:30:30 UTC 2007
Mridul Muralidharan wrote:
> In our implementation, as soon as a subsequent request with next rid
> comes in, we try to 'free' the current request.
Yes. That is the intended behaviour.
> So to answer your question - a subsequent (terminate) request will
> 'free' the previous request and make it respond to client (possibly
> with empty body).
Not just possibly, certainly.
If there was already something to send back before the terminate arrived
then the other request would already have been responded to.
> And the latest request would finally close the session.
Yes. And to answer Peter's question, to quote from the spec, after
receiving a terminate from the client:
"The connection manager SHOULD return an HTTP 200 OK response with an
empty <body/> element. Upon receiving the response, the client MUST
consider the HTTP session to have been terminated."
> 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).
That's really nice of you. :-)
I agree it's an interesting question. I'm not yet sure we should force
all connection managers to be as kind as yours - especially since
providing a successful reply to a retransmit request under any
circumstances is only a SHOULD, not a MUST.
Does anyone strongly believe that CMs SHOULD respond even after the
client has terminated the session? If not (only MAY respond) then IMHO
we could even leave this behaviour unspecified. [But that might be
because I'm more lazy in the small hours of the night.]
More information about the Standards