Sandstorm/Zero-day scan page no longer displays

You are using the DPI Engine (TLS/SSL Inspection) not the proxy, correct? 

This is actually a wanted behavior, as the DPI Engine cannot redirect on this level. 

But if the user "click again on the same download" it should show the waiting page (if the website supports this behavior). The reason is, DPI will try to slow down the download for some time but most browser notice this behavior and throw a "network error". 

Thanks for the reply LuCar!

Yes we're using DPI Engine with certs on all endpoints. What's strange is we never actually saw this before until we upgraded. We always had a tab open in the browser with the Sophos sandstorm page letting our end user know that is was scanning and when it was ready.

As you can see in the above screenshot, the end user tried to download that file 4 times and was never shown a scan page.

So you're saying the website has to support this behavior?

Kind of has to support this, yes. I cannot tell you, why this worked before, maybe the website changed something. But basically the DPI Engine struggles to "redirect" a certain resource, if there is nothing to redirect. So if the website presents a new download link all the time, we cannot redirect this request. Does the notification page work for other downloads? 

When you click on the link, the file if downloaded to the XG, and all but the last packet is sent to the client browser.  The last packet is held while the XG A/V scans the file.  If the file needs to be sandstorm'd then the connection is dropped.  DPI will then remember  (cache) the URL.  If anyone visits that exact same URL again in the next few minutes, they should get a Sandstorm pending page.

That cache that allows it to display the pending page only works if the next download attempt is the exact same URL.  But if the URL changes every click (for example with a timestamp passed in as a query parameter) then the DPI engine cannot be assured it is trying to download the same file.

Consider:
download.com/download.php?file=myfile1.exe&timestamp=1111

If the file has to be sandstorm'd the download fails.  The next download for the same URL will not actually start a download attempt, it will show a sandstorm page.

If the url changes at all (as it does in these two examples) then we cannot assume it is the same file, so we have to download it again, virus scan it again, etc.

download.com/download.php?file=myfile1.exe&timestamp=2222
download.com/download.php?file=myotherfile2.exe&timestamp=1

I don't recall, but potentially POST are never cached, because we cannot see the passed in parameters.

Websites that always use the same link will show the sandstorm page on the second attempt.  Websites that change the link will not.  There is no change in the XG behavior in this in any recent release.

When you click on the link, the file if downloaded to the XG, and all but the last packet is sent to the client browser.  The last packet is held while the XG A/V scans the file.  If the file needs to be sandstorm'd then the connection is dropped.  DPI will then remember  (cache) the URL.  If anyone visits that exact same URL again in the next few minutes, they should get a Sandstorm pending page.

That cache that allows it to display the pending page only works if the next download attempt is the exact same URL.  But if the URL changes every click (for example with a timestamp passed in as a query parameter) then the DPI engine cannot be assured it is trying to download the same file.

Consider:
download.com/download.php?file=myfile1.exe&timestamp=1111

If the file has to be sandstorm'd the download fails.  The next download for the same URL will not actually start a download attempt, it will show a sandstorm page.

If the url changes at all (as it does in these two examples) then we cannot assume it is the same file, so we have to download it again, virus scan it again, etc.

download.com/download.php?file=myfile1.exe&timestamp=2222
download.com/download.php?file=myotherfile2.exe&timestamp=1

I don't recall, but potentially POST are never cached, because we cannot see the passed in parameters.

Websites that always use the same link will show the sandstorm page on the second attempt.  Websites that change the link will not.  There is no change in the XG behavior in this in any recent release.