Downloads Fail because Error 346 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH):

[Yourvirtualworld]

I will write back to my ISP. I'd like to present the case that operating their server for Zen Cart and allowing access to files in hidden directories is an acceptable, if not zero, risk. Any suggestions on what I can say?

Dear Sir/Madam,
Thank you for contacting support.

I understand your concerns, but the decision to block this aspect of Zen Cart functionality was taken by out system administrators, for the reasons described above, and can not be reversed at this point by technical support.

Like all the applications in Simple Scripts, Zen Cart is provided on an "as is" basis, and we can make no guarantee that every function of the application will be compatible with our environment. The great majority of Zen Cart users do not activate this aspect of the program, and so it isn't an issue for then,

If you wish to submit a suggestion that this policy be changed, to our business department, you can do so through the form below:
http://www.ipower.com/support/suggestions.bml
This will be sent to senior management for consideration, though obviously, I can not give any guarantee as to the outcome. I'd recommend including the ticket number [#xxxxxxxxxx] for background.

Thank You,
Jim M.
Technical Support

[DrByte]

Unfortunately, due to security reasons we do not allow accessing of files inside a hidden directory and this is causing the issue.

There are numerous "hidden" foldernames that are typically blocked by traditional server configurations, in the name of enforcing proper security.
It's highly unusual to totally cripple the server's normal operation by completely blocking all forms of access to legitimate foldernames that are dot-prefixed.

So, either the person you're quoting doesn't really know what they're talking about, or the server administrators have gone overboard in the name of "protection", demonstrating that it's very possible they don't actually know security very well and are just applying all kinds of blacklisting limitations on the customers in an attempt to protect them from themselves.

Who's the hosting company?

I could be wrong here, but as far as responding to their latest message, IMO you're clearly getting into a technical battle without even a quarter of the bigger picture's information. It's not worth your time. Find a better host: someone who knows what they're doing.

[Yourvirtualworld]

The hosting company is iPower - http://www.ipower.com . In the past I know they're handed me a lot of bogus information indicating that at least one person only half knows what they're talking about. They're badly misconfigured servers when relocating sites. They've mistakenly deleted entire sites and taken two days to restore them, and the list goes on... yet I like them and they've usually been very accommodating and gracious.

[Yourvirtualworld]

I'm still wondering why removing the dot (.) within the /includes/modules/pages/download/header_php.php file didn't allow ZC to bypass creation of a dot prefixed directory. It still creates a randomized dot prefixed directory. I even tried other characters in place of the dot and still no go. Would removing the entire line containing $dirname = '.'; work or would it break the code? I had changed it to: $dirname = '';


"If you must remove the dot, you'll have to manually edit a core file:
/includes/modules/pages/download/header_php.php
around line 71 you see:
Code:
function zen_random_name()
{
$letters = 'abcdefghijklmnopqrstuvwxyz';
$dirname = '.';

change that $dirname = '.'; by removing the dot

[DrByte]

I'm still wondering why removing the dot (.) within the /includes/modules/pages/download/header_php.php file didn't allow ZC to bypass creation of a dot prefixed directory. It still creates a randomized dot prefixed directory.

Well, since the only place where that directory gets created is in that script, then I can only imagine that you didn't actually upload the change to the script, or you didn't make the correct change.

The hosting company is iPower - http://www.ipower.com . In the past I know they're handed me a lot of bogus information indicating that at least one person only half knows what they're talking about. They're badly misconfigured servers when relocating sites. They've mistakenly deleted entire sites and taken two days to restore them, and the list goes on... yet I like them

iPower has a longstanding reputation of being very unsuitable for ecommerce. Of the many hosts out there that people have tried, iPower is one that's often demonstrated to be unsuitable, based on problems reported here when asking for support. The simplest smartest safest fastest solution to all those peoples' problems has typically been to switch to a more capable hosting company. I realize you're new here, but I've seen a lot of support requests here, and one of the hosts most commonly making it necessary for extra support help here contains "ipower" in the name in one form or another. Just saying.

[Yourvirtualworld]

The mods were correct. Something else is going on.

[DrByte]

Yes, clearly "something else" is going on.

I just made the same edit to a fresh clean install of Zen Cart 1.3.9h (and also in a fresh 1.5.0) here, and when I attempted a new download of a new purchase, it properly created a foldername in /pub/ which does NOT have a dot-prefix.

  $dirname = '.';

to

  $dirname = '';

So, whatever you or your host is doing is completely breaking the normal operation of the code.

[DrByte]

dot-prefix override support added in v1.5.1: https://github.com/zencart/zencart/commit/fcd8d9ffc0fce003016633137939563b2c608a46
and multiple-content-length issue also fixed in v1.5.1: https://github.com/zencart/zencart/c...c710705d001d76

[Yourvirtualworld]

Thanks DrByte for the fix to this terribly perplexing problem. Is it possible to simply replace the ZC 1.39H /download/header_php.php file with the ZC 1.5.1 file fix? I don't want to have to update the entire 1.39H installation with 1.5.1 update if it's not completely necessary.

[DrByte]

Is it possible to simply replace the ZC 1.39H /download/header_php.php file with the ZC 1.5.1 file fix?

Yes, I'm pretty sure the v1.5.1 version of that particular file should work fine on v1.3.9h.