ASP.NET MVC pages aren't served over 3G or certain proxy servers

Question

We've just pushed out a new ASP.NET MVC based web-app that works fine on all desktop connections, and all mobile devices such as iPhone, etc. However, when certain pages are viewed over a 3G connection (either via a 3G dongle on a laptop, or directly on a mobile device), a blank, white page is served with no content of any kind. It appears as if we've returned an empty request.

On certain proxied networks, we're getting a similar issue whereby they say our request size is too large. This sort of makes sense, as it only affects certain pages, and I would assume the mobile network providers operate all manner of proxy servers on their side.

However, I've not been able to find any information on what would constitute a request that was too large. I've profiled one of the pages in question, here are some of the stats I thought might be relevant:

HTML content size: 33.04KB compressed, 50.65KB uncompressed
Total size of all stylesheets (4 files): 32.39KB compressed, 181.65KB uncompressed
Total size of all external JS (24 files): 227.82KB compressed, 851.46KB uncompressed

To me, the compressed size of the content is not excessive, but perhaps I'm wrong. Can anyone advise on what I can do to solve this problem, as I've had a really hard time finding any definitive information on this.

Troth

Did you typo the size of your uncompressed CSS? I sure hope so. – Spitfire

I did, sorry about that. Fixed now – Troth

Have you tried turning off compression? It might be that your web server is implementing compression in a way that some web proxies or 3G network intermediaries can't handle. At the very least, share how compression is set up so we can see if that's where the problem lies. – Handoff

@Handoff that's an interesting idea. We have GZIP compression enabled, which has been causing problems for some of our clients on Windows XP clients. I don't have the full details of our compression setup to hand, but I'll query with our infra guys and confirm. I hadn't considered that as an option. – Troth

@Handoff - unfortunately, disabling compression on our server didn't fix the issue. – Troth

We did actually resolve this issue, and it was down to the size and number of Set-Cookie items in the response header. We found we had a bug whereby there were nearly 100 Set-Cookie items in the header. Resolving this bug, and reducing the size of the values fixed the issue – Troth

Answer 1

We did actually resolve this issue, and it was down to the size and number of Set-Cookie items in the response header. We found we had a bug whereby there were nearly 100 Set-Cookie items in the header. Resolving this bug, and reducing the size of the values fixed the issue

Troth

Answer 2

As far as the MVC is concerned 3G networks are no different than Wifi. However there is a limitation on the size of the files that mobiles can Cache. In that case those files will be requested from the server with each postback.

Since some of the pages do work, I think its a good idea to isolate the problem to specific point of failure than searching in wild.

You can debug problems easilt with a 3G dongle and firebug in Firefox or Chrome developer tools

• Make sure there are no Java Script errors in the first place that's causing the problem
• Confirm the Javascript/css/html files are indeed delivered to the client. (Firebug on the client). On the server check the IIS logs or MS Network Monitor or create a http proxy where you can monitor the traffic. Try which ever you are comfortable with.
• You have nearly 30 requests just for css/java script/html and the count may be higher if you have images. Completeting all those requests may be taking forever on 3G. Try bundling the Java Script files and reduce the request count. Browsers have limitation on number of simultaneous requests they can make, adding to the over all time (Firefox I believe can make around 10 simultaneous requests).

Iridescent

Thanks for your suggestions. The thing is, our JS/CSS loading isn't highly optimised at the moment, so we serve the exact same, minified and bundled payload of JS and CSS on every page on the site. To me, this rules out the possibility of it being related to the JS/CSS. I would also assume it rules out a caching/loading issue, as the same mobile devices are fine on a WiFi connection, etc. My assumption is it must be related to size of the initial HTML packets, but I can find no information to confirm if that could be a problem, and if so, what that size limit is. – Troth