I had initially looked through the connection tracing logs and thought that there might be an issue with one of my media filters, but disabling these did not change anything.
It now looks like the problem relates to a script requiring authentication. All of our proxy traffic requires authentication. When I disable the authorize and authenticate ruleset, the file downloads successfully. I can't pinpoint what script is running or what additional site is being referenced.
Actually I was wrong about the authentication. Even if I disable every policy/rule, I cannot download the file.
if you disable every rule and still can't download the file it is either a network problem or a problem of the proxy implementation. The network traces might help here, especially the server communication (MWG <-> Webserver) would be important.
I've tested the download with 188.8.131.52.0 (9451) and I can download the file. If you have an older build you might want to upgrade. 184.108.40.206 includes several fixes for not quite RFC conform header formats and bug fixes for chunked encoding transfer. As this server is using chunked encoding and the file is fairly small this might be such a problem.
Yes, I am using 220.127.116.11.0 (9451). I have two completely separate domains/networks each a VMware based Proxy HA implementation. I deployed all the MWG's so they should be identical which matches the behavior on both networks. I will investigate further.
I tried the URL you posted and recieved the same results you did - page cannot be displayed within IE, and an auth prompt in Firefox. Upon some further testing, I bypassed authentication for my PC on the WG7. Still recieved the page cannot be displayed within IE but the auth prompt in Firefox went away. I then put *eventbrite.com in a URL.Host whitelist for the Media Type Filters - same results. Finally, I put an *eventbrite.com entry into the URL.Host whitelist for into the AV scan ruleset. Once I did that, the file downloaded as expected.
Just thought I'd offer that up so you know that it can work.
I've been able to reprduce this on a different machine and it seems server related. The same file downloaded from a different server works fine. The Gateway Antimalware ruleset has an effect, when it is disabled the download worked. I can't see an error in the antimalware engine directly and currently I assume a problem with the request passing from the proxy towards the AV engine.
I've all the network traces I need and forwarded this to development. This needs to be debugged I guess.
1 of 1 people found this helpful
Already received feeback from development. It's a bug on the server. There are several bugs actually.
In case you can download the file, look at the end of the document with an editor (hex-editor) and you will notice a HTML file. This shouldn't be. The server sends the content and then a HTML page, which is wrong.
In addition the content is supposed to be gzip encoded when your browser accepts this. The server only encodes the HTML page at the end, not the file that is transfered. This is what prevents the page from getting delivered to the client, because encoding obviously fails.
This is a bug with the script on the site that creates the document.
If you rely on this site you could create a rule that removes the"Accept-Encoding" header from the browser request for this domain, so that the webserver will not try to send responses with broken encoding. The PDF is still not ok, but it can be downloaded and most PDF viewers probably don't mind the error and will open the file anyway.