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

[Yourvirtualworld]

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

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!

[Yourvirtualworld]

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.

[DrByte]

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.

[Yourvirtualworld]

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?mai...d&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?

[RodG]

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

[Yourvirtualworld]

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/...e6fddb20&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?”

[Yourvirtualworld]

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

[RodG]

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.

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

[Yourvirtualworld]

I found the answer to changing the code to modify the dot directory creation here: http://www.zen-cart.com/forum/showpo...33&postcount=7

[Yourvirtualworld]

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