diff options
| author | Havoc Pennington <hp@redhat.com> | 2003-10-14 22:16:03 +0000 |
|---|---|---|
| committer | Havoc Pennington <hp@redhat.com> | 2003-10-14 22:16:03 +0000 |
| commit | 3251264ac483680b4a5fe808729f7e3b34f41fd4 (patch) | |
| tree | 0b2a953be7b1a858c5759158e834de3d2d1b763e /doc/dbus-specification.xml | |
| parent | b704a068a92c00b50e7d5f33ef6c8e1c3a87ceae (diff) | |
2003-10-14 Havoc Pennington <hp@redhat.com>
* bus/bus.c (bus_context_check_security_policy): revamp this to
work more sanely with new policy-based requested reply setup
* bus/connection.c (bus_transaction_send_from_driver): set bus
driver messages as no reply
* bus/policy.c (bus_client_policy_check_can_receive): handle a
requested_reply attribute on allow/deny rules
* bus/system.conf: add <allow requested_reply="true"/>
* bus/driver.c (bus_driver_handle_message): fix check for replies
sent to the bus driver, which was backward. How did this ever work
at all though? I think I'm missing something.
* dbus/dbus-message.c (decode_header_data): require error and
method return messages to have a reply serial field to be valid
(_dbus_message_loader_queue_messages): break up this function;
validate that reply serial and plain serial are nonzero;
clean up the OOM/error handling.
(get_uint_field): don't return -1 from this
(dbus_message_create_header): fix signed/unsigned bug
* bus/connection.c (bus_connections_expect_reply): save serial of
the incoming message, not reply serial
Diffstat (limited to 'doc/dbus-specification.xml')
| -rw-r--r-- | doc/dbus-specification.xml | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 698e35a2..807769b7 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -645,6 +645,11 @@ was successfully processed. </para> <para> + The METHOD_RETURN or ERROR reply message MUST have the REPLY_SERIAL + header field. If this field is missing, it should be treated as + a corrupt message. + </para> + <para> If a METHOD_CALL message has the flag NO_REPLY_EXPECTED, then as an optimization the application receiving the method call may choose to omit the reply message (regardless of |