Network Error in Chrome while downloading files

The dev team reported an odd behavior that exhibited only in Chrome. Since MS Excel is a preferred tool to view transactional data for analysis/self-service, we have an Export function within web pages.

Using OpenXMLSDK to stream the data failed with a “Network Error” in chrome. Surprisingly the same functionality worked in Chrome when the website was hosted on IIS 8.5 / .NET 4.5.

I then traced the Request and Response in fiddler. Decoding the response threw the “chunked body did not terminate properly with 0-sized chunk” error. So, I suspected that the Response was being truncated.

Reviewing the .NET code, after writing the memory stream to the HTTP Response object,  we had a Response.Close. It looks like Response.Close drops the last chuck (in IIS prior IIS versions) causing Chrome to throw the network error. It doesn’t explain how Firefox and IE were able to keep the pipe open to receive the last chunk (need to dig into this further using wireshark).

Removed the Response.Close and all good now.

Troubleshooting – Erratic Load Balanced Web Application behavior

Have you ever run into situations where the Customer reports an issue, but the Dev Team is not able to reproduce it. Well, I have had several of these and sometimes one of the Web Server is configured differently than the rest in a Load Balanced environment. Sometimes these behavior also exhibit when we actually deploy a new farm or add new servers to an existing farm.

Recently a customer reported that attachments on a particular customer portal were not being viewable. Sure enough, when we tested this issue initially, it worked for us. We were able to quickly able to use this technique to isolate the server and then add the missing mime type.

The actual issue/behavior can be identified using Fiddler or the Developer Tools. Identifying the server that is causing the erratic user behavior is key to either quickly resolving or removing the server from the farm for offline resolution.

When adding each server to the farm, add a HTTP Response Header that uniquely identifies the server as shown in the screenshot below. Don’t include any sensitive details that might compromise your server.

screen_shot_2016-11-11_at_4_19_00_pm

Shown below is a Network Capture using Firefox / Firebug, but the same steps apply to Fiddler and other Developer Tools. After you have captured enough events to reproduce the issue, sift through the requests to find the offending request, identify the HTTP Response Header and you will be able to locate the server.

screen_shot_2016-11-11_at_4_03_53_pm

Keep in mind that the Developer Tools have limitation to the total number of requests / responses that can be captured without degrading performance. fiddler seems to be a better tool of choice for this particular debugging scenario.

It’s possible to programmatically set the HTTP Response Headers, but that’s a different topic.