authTokenControl was introduced as part of the changes for Bug 71479 ? Clear cookie when one parameter is set in Soap Request
This is from Comment #19 of the bug, which I hope explains it:
soap.txt does have something to say about <change>:
Added an optional <authTokenControl voidOnExpired="1"/> element in
soap context. If this element is present, and if the incoming auth
token is expired, server will just "void"(i.e. set the mAuthToken
field in ZimbraSoapContext to null, as if there is no auth token for
the request ) the auth token instead of throwing AUTH_EXPIRED.
The auth token can come in the <authToken> element in soap context,
or in a http cookie as a fallback, <authTokenControl
voidOnExpired="1"/> does not distinguish the two cases. It just
applies to the auth token object returned from the AuthProvider.
In other words, if the incoming auth token is expired:
- If <authTokenControl voidOnExpired="1"/> is not present, server
will throw AUTH_EXPIRED exception - nothing changed.
- If <authTokenControl voidOnExpired="1"/> is present:
- if a valid auth token is required for the request, server
will throw AUTH_REQUIRED.
- otherwise, the request will go through
<authTokenControl voidOnExpired="1"/> should be used with the
ClearCookieRequest. Usage is when browser sends in expired auth
token cookie beyond the control of the web client code. This
problem is triggered becasue we now set httpOnly attribute on auth
token cookie, as a result, client cannot get to or clear cookies
cookie - we set Max-Age only when user opts to "remember me" (i.e.
ask browser to persist cookies after browser exits.).
In other words, if a modification just involved tagging an item, then if type="mod", mail.MODIFY_CONFLICT would be thrown but if type="new" it wouldn't.
To avoid race conditions, the client may specify the highest change ID
that it knows about in the <change> header element. The default behavior
(type="mod") will cause mail.MODIFY_CONFLICT to be thrown if we try to
modify an object that has been touched (flags, tags, folders, etc.) since
the specified change ID. Alternatively, type="new" will throw
mail.MODIFY_CONFLICT if we try to modify an object that has been created
or whose content has been modified since the specified change ID.
In general, the sync client will use type="mod" and the web client will
Hope that helps,