Hi Anthony. Let's have a look at the visitor's point of vue if you want :

http://www.ales.cci.fr/Default.aspx?tabid=191  Downloads a .pdf with a 0k size

http://www.aircreation.fr/Technique/tabid/28/Default.aspx Cannot read the .pdf either

http://www.cevennes-sports.fr/Manifestations/Résultatssportifs/TéléchargementRésultats/Année2006/tabid/320/Default.aspx

 (A messy website, sorry, but anyway has been working for years before v 3.3.5 that makes it impossible to download the .xls excel files)

I still investigating and cannot say much more at this time, but anyway 3.3.5 and 4.3.5 have not solved the problems that have been reported here and there after 3.3.4 and 4.3.4

The problem is in part dependant from the client, since I asked the french community to test the links of my previous posts, and the results are not consistent.

Some can download and view, others cannot. I could not make a rule out of that yet.

I confirm that these are websites that have been running document modules for monthes without an issue. But we also tested on a fresh DNN 4.3.5 and we have the same issue.

I turned HTTP compression off, but no better result (I am doing testing on 3 different web servers) - or is there some latency with that http compression - I'll wait and see.

Sometimes download files are truncated or uncomplete.

We reinstalled a former version of the document module. Same problem so the cause is in the core.

A programmer here noticed that just after he changed the line 'add verb="*" path="linkclick.aspx" in  web.config, he could download a file that was impossible to download before, but just for  a couple of seconds and then same problem again, just like if some restart had un-blocked something.

I understand that this is probably not the right forum for this discussion; the document modules just reveals this specific issue more than any other module.

Anthony, I've been into all these checkings. I only mentionned that touching this add verb ... line SOLVED the problem for a very short time, thus leting me into thinking that it might be related to the problem. However, having not gone much further into that way,  I put it back as it was.

I have done another very interesting testing, trying to reach the website and download the files from a chinese proxy, and it worked ! So I've investingated this a little further. As i said, some people can download, others cannot, there must be some difference depending on the client :

After comparing the headers, I found this (please note the different URLs ):

WITHOUT A PROXY, A REQUEST HEADER THAT WILL FAIL THE DOWNLOAD :

HTTP/1.1 200 OK
Date: Mon, 25 Sep 2006 13:58:00 GMT
Content-Length: 365441
Content-Type: application/octet-stream
Cache-Control: private
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
content-disposition: inline; filename=ResourcePack.Full.04.03.04.fr-FR.zip
Via: 1.1 supercache3 (NetCache NetApp/6.0.4)