Support Article
Report export POST request has Content-Length: 0
Summary
When using integrated report viewer there is export functionality (for example Export to Excel). This functionality, when clicked on export button generates POST request with Content-Length: 0 which is blocked by Application firewall that is between external gateway (F5) and internal load balancer and reported as security issue.
Is there some simple way to fix this?
Steps to Reproduce
Show any report in default generic report viewer, use Export to Excel functionality.
Root Cause
The root cause of this problem is in a third-party product integrated with PRPC. When we try "export to excel" a report definition, Fiddler throws a HTTP 500 error saying the request was rejected by the server. Possibly blocked by firewall.
Following is an analysis as to what happens when we click the "export to excel" button:
1. The export to excel button has the following code in the html:
2. The exportToExcel function present in the pzpega_report_definition.js javascript file is executed. The function (as shown below) basically creates an html form to submit a http POST request to the server to run the pzRDExportWrapper Activity which is responsible for fetching the report content from the clipboard and exporting the same in an excel format.
var B=document.createElement("form");
B.id="formExportViewToExcel";
B.method="POST";
B.target="_target";
document.body.appendChild(B);
var C=document.forms.formExportViewToExcel;
if(pega.env.ua.webkit){
C.target=""
}
var E=new SafeURL("Rule-Obj-Report-Definition.pzRDExportWrapper");
E.put("PrimaryPageName",A);
E.put("pzPrimaryPageName",A+".pyReportDefinition");
E.put("exportmode","excel");
C.action=E.toURL();
C.submit();
document.body.removeChild(B)
}
Thus, we are basically sending a POST request to export the report into an excel. The reason for the content-length to be 0 is mostly to do with how IE handles POSTS requests from a form submit behavior. A lot of information can be found online. An excerpt is as follows:
Internet Explorer does not send form fields if they are posted from an authenticated site (NTLM) to a non-authenticated site (anonymous).
This is feature for challange-response situations (NTLM- or Kerberos- secured web sites) where IE can expect that the first POST request immediately leads to an HTTP 401 Authentication Required response (which includes a challenge), and only the second POST request (which includes the response to the challange) will actually be accepted. In these situations IE does not upload the possibly large request body with the first request for performance reasons.
This behavior occurs every time an HTTP POST is made from a NTLM authenticated (i.e. Intranet) page to a non-authenticated (i.e. Internet) page, or if the non-authenticated page is part of a frameset, where the frameset page is authenticated.
The work-around is either to use a GET request as the form method, or to make sure the non-authenticated page is opened in a fresh tab/window (favorite/link target) without a partly authenticated frameset. As soon as the authentication model for the whole window is consistent, IE will start to send form contents again.
This could be a server side issue. The response header showed the below which could possibly give us a clue:
Resolution
The explanation for this behavior is as follows:
The issue was not reproducible and seemed to be a 3rd party issue. The fiddler trace showed the below:
Published January 31, 2016 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.