Changes to form data are lost when page refreshes during form POST in SharePoint 2013

Symptoms

Assume that you have a form in Microsoft SharePoint 2013 that performs an AJAX postback to retrieve data from the server. Intermittently, the whole form page refreshes when the form posts. This causes you to lose any changes that you made in other form fields.

Example 1

On a Microsoft Dynamics AX 2012 Enterprise portal, you open a new form for expense report itemization. You enter text into some fields on the form. When you make a selection on one of the other fields, the whole form refreshes and deletes text that you entered into other fields. This problem also occurs when you enter text into Purchase Order Requisition forms or you add credit card transactions to an expense report.

Example 2

In Microsoft SQL Server Reporting Services (SSRS) running in SharePoint-integrated mode, you change report parameters. Intermittently, the whole page refreshes and deletes previous changes that you made to other report parameters.

In a Fiddler trace, you see a POST request that was made to "/_layouts/15/ReportServer/RSViewerPage.aspx." This post contains an XMLHttpRequest header that receives a "200" response from the server. However, the body of the response contains a redirect directive that resembles the following:

1|#||4|498|pageRedirect||%2f_login%2fdefault.aspx%<...line truncated>

This is followed by client requests to "/_login/default.aspx with a 302 redirection to /_windows/default.aspx." These requests cause a whole page refresh of RSViewerPage.aspx.

Note This problem can be intermittent. It may reproduce more frequently in some browsers, although the problem is observed in multiple browsers.

Cause

This problem occurs because of a known conflict between the Microsoft .NET Framework and SharePoint 2013 in which "401" responses to AJAX postbacks are repackaged as "200" responses and include a redirection to the login page (_login/default.aspx).

Some AJAX POST requests are sent anonymously, especially when they use NTLM authentication. This is typically not an issue. In this situation, the SharePoint server sends a "401" response, the client and server perform the "NTLM handshake," and the client then reposts by using authentication. This all occurs in the background without refreshing the page. Therefore, the page maintains the form data.

However, because of this known conflict, the SharePoint code first creates a "401" response that is repackaged as a "200" response that includes a redirection to the login page in the body of the response. The form then redirects to the login page to handle the authentication. But because the redirection causes the whole form to update, changes are lost.

Important You must install these fixes on all the SharePoint servers in the farm.

Notes about the fixes

The fix for the .NET Framework puts a flag on the request to indicate that it is a redirect, even if it contains a "200" response code. The fix for SharePoint then checks for that flag and changes the response code to "401" so that the browser can authenticate in the background as it usually does.

The .NET Framework issue is described as "Issue 8" in the following article in the Microsoft Knowledge Base:

When you use AJAX postback on a page, the postback is occasionally redirected to another URL. You can obtain the RedirectLocation in an HTTP module through HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].

The SharePoint issue is described in the following article in the Microsoft Knowledge Base:

When you browse to a SharePoint 2013 page that contains an UpdatePanel control, the page may be refreshed randomly. Therefore, if you type something in a text field on the page, the text field may become empty.

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

More Information

The best method to determine whether you are experiencing this behavior is by using a Fiddler trace together with Verbose SharePoint ULS logs.

In the Fiddler trace, find the problem POST request that the form made. The request is usually made immediately before the client makes requests to _login/default.aspx and _windows/default.aspx.

If you view the Auth tab for the POST request, you find that the client provides no authentication. You also find that the server response is "200-ok." However, if you view the TextView, WebView, or Raw tabs, you find that the client is performing a redirect to the login page by using the pageRedirect directive that resembles the following:

1|#||4|792|pageRedirect||%2f_login%2fdefault.aspx%3fReturnUrl<… line truncated>

In the server's "200" response code, the value for SPRequestGuid (for example: 19e8009d-2bbe-9096-a427-11c747d167ff) is the correlating GUID for that request. If you filter the ULS logs by using this GUID, SharePoint reports that it is sending a "401" response code, as follows:

Only in the Fiddler trace do you see that the client does not receive a "401" response code. Instead, it receives a "200" response code that has a pageRedirect directive pointing at "_login/default.aspx."