After last update, the plug in sends zero length files

File is just about 500k in size and is stored in

/home4/host_user_name/downloads/vahrokh/public/applications/eve-online/income_analyzer/setup.exe

The website is in a subdirectory:
Multisite: No

SITE_URL: http://www.vahrokh.com/vahrokh
HOME_URL: http://www.vahrokh.com

EDD Version: 1.7.2
Upgraded From: 1.7.2
WordPress Version: 3.6
Permalink Structure: /%year%/%monthnum%/%postname%/

————-

Is there a way for me to send you such information in a private way? I am afraid sharing all my configurations to potential hackers.

If I can help you further please tell me what I could do for you. And thanks for your assistance!

The “info” says 1.7.2 (impossible as it’s the current release).

I tend to update most plug ins in the same day they become available, I had 1.7.1 as last version.

I had about 55 downloads working before I updated and something broke and then I started getting end users posting me about the zero length file.

If you could please tell me the whereabouts of the code responsible for sending the files in forced mode, I could slap in some “echo”, print_r etc. and see what’s interfering with the intended functionality.

Besides being useful to me, your plug in would benefit from solving this, as the affected website (I manage several) is on a very large hosting provider and thus the issue potentially affects all those who are on that hosting.

Thank you, I will check those functions once I get at home.

In the meanwhile, in that source file I have spotted stuff you might have an use for.

At line with this statement:

elseif ( stristr( getenv( ‘SERVER_SOFTWARE’ ), ‘nginx’ ) || stristr( getenv( ‘SERVER_SOFTWARE’ ), ‘cherokee’ ) )

I have just checked on one of my NGinx servers (latest version) and it has no “nginx” environment variable for getenv. I am not sure if NGinx automatically passes $_SERVER vars in environment vars (IIS does not).

A phpinfo() would only show the environment vars HOME and USER.

Instead I have this signature:

_SERVER[“SERVER_SOFTWARE”] => “nginx/1.4.1”

I repeat, I am not sure if phpfpm sets env var to the $_SERVER var.

Furthermore, the program enters in the nginx clause even if $direct == true and then proceeds building a path relative to the domain. In case of $direct && file residing outside the web path I feel this could break something. Maybe I have just read your source wrong (I had all of 30 seconds to skim through it) but still, it might be worth giving it a look.

Returning to this specific case, instead, here I have Apache and I don’t think it got mod_xsendfile installed.

Therefore the issue is going to be in edd_deliver_download(). I smell something breaks while creating the temp link.

Some updates.
The program flow, due to Apache not having the file mod installed nor symlinks being enabled etc. ends up calling

edd_readfile_chunked( $file, $retbytes = TRUE )
line 536.

In that function,

$handle = fopen( $file, ‘r’ );

should become

$handle = fopen( $file, ‘rb’ );

else you’ll have issues with servers’ operating systems supporting both text and binary reading (i.e. Windows).

Moreover the bug is immediately turned off if I comment out:

// ob_flush();
// flush();

at line 550.

Now I don’t have an idea about what flushing is doing in there.

Is it needed? I see the function mentions:

“See http://codeigniter.com/wiki/Download_helper_for_large_files/”

therefore did you copy the function including the flushing because it was already working in Code Igniter? I mean, is the flushing with no previous buffer setup or whatever the intended program flow?

I don’t know if removing the two flushing instructions is good, my file is 428k and thus does not even really test that fread loop.

Some extensive testing with files ranging from 0 to > $chunksize are needed to see if it’s still working.

Also, I don’t know about side effects of not flushing a large file. Does PHP allowed memory exhaust? No idea.

Anyway that’s food for thought, I am going to bed now.