attachment.php header problem

[JamesAB]

This isn't for a modification. This is a problem I'm having with the stock VB 3.8.7 code.

I have attachments stored in the file system and I'm not using the lightbox feature. When a user clicks on a photo it opens by itself. However, if the user tries to save the photo, the filename is always "attachment.php" and not the actual file name.

This has been a problem in Internet Explorer for quite a while. The only workaround I knew of was to view the forum in "compatibility" mode in IE.

Now this has also become a problem in Firefox 39. Previous versions of Firefox didn't have this issue. When you tried to save a photo in Firefox 38, the correct file name was displayed in the "Save As" dialog box.

I believe this is the part of attachment.php that is causing the problem:

// Opera and IE have not a clue about this, mozilla puts on incorrect extensions.
if (is_browser('mozilla'))
{
	$filename = "filename*=" . $filename_charset . "''" . rawurlencode($filename);
	//$filename = "filename==?$stylevar[charset]?B?" . base64_encode($filename) . "?=";
}
else
{
	// other browsers seem to want names in UTF-8
	if ($filename_charset != 'utf-8' AND function_exists('iconv'))
	{
		$filename_conv = iconv($filename_charset, 'UTF-8//IGNORE', $filename);
		if ($filename_conv !== false)
		{
			$filename = $filename_conv;
		}
	}

	if (is_browser('opera') OR is_browser('konqueror') OR is_browser('safari'))
	{
		// Opera / Konqueror does not support encoded file names
		$filename = 'filename="' . str_replace('"', '', $filename) . '"';
	}
	else
	{
		// encode the filename to stay within spec
		$filename = 'filename="' . rawurlencode($filename) . '"';
	}
}

if (in_array($extension, array('jpg', 'jpe', 'jpeg', 'gif', 'png')))
{
	header("Content-disposition: inline; $filename");
	header('Content-transfer-encoding: binary');
}
else
{
	// force files to be downloaded because of a possible XSS issue in IE
	header("Content-disposition: attachment; $filename");
}

I've tried changing the Content-disposition: by changing the $filename variable and have found combinations that work in IE so that the correct filename is displayed in the "Save As" box instead of attachment.php.

I haven't found any fix that will make this code work correctly with Firefox 39.

Any ideas?

All help is appreciated.

Thanks,
James

[JamesAB]

You can see this problem right here on vbulletin.org

Just click on on any image attachment that was uploaded here and then try to save the attachment. Rather than seeing the image's actual file name, you'll get "attachment.php" as the file name in Internet Explorer (unless you have already set your browser to view vbulletin.org in "compatibility" mode) or while using Firefox 39. Earlier versions of Firefox (38 and below) work as you would expect and you see the attachment's real file name in the "Save As" dialog box.

This is an annoying problem for a forum with lots of image attachments that people want to save to their local computers, so I hope someone can share some insight on how to fix this.

Thanks for your help,
James

[JamesAB]

Does anyone have any ideas or clues how to fix this issue?

It's bizarre. In Firefox 39, if you open a photo attachment and right-click over the image and choose "Save Image as..." you get attachment.php as the file name. This is the wrong/unexpected behavior.

In Firefox 39, if you open a photo attachment and right-click outside the image area (not directly over the photo) and choose "Save Page As..." you get the correct file name and extension.

This is just backward. You would think the page might be called attachment.php since that's the script serving the image, but the actual image should save with the correct file name.

It really doesn't matter is it's a bug in Firefox or a bug in vBulletin, either way I still need to find a work around.

Thanks for any help or suggestions.

[Lynne]

I just tried it with Firefox 39 and you are correct. However, I'm not sure what the fix for it is.

[Stratis]

<a href="https://vborg.vbsupport.ru/showthread.php?t=318860" target="_blank">https://vborg.vbsupport.ru/showthread.php?t=318860</a>
Same problem, I had it with IE11, Any way all problems are fixed with vb4.2.2 - 3
But for me for many reasons I will don't make the update yet.

I think that fix is with the php version

[JamesAB]

Originally Posted by Lynne

I just tried it with Firefox 39 and you are correct. However, I'm not sure what the fix for it is.

Lynne,
Can you do me a favor and confirm that this isn't a problem with vB4 and/or vB5 when browsing with Firefox 39?

Originally Posted by Stratis

https://vborg.vbsupport.ru/showthread.php?t=318860
Same problem, I had it with IE11, Any way all problems are fixed with vb4.2.2 - 3
But for me for many reasons I will don't make the update yet.

I think that fix is with the php version

Thanks for the tip Stratis. I'll try to take a look at what is different in the code in VB4.

[TheLastSuperman]

Firefox 40 here but I adjusted my about:config and have done many warranty voiding things (I can run plugins and themes not marked as compatible and other novel things woohoo) so I can't even begin to offer suggestions other than this one:

Seems this is a known issue in IE and certain sites (depending on how their server/php is setup but does not mean its wrong) see post #21 here - http://blenderartists.org/forum/show...p-files/page2&

Make sure to edit your settings in IE11;
> Menu > Tools > Compatability View settings > Add vbulletin.org to the list, should be fixed now .

Edit: No offense intended however most of you are actually searching for this info right? I typed in "attachments saving as .php files?" into Google and BAM there it was in the top three search results... I'm going to just go now .

Edit #2: Also so you know, if you ever visit a site and attempt to download an attachment/image or simply click on a link and it opens the save dialog box... it can be several things... PHP Version on said site has changed / recent .htaccess change / usually some type of configuation OR setup change recently made so if you're ever working on your site then it acts a fool simply revert the recent change made and viola, should return to normal.

[JamesAB]

Thanks for the info TheLastSuperman.

However, in this case it is a software issue not a server issue. I'm aware of the compatibility mode work around, but that isn't a very elegant solution. I don't like idea of telling thousands of members to change their browser settings because we can't get our code working right. I want to fix things properly on our end and that means dealing with all the quirks in different browsers.

I don't have a fix for Firefox 39 yet, but this simple change seems to make the file names appear correctly in Internet Explorer without having to enable compatibility mode.

Look for this in attachment.php:

// Opera and IE have not a clue about this, mozilla puts on incorrect extensions.
if (is_browser('mozilla'))
{
	$filename = "filename*=" . $filename_charset . "''" . rawurlencode($filename);
	//$filename = "filename==?$stylevar[charset]?B?" . base64_encode($filename) . "?=";
}

And change it to this:

// Opera and IE have not a clue about this, mozilla puts on incorrect extensions.
if (is_browser('mozilla'))
{
	//$filename = "filename*=" . $filename_charset . "''" . rawurlencode($filename);
	//$filename = "filename==?$stylevar[charset]?B?" . base64_encode($filename) . "?=";
	$filename = 'filename="' . str_replace('"', '', $filename) . '"';    //This works in IE
}

I'm only running this on my test server so far and I'm not calling this a permanent solution until I find out (and fix) why Firefox stopped handling file names as expected.

Thanks,
James

[JamesAB]

As far as Firefox is concerned, it appears that this was a bug in Firefox 39..
I just upgraded to Firefox 40.0.2 and the issue no longer exists.

I'll try testing my IE fix on a live forum next.

Thanks,
James