| ff7e02603bc8196f411c0c491d74a42e747b7dc5 |
|
08-Aug-2013 |
Yu Ping Hu <yph@google.com> |
Decouple operation management from EasServerConnection.
This restructuring touches a regrettable number of files,
but allows us to put common code in a common base class.
(Before, it was messy because it would be muddled with the
connection management code.) Specifically, we want common
error paths to be handled in one place, although this isn't
implemented yet.
The new class of interest is EasOperation. This CL changes
Ping to use this base class. Future changes will switch all
operations to work this way.
Change-Id: I1bd26336e8916cafe592352f8ee05616bce8181c
/packages/apps/Exchange/src/com/android/exchange/EasResponse.java
|
| c9e47f85203da0ea3b6e9a49aa2007d1fc6f0814 |
|
08-May-2013 |
Yu Ping Hu <yph@google.com> |
Cleave sync adapter from ExchangeService.
All manual syncs now go through the system sync manager,
with no involvement of the SyncManager or the
ExchangeService (hopefully).
Push is not yet properly implemented in the new way.
Change-Id: I62477ff963016f878e244144d5ebbebce7fe2521
/packages/apps/Exchange/src/com/android/exchange/EasResponse.java
|
| 6760c30a8218c4ab1d38774ed0d765384ca1189b |
|
20-Oct-2011 |
Marc Blank <mblank@google.com> |
Close gzip streams properly
Bug: 5479150
Change-Id: I5cdaeb32563b6c535c82a95d5bcbc3b40a4d608b
/packages/apps/Exchange/src/com/android/exchange/EasResponse.java
|
| 6534bd5e100625c653c9fba09243bbb67a9023c7 |
|
05-Aug-2011 |
Marc Blank <mblank@google.com> |
Fix problem with SmartReply/Forward and deleted messages
* Please read bug 5112318 for a full analysis of the issue being
fixed in this CL
* When a send fails with an HTTP 500, and that send uses a "smart"
command, we retry the send without the "smart" command
* Also handle status 150 for EAS 14 (equivalent to HTTP 500)
* A little bit of cleanup
* Bug: 5112318
Change-Id: Id8325cd324cdc27f3b65b1d14d76da1ead80255c
/packages/apps/Exchange/src/com/android/exchange/EasResponse.java
|
| 3d6d254c2503e317b9b0873dc6a638c974f705f4 |
|
01-Jul-2011 |
Ben Komalo <benkomalo@google.com> |
Make client certificate requests optional.
This prevents things from always failing if the server requires a client
SSL certificate.
Note that the solution used to determine if a certificate request was
made for a given request is approximate; it is timestamp based and can
theoretically give a false positive. In practice, this is very unlikely,
since another cert request had to have happened around the same time,
AND the response must be a 401/403.
Change-Id: I726b32200ed784debfa72f033f61c71bfbc2ea10
/packages/apps/Exchange/src/com/android/exchange/EasResponse.java
|
| 0b3a1547b4adf380dab1cc9a1af6c227c9a4e00f |
|
16-Jun-2011 |
Ben Komalo <benkomalo@google.com> |
Wrap client certificate errors in EasResponse.
Client certificate errors and bad username/error passwords just return
403 and it's difficult for us to differentiate the two. The easiest way
right now is to track it using a dummy KeyManager that can detect when a
certificate is requested upon connection establishment (way low in the
bowels of the Apache HTTP stack).
This change propagates that information up to the EasResponse and
encapsulates it there.
In the future, we should be more flexible as there can theoretically be
servers that REQUEST certificates, but do not REQUIRE it, but this code
will present an error regardless.
Change-Id: I7ee36e2c2ab06bdb8ce34b8967b7cb241812ac96
/packages/apps/Exchange/src/com/android/exchange/EasResponse.java
|
| 498c903e02ef1b150d6dbd3a01d35839026db264 |
|
10-Jun-2011 |
Ben Komalo <benkomalo@google.com> |
Move EasResponse to top level class.
All behavior unmodified.
This prepares the way for some additional error codes (that aren't
necessarily HTTP error codes, since no connection can even be made) that
will be put on the EasResponse itself.
Change-Id: I1ba3b212dc63fb2f10a6462466e8fe62409b87e9
/packages/apps/Exchange/src/com/android/exchange/EasResponse.java
|