[JDEV] Jabberd 1.5 Development
Iain Shigeoka
iainshigeoka at yahoo.com
Wed Jan 16 16:47:51 CST 2002
On 1/16/02 8:51 AM, "Peter Saint-Andre" <stpeter at jabber.org> wrote:
>> Fantastic. While this is being done, I would really (really really)
>> appreciate it if someone would create a list of exactly what error codes are
>> reported in what situations. That would greatly help client writers react
>> properly to error codes and help independent server implementers provide the
>> uniform error reports.
>
> I have a list here:
>
> http://docs.jabber.org/general/html/protocol.html
>
> But I'll probably just add a similar list to the RFC I'm writing.
:) That isn't exactly what I meant. :) The Jabber docs do an excellent job
of documenting the fact that a certain error code means a certain thing.
For example that 401 means unauthorized while 403 means forbidden. However,
we don't have a list of the expected error codes for particular situations.
For example, I try and send a message packet before authenticating. The
server doesn't support any message sending prior to authentication (I know
the spec recommends store and forward after auth but my implementation may
consider that a huge DOS vulnerability so I want to reject all messages
until authenticated).
Does the server send back a 401 or a 403. Or a 405 (not allowed) or 406
(not acceptable). Or a 501 (not implemented... I guess messaging is not
implemented ...) or 503 (service unavailable)? All apply and I can see the
possibility that a particular implementer may see things differently and
choose different error codes.
However, client writers would be aided by consistent error messages.
Perhaps always 401 in this situation (no message store and forward until
auth). While a 403 is reserved for messaging to blacklisted addresses with
401's taking precedent over 403 (you'll get auth problems before blacklists
are checked).
Essentially, this would be the process of defining every protocol and
"valid" situation in Jabber as sets of "state diagrams" with some outcomes
(states) being error conditions with standard error code responses. Any
situation outside of the specs would be "unspecified" and therefore result
in unpredictable behavior... Right now we have no detailed specified
behavior so everything is "unpredictable" to a certain extent.
-iain
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the JDev
mailing list