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

I've set up a Zen Cart store offering downloaded products only. Failure for customers to actually download their product is a showstopper of the first order. Immediately after their purchase or when they log into My Account > View > Download they are presented with an error page that states:

"Duplicate headers received from server
The response from the server contained duplicate headers. This problem is generally the result of a misconfigured website or proxy. Only the website or proxy administrator can fix this issue.
Error 346 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH): Multiple distinct Content-Length headers received. This is disallowed to protect against HTTP response splitting attacks."

After two days of going back and forth with my ISP, performing web searches, and searching these forums I'm resorting to posting this problem because it's similar to other posts but also unique. My ISP techie researched my problem and responded:

Hello Yourvirtualworld,

Thank you for your patience.

I have checked once again the issue with the downloading the zip file at http://www.xxxxxxx.xxx . However, I have noticed that when we click on the download option the URL is re-directing to 'www.xxxxxxxx.xxx/pub/.zzychircojejjs/xxxxxxxxxxxxx.zip' (my masking for this forum) and displays the Bad Request error. This is because of the special character in the URL that is folder name with dot '.zzychircojejjs'. I have tried by renaming the folder without dot, however when I click on the download link it will create the separate folder name with dot inside the folder 'pub'. So, you need to check the script so that folder should appear without special character in the URL. If the issue still persists please contact the web developer or application vender regarding this issue.

If you have any further questions, please update the Support Console.

Sincerely,

Aldo XXXXX
Level 3 Technical Support:clap:

My question then is in three parts:

1. What script must I modify to be rid of this error assuming Aldo's analysis is correct?
2. What may have modified this script from its installed state to render it now buggy?
3. If the script was not modified from the installed version 1.3.9H then how could it ship to users and cause days of grief to those of us trying to use it?:(

So much thanks to anybody who can help!

I am a bit confused by directions given in Zen Cart regarding download configuration setup. The admin tasks at Configuration>Attribute Settings>Download by Redirect notes:
"Please make any necessary changes

Download by Redirect
Use browser redirection for download. Disable on non-Unix systems.

Note: Set /pub to 777 when redirect is true

#___
and the directions given in the Zen Cart Manual on page 212-213:

"3. Edit the Download by Redirect field to bring up the following side-panel. Choose true if your Zen Cart is
running on a Unix/Linux/Mac operating system. Choose false if your Zen Cart is running on a Windows
operating system. Click update to save your changes."...

"Remember to make sure the <zc-home>/pub directory on your server has the correct file permission (i.e. chmod
755) if you have specified true for the Download by Redirect field and your Zen Cart store is hosted on a
##__

I'm running on a Linux operating system.

Does anybody know which instruction is correct? Getting this wrong could have untold consequences. In this case I continue to get the same download error in both cases regardless of the file permission setting of 755 or 777.

Yourvirtualworld:

I have noticed that when we click on the download option the URL is re-directing to 'www.xxxxxxxx.xxx/pub/.zzychircojejjs/xxxxxxxxxxxxx.zip' (my masking for this forum) and displays the Bad Request error. This is because of the special character in the URL that is folder name with dot '.zzychircojejjs'.
No, it's not a result of the "dot" in the foldername. That dot is intentional. dot-prefixed files and folders are treated as "hidden" by linux. This is part of delivering your files in a secure manner that minimizes likelihood of theft.

The "dot-prefix" is not your problem.

Or, if it is, then it's extremely unique to you and your hosting company's server configuration. Tens of thousands before you have had no problem with the dot-prefix.

My ISP has looked into it further and their reply is:

Hello,

Thank you for your patience.

I have checked your issue regarding unable to download the file 'SantaSample.zip' and it appears to be issue with your application. Currently the URL http://www.xxxxxxx.xxx/index.php?main_page=download&order=9&id=7 produces a Corrupted Content Error. Unfortunately we wont be able to assist you further regarding the issue. I would suggest you to contact your application vendor regarding the issue.

If you have any further questions,please update the Support Console.

Sincerely,

Marco
Level 3 Technical Support "

Nobody to date appears willing to take ownership of this problem (ISP, Zen Cart, Template Developer, Microsoft, Google Chrome). The example file in question to be downloaded through Zen Cart has been confirmed to not be corrupted and it has been set up correctly for download. It can be downloaded directly with no problems from my ISP but not through Zen Cart...

Where can I turn to now?

Yourvirtualworld:

Nobody to date appears willing to take ownership of this problem (ISP, Zen Cart, Template Developer, Microsoft, Google Chrome).

A quick Google search for
net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENG

Produces lots of results, for a number of different eCommerce sites, all of them suggesting that this is a Google Chrome issue.

Not much more that we can do or say to help really.. It is not a zencart problem.

Cheers
Rod

This appears to go beyond Chrome. The verbiage is Chrome's but the issue of being unable to download is at the root. My ISP keeps telling me that it's somebody else's problem but all of those somebody elses point back to the ISP. ISP will likely have to spend time and money researching and fixing the issue and it seems like they haven't wanted to. A third party posted this:

Response posted at http://www.google.com/support/forum/p/Chrome/thread?tid=76c837e5e6fddb20&hl=en> “A customer running my download software reported this error and this is what I found

Chrome shows this error: "Error 346 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH): Unknown error."

Firefox 7 shows this error: "Corrupted Content Error".

IE 8 does the download, but using Fiddler I saw the error "Content-Length mismatch: Response header indicated 625,804 bytes, but server sent 627,238 bytes.

Googling ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH, I found this:
https://www.varnish-cache.org/trac/ticket/801

• which says that the error relates to multiple Content-Length headers (and now Chrome's error message suddenly makes sense)

So I looked at the headers, and sure enough, the Varnish caching software is installed on the server, and there are two (different) Content-Length headers, one from my download application, and another one, presumably generated by Varnish:

HTTP/1.1 200 OK
Date: Fri, 28 Oct 2011 09:45:31 GMT
Content-Type: application/zip
Connection: close
Server: Nginx / Varnish
X-Powered-By: PHP/5.2.17
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Cache-Control: pre-check=0, post-check=0, max-age=0
Pragma: no-cache
Content-Description: File Transfer
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Content-Length: 625804
Content-Range: bytes 0-625804/625804
Content-Disposition: attachment; filename="blah.zip"
Content-Transfer-Encoding: binary
Content-Length: 670673

My job is done, I told my customer to get his web server provider to fix it - presumably the solution is to upgrade Varnish.

Chrome could do a better job of reporting this. Maybe it could just ignore the second Content-Length header?”

My ISP spent a good while looking at the issue. It appears their practice of running their site counters the recommendations issued by Zen Cart to its users. He states:

"Hello,

Thank you for contacting us.

In Zen cart you have selected the option to download the file by Redirect method (Admin->Configuration->Attribute Settings). In this method, the application will create a symlink to the actual file inside a temporary hidden directory ( a hidden directory is the one which starts with a . (dot)).

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

You can either change the download method to 'without Redirect' which is not recommended as this link could be shared by others or he needs to modify the application code/settings such that the temporary directory created should not contain the . (dot) at the beginning of its name.

If you have any further questions, please update the Support Console.

Sincerely,

Sidney Kent
Technical Specialist "
The Zen Cart manual says:
Edit the Download by Redirect field to bring up the following side-panel. Choose true if your Zen Cart is
running on a Unix/Linux/Mac operating system. Choose false if your Zen Cart is running on a Windows
operating system. Click update to save your changes....Remember to make sure the <zc-home>/pub directory on your server has the correct file permission (i.e. chmod 755) if you have specified true for the Download by Redirect field and your Zen Cart store is hosted on a Unix/Linux operating system.

I guess that will mean that my products cannot remain hidden from non-purchasing users if I understand his recommendation and its implications. Following his second recommendation, does anybody know what code to change so as to not put the . dot in the temporary directory created within /pub? Any words or recommendations from a Zen Cart guru will be welcome. (Ajeh, DrByte...)

Yourvirtualworld:

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

I wonder what they mean by "Unfortunately"? If they did it and regret it, then why not put it back as it was?
Perhaps it was unfortunate in that it was unlucky it was done? What does luck have to do with it? Someone tossed a coin?

Sorry, it gripes me at the things done in the name of "security", doubly so when told it is "unfortunate", and quadruply so when the actions taken have no sound basis.

Yourvirtualworld:

I guess that will mean that my products cannot remain hidden from non-purchasing users if I understand his recommendation and its implications
.

Correct. (but remember, this is somehow supposed to increase security) <cough, cough>

Cheers
Rod

I found the answer to changing the code to modify the dot directory creation here: http://www.zen-cart.com/forum/showpost.php?p=269833&postcount=7

I implemented the "fix" but sadly, it did not work. Zen Cart is still creating the hidden "dot" directory. Maybe there is other code within ZC that is overriding this modification. I wrote to my ISP the following:

Thank you Sidney for your advice. In this case I followed your second suggestion by removing the dot per these instructions available on the Zen Cart website:
"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: Problem resolved. I removed the dot and everything now works. I assume the downloaded file is moved into that gibberish folder "during" the download, and is then removed...because I always see that temporary folder empty.
A "pointer" to the real download file is placed in that folder. Called a symlink.
During the "next" download, the links are cleaned up so things are kept clean and secure as much as possible."

Sidney, I edited this file to remove the dot to read

function zen_random_name()
{
$letters = 'abcdefghijklmnopqrstuvwxyz';
$dirname = '';

Unfortunately it had no effect as the randomly created directories within /pub continue to be created. Thus, I continue to receive the same error:

Duplicate headers received from server
The response from the server contained duplicate headers. This problem is generally the result of a misconfigured website or proxy. Only the website or proxy administrator can fix this issue.
Error 346 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH): Multiple distinct Content-Length headers received. This is disallowed to protect against HTTP response splitting attacks.

Sidney, is it possible to permit accessing of files inside a hidden directory on my site while continuing to enforce it on other sites on the server? I'm running an ecommerce store and was given the option to install Zen Cart from among server other choices by your company. All of the scripts were put in place by your company to make installation easy and quick yet your company has deliberately set up a server environment that has, in a way, severely crippled the ability of Zen Cart to operate as designed. I need to mention that there are numerous other ISP companies that DO host Zen Cart stores without crippling their functionality in any way because these sites are ecommerce friendly and fully understand the needs of ecommerce businesses. I am appealing that this ban on allowing files inside a hidden directory on your servers be lifted.

I await your prompt reply. Each passing day is a day for me without being able to conduct business.

Thank You

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

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.

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.

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

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.
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.
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
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.

The mods were correct. Something else is going on.

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.

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/commit/d494c8a74865b59999ce29e849c710705d001d76

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.

Yourvirtualworld:

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.