[Standards] XEP 313 error handling
e at ik.nu
Thu Dec 4 18:10:45 UTC 2014
On 04/12/14 18:57, Kamil Kisiel wrote:
> On Thu, Dec 4, 2014 at 9:53 AM, Edwin Mons <jsf at edwinm.ik.nu
> <mailto:jsf at edwinm.ik.nu>> wrote:
> On 04/12/14 18:07, Kim Alvefur wrote:
> > On 2014-12-04 15:11, Kamil Kisiel wrote:
> >> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland
> <dave at cridland.net <mailto:dave at cridland.net>
> >> <mailto:dave at cridland.net <mailto:dave at cridland.net>>> wrote:
> >> On 3 Dec 2014 21:11, "Kurt Zeilenga"
> <kurt.zeilenga at isode.com <mailto:kurt.zeilenga at isode.com>
> >> <mailto:kurt.zeilenga at isode.com
> <mailto:kurt.zeilenga at isode.com>>> wrote:
> >> >
> >> > How does the server, after it has responded to the IQ
> with a type=result stanza, communicate errors in processing the
> query to the client that might subsequently occur. What if the
> server is unable to send any subsequent stanzas associated with
> the query? Is the server expected to hold off sending the IQ
> response until it is reasonable assured that no subsequent errors
> will occur? That is, to the time in which has compiled all the
> stanzas to sends to the client and is ready to put them to XMPP
> >> >
> >> > It seems to me that the IQ response really should come
> last so that the server is able to indicate to the client whether
> or not is has successfully completed the request or failed. If
> sent last, then there’s really no need for a separate <fin/>.
> >> >
> >> > If the IQ response is not last, there there really needs
> to be some method for the server to indicate that it’s not able to
> provide further results.
> >> >
> >> I think I agree with everything written here. Sending the
> iq last
> >> would be best, I think, though I appreciate that's likely
> to be a
> >> protocol bump.
> >> Dave.
> >> That's how it was specified in version 0.2, it seems it was
> changed to
> >> <fin/> in 0.3
> > I remember someone argued very persistently that this change was
> > because their code had timeouts for iq requests that could
> trigger if
> > there is rate limiting or a slow connection before all the
> messages and
> > the iq-reply was received.
> > Or something. Personally I prefer having the iq-result sent
> last, it
> > makes client code (Verse in my case) simpler.
> I believe that was Joe. Nowhere in the XEP do I see a requirement
> the server should send back the IQ result (or error) immediately, just
> that it has to answer the IQ, send back messages, and terminate with a
> <message><fin/></message>. The example seems to hint at sending
> the iq
> result first, but nowhere does this claim you have to send back the iq
> result before making an attempt to generate results internally. Only
> the examples hint that you should send back the iq result first, and
> indeed that was the intended behaviour as discussed at the summit.
> That seems a bit contradictory to me. If you can delay sending the
> result until all the messages have been sent, how does the <fin/>
> message solve the problem of timeouts waiting for the result iq? On
> the other hand if you are sending the iq result at the beginning to
> avoid the timeout, how do you indicate an iq error during the message
> stream? It doesn't seem clear what the answer is.
If you send back the iq result first, it will not be delayed further by
all the result messages. Why would there be an error during the message
stream that would prevent you from returning an otherwise valid 313
response (or in an extreme case terminating the stream and making the
point of properly finishing the messages moot?)
Most error cases will either happen before or at the moment when you
actually start to find messages, e.g. authz issues or database issues.
Once you start sending back messages, or know there aren't any for a
particular query, you can always present a valid message stream
including a fin with an appropriate rsm set a client can use to continue
a query should it choose to. Note that the XEP allows you to return
less items than the amount requested.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards