00600: Disabling direct downloads leads to change in download file treatment

Summary: Disabling direct downloads leads to change in download file treatment
Created: 2005-11-18 12:17
Status: Closed, not a bug
Category: Other
From: Henning
Priority: 4
Version: 2.0.11
OS: Windows XP/Apache 2

Description: This is a really strange one. After disabling direct downloads, uploaded ZIP files viewed via Winzip seem to contain no files at all. All ZIPs seem to be affected.

If the files are stored directly to the disk and opened then, there is no problem at all.

Now this is probably a client-side problem, but I believe PmWiki might be involved in some weird way because occurence of the problem depends on PmWiki configuration.

(This is another of the problems I ran into after being forced to disable direct downloads by 00588.)

--Henning November 18, 2005, at 12:17 PM

Is the problem for uploaded zip files with non-ASCII chars in the name, or all uploaded zip files?

If you turn off direct downloads, does the problem go away?

Do they "seem" to contain no files at all (when viewed through the browser via indirect download), or do they actually contain no files (as viewed directly on the server)?


All ZIP files are affected. The name is not a factor, and the files are actually valid when downloaded and viewed then - they just don't display properly when opened via the browser with direct downloads disabled.

I just found that I can simply type the URL of a seemingly empty file into the browser address line, and the same browser displays the same file correctly with all zipped files present and valid.

--Henning November 22, 2005, at 07:34 AM

I have watched the behaviour of this effect, and it seems completely erratic. Here is one explanation attempt:

  • The failure to display the files correctly is caused by a time out of the PHP code on the server.
  • The affected files might not time out if downloaded directly, but starting Winzip as additional application causes the client to waste some of the PHP runtime allowance without accepting data.
  • Files that are near the maximum PHP runtime get pushed beyond the limit and fail if viewed directly, but not when saved to disk as no extra delay occurrs.

Since this doesn't seem to be a PmWiki problem, I'm closing the PITS. --Henning June 06, 2006, at 10:14 AM