Connection dropped with extended ascii strings

[Per Inge Mathisen]

On Thu, 2008-12-11 at 09:03 -0500, Havoc Pennington wrote:
> Comment #1 https://bugs.freedesktop.org/show_bug.cgi?id=16338#c1
> explains in some detail.
> 
> As does http://lists.freedesktop.org/archives/dbus/2007-November/008975.html
> on the fix.
> 
> dbus_shutdown discussed in comment #1 here:
> https://bugs.freedesktop.org/show_bug.cgi?id=16924#c1

Thanks for your help. I take it that the fix mentioned above is not yet
implemented?

> The docs explain exactly when it calls exit (on disconnect) and how to
> turn it off; if you didn't read those docs, then you would not have
> read the docs explaining that you *must* exit on disconnect in the
> normal case, which just proves that we have the right *default* to
> exit on disconnect - unless the app installs an alternative disconnect
> handler. 

Can this alternative disconnect handler know the reason for the
disconnect somehow? An application that is required to be robust needs
to be able to recover from connections dropped due to errors, but should
still go down if the session itself is going down. But to do that it has
to know the difference.

> Disconnecting on not-well-formed data (such as bad UTF-8) should not
> be a surprise - http servers and imap servers and the like would
> typically do something similar. A daemon is not going to let you stay
> connected if you start sending suspicious-looking garbage that might
> crash somebody. (Which invalid utf8 is.)

I can certainly understand why the message would be dropped, but
terminating the entire connection seems unwarranted. It makes it far
harder than it ought to be to write robust applications.

  - Per