0

I have a WS2012r2 web server with multiple sites. We host zip files that are accessed though a direct URL (http://mysite.me/Test.zip").

These files are used to update our software and are downloaded using a c# WebClient but the same issue occurs when downloading via browsers.

The issue is only affecting one client, the file is being corrupted as a part of the download, it looks like it is one KB smaller than what it should be. But if i put the same zip on dropbox and download it, it works fine.

  • I have disabled static content compression
  • I have changed the mime type to application/zip or application/octet-stream
  • I have disabled output caching

these are the headers being returned:

Accept-Ranges : bytes

Content-Length : 1289611

Content-Type : application/zip

Date : Fri, 18 Jul 2014 01:00:20 GMT

ETag : "e3b794fa2cf1:0"

Last-Modified : Thu, 17 Jul 2014 22:36:40 GMT

Server : Microsoft-IIS/8.5

X-Powered-By : ASP.NET

Like I say this is only happening to one client, but only on my server.

Any idea?

Improve this question
4
  • 1
    What's the betting DropBox serves it over HTTPS, and the client's broken transparent HTTP proxy, AntiVirus, browser plugins or malware can't get in the way and ruin things?
    – TessellatingHeckler
    Jul 18, 2014 at 2:12
  • dropbox is https, AV or AM may get in the way, browser has been excluded by downloading with script.
    – TheRealTy
    Jul 18, 2014 at 2:55
  • @TessellatingHeckler Thanks for https hint, i've tested another server (linux) and get the corrupt file too. I can now wipe my hands of it. If you post as an answer ill give you a tick!
    – TheRealTy
    Jul 18, 2014 at 3:11
  • Good news. I've posted as an answer, although it doesn't feel like I actually answered your question - it would probably be more appropriate for the site if you upvote my answer, and then post your resolution and tick your own post.
    – TessellatingHeckler
    Jul 18, 2014 at 3:21

2 Answers 2

Reset to default
1

This could be caused by an HTTP proxy at the client site (e.g. an office firewall, SQUID cache server) or on the client computer.

An interesting test would be to rule out anything along the way being able to interfere with the download, by serving the file over HTTPS.

Improve this answer
0

Thanks to @TessellatingHeckler advice I found the issue was more thta one server, passed it back to the clients tech and they decided to look at it.

It was ClamAV getting a false positive

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .