[commits] [Wiki] changed: ActiveSync/BrokenClientBehavior
Michael Rubinsky
mrubinsk at horde.org
Thu May 29 17:00:07 UTC 2014
mrubinsk Thu, 29 May 2014 17:00:07 +0000
Modified page: http://wiki.horde.org/ActiveSync/BrokenClientBehavior
New Revision: 2
Change log: More stupid client information.
@@ -1,13 +1,22 @@
[[toc]]
+ Known broken !ActiveSync client behavior
-Many clients do not follow the published ActiveSync protocol
specification. In fact, even some of Microsoft's products are guilty
of this. This page attempts to document some of these idiosyncrasies.
Horde_ActiveSync attempts to work around those issues that are
possible to do so. Some broken behavior seems to be wide spread, and
are documented in the //General// section. More specific behavior is
documented in client specific sections.
+Many clients do not follow the published ActiveSync protocol
specification. In fact, even some of Microsoft's products are guilty
of this. Horde_ActiveSync attempts to work around those issues that
are possible to do so. This page attempts to document some of these
idiosyncrasies that we are not (yet?) able to workaround. Some broken
behavior seems to be wide spread, and are documented in the
//General// section. More specific behavior is documented in client
specific sections.
++ General
+++ The sending of STATUS_FOLDERSYNC_REQUIRED (12) is ignored by a
large number of clients.
This status code is issued in response to a SYNC request when the
server is unable to locate the folder data in the hierarchy cache.
I.e., the folder looks to no longer exist. This can happen when
something causes the server stored state to disappear (like when
explicitly removing a device from the server) or when something
corrupts the stored data. This is supposed to trigger the client to
issue a FOLDERSYNC request to freshen the hierarchy cache. Some
clients will continue to issue the exact same SYNC request in response
to this status code, causing a sync loop. Other clients will
accurately issue the FOLDERSYNC request, but fail to update their
local cache. Outlook 2013 does this. On receiving new FOLDERSYNC
responses, it continues to issue SYNC requests on the old folderids
(though it DOES reset the synckey, so **something** is happening in
the client, just not the correct something).
+
+
+++ Outlook 2013
+
++++ Duplicate email items due to broken MOVEITEMS request handling.
+
+When moving email items from one folder to another, or deleting them,
Outlook does not follow the specification for handling the move, which
leads to duplicate email items being present in the destination
folder. There are two issues interacting here that cause this. The
first, is that Outlook moves the local item on it's own, without
waiting for the DELETE and ADD commands to be issued from the server.
Instead, it reassigns the existing email the new UID received in the
MOVEITEMS response. Secondly, when it receives the ADD command for the
new email in the destination folder, it fails to treat this command as
an UPDATE command as the specification says you must when an ADD
command is received for an already existing UID.
+
+
More information about the commits
mailing list