I have recently renovated the GFWR Software site at members.shaw.ca/gfwrsoftware. In former days, it easily allowed readers to download installer files for the freeware programs I write in Visual Basic 6. Now, however, WHEN PUBLISHED, an attempt at downloading causes an error stating "The website declined to show this page", etc. However, before publishing, when testing the website in three different browsers, the downloads commence as they should, with no problem at all. I used Dreamweaver CS4 to make the site, and I have no control whatsoever over the servers.

Dani AI

Generated

Short summary and practical next steps.

The symptom described by — downloads work during local testing but return a 403 once published, and switching the downloadable from .exe to .zip fixed it — strongly suggests a host-level policy or server configuration that blocks or filters executable file types (common on shared hosts). A 403 means “forbidden”; it can come from file-permission settings, .htaccess rules, or mod_security / MIME-type filters that prevent serving .exe files. It can also be triggered by hotlink protection or antivirus/malware scanning on the hosting side.

How to confirm the cause

  • Fetch only headers to see the server response code and server string. Example:

    curl -I http://members.shaw.ca/gfwrsoftware/yourfile.exe

    A 403 response plus an explanatory header or a server error log entry is a good indicator of provider-side blocking. If access to logs is unavailable, opening a support ticket with the exact request time and URL lets the host examine their logs.

Workarounds and cleaner solutions

  • The simplest, policy-compliant fix is what already did: distribute the installer inside a .zip. This is widely accepted and avoids executable-blocking filters.
  • As suggested, server-side streaming (PHP/ASP/other) can serve files with controlled headers; where supported, use an internal sendfile mechanism (X-Sendfile / X-Accel-Redirect) to avoid streaming large binaries in script memory. Note: these require host support and may still be blocked if the host forbids .exe content entirely.
  • If control over the server is needed, use a proper file-distribution service (cloud storage, code-hosting releases) or upgrade hosting to one that permits binaries.

Practical checklist before contacting support

  • Verify URL case (Linux hosts are case-sensitive).
  • Check file permissions (typical read permission for the web user, e.g., 644).
  • Include the exact URL, timestamp, and a curl/wget output when asking support to speed diagnosis.
  • Avoid renaming extensions as a long-term workaround; prefer zipping or approved hosting.

Recommended Answers

All 2 Replies

Looks for all the world like a permissions problem. If you have no control over the servers then you probably can't change the access permissions for the directory you are storing the files in either.

If you are sure that the permissions aren't the issue, you might try not just linking directly to the file but rather using readfile() to send it.

From http://php.net/manual/en/function.readfile.php

<?php
$file = 'monkey.gif';

if (file_exists($file)) {
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename='.basename($file));
    header('Content-Transfer-Encoding: binary');
    header('Expires: 0');
    header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
    header('Pragma: public');
    header('Content-Length: ' . filesize($file));
    ob_clean();
    flush();
    readfile($file);
    exit;
}
?>

SOLVED - I changed the files I was offering to download from .exe files to .zip files, and everything worked just fine. Thanks for trying.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.