none
HTTP 500 and lost data with ActiveSync RRS feed

  • Question

  • We are hitting a problem whereby our ActiveSync mail clients makes a Sync request to Exchange, and periodically receives a HTTP 500 response. 

    I have looked at the server logs and have determined that this is what happens:

    1. Client makes Sync request with Folder Sync Key 1
    2. Exchange returns data to the front end server with HTTP 200 and valid sync data + Folder Sync Key 2
    3. Front end server returns HTTP 500 to the client device
    4. Client device makes another Sync request with Sync key 1(Since it has not received valid data to request 1 above)
    5. Server responds with HTTP 200 + no data + no new Sync key
    6. New mail arrives at the server
    7. Client makes sync request with Sync key 1
    8. Server returns new mail to the client + sync key 3

    I do not understand how to recover the payload of the response that was returned in step (2) above. It is lost forever unless the client resets its sync key for the folder to 0 and resyncs the entire folder. I want to avoid this, since we hit these 500 errors multiple times a day.

    Is there any way to recover the lost mail by altering the parameters of subsequent sync requests with the original folder sync key?

    Friday, December 6, 2013 9:52 AM

Answers

  • I have worked out what this is - when you get a HTTP 500 response you need to issue another sync request before issuing the Ping request.


    If you make a sync request after the HTTP 500 response, then you'll get the missing data. If you make a Ping request in between the sync key has been obsoleted and can't be used to get back any data.

    Friday, December 6, 2013 5:56 PM
  • Hi Lee Laborczfalvi, I believe you are correct. Also, this behavior is described in MS-ASCMD section 3.1.5.7, Handling Status Errors. While the scenario described isn't exactly what you are dealing with, I believe the same logic applies.

    "In this case, the server response is not received by the client. The client knows it has not received a response if neither the airsync:Wait element nor airsync:HeartbeatInterval element was sent in the Sync request and the server response is not received immediately, or if the airsync:Wait element value or the airsync:HeartbeatInterval element value was specified in the Sync request and that time has elapsed. The data on the server changed. The client MUST resend the request. The server recognizes the duplicate request. Because the server changes have already occurred, the server resends the response to the client to keep the server and client synchronized."


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Monday, December 16, 2013 7:33 PM
    Moderator

All replies

  • Hello Lee

    Thank you for contacting Microsoft Support. A support engineer will be in touch to assist further.

    Regards.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Friday, December 6, 2013 5:52 PM
  • I have worked out what this is - when you get a HTTP 500 response you need to issue another sync request before issuing the Ping request.


    If you make a sync request after the HTTP 500 response, then you'll get the missing data. If you make a Ping request in between the sync key has been obsoleted and can't be used to get back any data.

    Friday, December 6, 2013 5:56 PM
  • Hi Lee Laborczfalvi, I believe you are correct. Also, this behavior is described in MS-ASCMD section 3.1.5.7, Handling Status Errors. While the scenario described isn't exactly what you are dealing with, I believe the same logic applies.

    "In this case, the server response is not received by the client. The client knows it has not received a response if neither the airsync:Wait element nor airsync:HeartbeatInterval element was sent in the Sync request and the server response is not received immediately, or if the airsync:Wait element value or the airsync:HeartbeatInterval element value was specified in the Sync request and that time has elapsed. The data on the server changed. The client MUST resend the request. The server recognizes the duplicate request. Because the server changes have already occurred, the server resends the response to the client to keep the server and client synchronized."


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Monday, December 16, 2013 7:33 PM
    Moderator