Has anyone experienced problems loading large iOS (iPad in this case) apps through a webgateway? We have a 11-12M app that loads fine over 3G or an open Internet connect, but fails when going through the webgateway. It appears to start fine, then stops after 10 seconds. The tcpdump shows the request from the client (via itms-services://...) properly being forwarded to the destination, and content being retrieved by the gateway. After 10 seconds (with no packets returned to the client), the client send a RST.
I've set the proxy control timeout value to 3600 seconds, and do not enable a progress page nor data trickling.
For some reason, it appears that the webgateway is queueing up the content before sending it back to the client, and the client has a short timeout for a response.Any ideas on how I can force the webgateway to flow the content on to the client?
We're on webgateway 126.96.36.199 on WG5000 devices.
So you are not sending a progress page at all?
If you are applying filters, then you definitly DO want the progress pages to be shown, otherwise the Web Gateway WILL sit on the download until its done downloading and scanning the content. The progress page is meant to allow the MWG to let the client know that it's downloading the file. In the least you should have data trickling.
The 3600 second timeout you set only changes the MWG's behavior with the web server, ie if you are attempting to run a report on a web server and the server takes for ever to return a response.
This timeout cannot control the clients own timeout (which sounds like it's 10 seconds).
I forgot to add that I am bypassing scanning for this URL, in the expectation that the gateway will not download the entire file before sending response back to client.
I verified this again this morning with log entries and tracefiles. Of course, this morning the Internet is faster and the download between the gateway and the external site takes 9.5 seconds, and the client is satisfied.
However, watching the trace file I still see communications only between gateway and server until the entire content has been received, then the gateway-client communication starts back up.
The iOS packages are zip-based archives, so we're detecting that this is a zip, so we're going to open it with corresponding opener, and checking everything in it.There is separate mime type for it: application/vnd.apple.ios-package, so you can disable opening of this file types if you want
Data trickling verified to be on. Progress page off.
Verifed that I am not calling Antimaleware.Infected.
So, based on my knowledge of the gateway, it should not be holding and scanning the file. Is there someplace else that the gateway may be doing this that I'm not seeing?
If you open a case I can pick it up.
This has to do something with filtering applying (be it anti-malware or the opener) causing the file to not be sent back immediatley.
Include whatever data you have including a feedback. Dont post it here.
Thanks Jon. I've opened a case, number 3-2678165123. I attached the feedback file to the case via the portal. I put a tracefile on the ftp.support.securecomputing.com, prefaced with the issue number.
Just to further clarify, some properties require further inspection in order to be filled.
In this case Al had a rule which was calling "MediaTypes.EnsuredTypes" above his data trickling rule. The media type rule was causing the MWG to sit on the file download rather than start trickling data back to the client.
So, moving data trickling to the top resolved the issue in this case because MWG would start to send data to the client and not sit on the file instead.