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.
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:
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.
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.
- The .NET Framework hotfix for Windows Server 2012 R2 , Windows Server 2012 , Windows Server 2008 R2 , or Windows Server 2008 .
- Service Pack 1 for SharePoint Server 2013.
- The December 2014 Cumulative Update for SharePoint 2013 (build 15.0.4675.1000) or a later cumulative update.
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:2996568 Hotfix rollup 2996568 for the .NET Framework 4.5, 4.5.1, and 4.5.2 on Vista SP2, Windows Server 2008 SP2, Windows 7 SP1, and Windows Server 2008 R2 SP1
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:2910943 Hotfix KB2910943 for SharePoint Foundation 2013 December 9, 2014 (Sts-x-none.msp)
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.
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:
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:
Windows Sign-In: Sending 401 for request 'http://teams.contoso.com/sites/DynamicsAx/EmployeeServices/ManageExpenses/Enterprise Portal/TrvItemization.aspx?WMI=TrvItemization&WTID=487&WKEY=[65534:5637169981 &WHPV=240BDFD957410B7F9D3A378ED39AEBC751579E3104F5A32A041E8F5B036C6DD1&cdlg=1&targetid=ctl00$ctl00$m$g_8168840a_90ac_4088_8a37_4a639462ec14$_content&IsDlg=1' because the user is not authenticated and resource requires authentication. 19e8009d-2bbe-9096-a427-11c747d167ff
w3wp.exe (0x2BEC) 0x09E4 SharePoint Foundation General b6p2 VerboseEx Sending HTTP response 401 - text/plain:401 UNAUTHORIZED. 19e8009d-2bbe-9096-a427-11c747d167ff
However, in the Fiddler trace, you find that instead of a "401" response code, the client received a "200" response code that includes a page redirect to the login page.
In Example 2 in the "Symptoms" section, an empty authentication token is sent that makes the following anonymous request:
w3wp.exe (0x19FC) 0x161C SharePoint Foundation Claims Authentication aip73 VerboseEx SPSam.OnSessionSecurityTokenReceived: Token is anonymous session security token. Cancelling event. 8d7d049d-9bed-70b9-242d-2586950a2d69
In this case, SharePoint sends the following "401" response code:
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."