Document Ultimate is not working in ASP.NET webforms

We deploy our ASP.NET webforms websites to a large number of clients on premise. We only have this issue on a very small number of client instances.

The Document Ultimate Control is on a specific Document View page which is then displayed in an iframe on the pages where it is used.

The document viewer is failing to load for all types of files and displays the following error in the console:

‘frmViewDocument.aspx:8 GET https://connx.XXXXXX.org.au/resource.ashx/605699360150000000/du/viewer.css net::ERR_CONTENT_DECODING_FAILED 200 (OK)’
‘frmViewDocument.aspx:9 GET https://connx.XXXXXX.org.au/resource.ashx/605699360150000000/du/viewer.js net::ERR_CONTENT_DECODING_FAILED 200 (OK)’

The following error is logged in our application log:

System.NullReferenceException: Object reference not set to an instance of an object.
at Mobile_frmMobilePayAdvices.Page_Load(Object sender, EventArgs e)
at System.Web.UI.Control.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Generally a ERR_CONTENT_DECODING_FAILED error indicates that there is some sort of compression issue with the website, however, dynamic compression was not enabled and we also disabled static compression to see if that had an impact.

Is there anything else we can try that might fix the issue?

Cem Alacayir Replied

7/6/2020 at 5:25 AM

Employee Post

Well, your error log;

Shows the error is happening in your own code Mobile_frmMobilePayAdvices.Page_Load

Regarding error “net::ERR_CONTENT_DECODING_FAILED 200 (OK)”:

This can happen when an HTTP request's headers claim that the content is gzip encoded, but it isn't.

So I suspect you are accidentaly redirecting /resource.ashx/605699360150000000/du/viewer.css to frmMobilePayAdvices.aspx ?

Do you use URLRewrite module in IIS? If so;

Here is a rule that stops rules for GleamTech handlers (this is for Microsoft's UrlRewrite module but the idea is same):

<rules>

</rule>

</rules>

</rewrite>

Add this rule to the top of the rules and when the request is .ashx, it will stop processing your other rules so that the .ashx request passes through and works.

Cem Alacayir Replied

7/19/2020 at 4:43 AM

Employee Post Marked As Answer

Ok, the problem turned out to be an outbound rule so the above inbound rule did not work for this case.

Add this rule at the top of outbound rules and when the request is one of our .ashx handler, it will stop processing your other rules so that our handler request passes through and works.

<rewrite> 
  <outboundRules>
    <rule name="Stop Outbound for GleamTech Handlers" stopProcessing="true">
      <match serverVariable="RESPONSE_SERVER" pattern=".*" />
      <conditions>
        <add input="{REQUEST_URI}" pattern="(resource|filemanager|fileuploader|documentviewer)\.ashx" />
      </conditions>
      <action type="None" />
    </rule> 
    .
    .
    . 
  </outboundRules>
</rewrite>

For reference, the specific outbound rule that caused the problem was this:

<rewrite>
  <outboundRules>
    <rule name="Add Strict-Transport-Security when HTTPS" enabled="true">
      <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" />
      <conditions>
        <add input="{HTTPS}" pattern="on" ignoreCase="true" />
      </conditions>
      <action type="Rewrite" value="max-age=31536000" />
    </rule>
  </outboundRules>
</rewrite>

More info: Our resource.ashx handler sends GZIP response for CSS and JS files (of course when browser supports it), however the above RESPONSE_Strict_Transport_Security outbound rule caused ERR_CONTENT_DECODING_FAILED for GZIP responses. So using our stop processing rule at the top should prevent it.

Actually the above outbound rule only adds this header to responses:

Strict-Transport-Security: max-age=31536000

And this specific header is not known to conflict with GZIP responses. So I suspect the actual problem is this:

Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded (“gzip”).

So the fix may be as easy as this one (may not even need our rule at the top):

 <outboundRules rewriteBeforeCache="true">

References:

https://www.saotn.org/iis-outbound-rules-with-gzip-compression/

https://blogs.iis.net/jeonghwan/iis-url-rewrite-one-of-known-issues-with-the-rewritebeforecache-feature

https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/using-url-rewrite-module-20

Additional note:

This problem happened only on some few machines so it's possible old version of URL Rewrite module may be causing the issue so first ensure you have the latest version of it:

https://www.iis.net/downloads/microsoft/url-rewrite

Then maybe you will not even need to add any settings (if the issue is not related to old versions of IIS)

2 Replies

Reply to Thread

Related Knowledge Base Articles

2 Replies

Reply to Thread

Tags

Related Knowledge Base Articles