XF 1.5 Avatar trouble...

OK, I have a weird problem I can't seem to find the cause for.

Avatars uploaded as .gif are not displaying in IE, but fine in any other browser. The avatar itself shows fine in IE when viewed with just the link for the avatar, but not when it should be displayed in the forum.

Here's my test post: https://www.windowsbbs.com/threads/avatar-test.110833/

The avatar doesn't show in IE (in my case I tried IE11/Win10 and IE8/WinXP).

When you go to the direct url's for the avatar it shows fine in IE:

So I'm running a RHEL 6 server with php 5.3.3 and GD 2.0.34. The issue was happening with APC cache (3.1.13) and is also happening after switching to XCache (3.0.4)..


XenForo developer
Staff member
Something appears to be adding a X-Content-Type-Options: nosniff header to these requests. This would be something coming from a configuration within the webserver itself, presumably.
I've been testing for the last 4 hours... silly thing is that on my test install (which is on a non https domain) there is no problem. I switched off everything under the sun, so both domains had the same settings...

I see that there is this "X-Content-Type-Options: nosniff" on the secure site

This header prevents "mime" based attacks. This header prevents Internet Explorer from MIME-sniffing a response away from the declared content-type as the header instructs the browser not to override the response content type. With the nosniff option, if the server says the content is text/html, the browser will render it as text/html.
Now to figure out where it is being set...
This is nuts! I'm finding answers on how to enable it, but how on earth do you disable this?

Nothing in any of the Apache files... a text search for "nosniff" on the server also negative... soo file checking. It is set in library/XenForo/ProxyOutput.php

That explains it... I'm using the image proxy on the SSL site of things. So now let me get rid of it and see if that's the problem...


XenForo developer
Staff member
Avatars aren't served through the XenForo files -- they're served directly by the web server. The proxy output won't be causing it (and the usage of the header there is expected).

That's really my only clear guess as to the cause, as this isn't a standard header. I would say there might be an .htaccess file somewhere adding it.
Nope, still no go...

curl -I -H 'X-Content-Type-Options: nosniff' https://www.windowsbbs.com/data/avatars/m/54/54046.jpg

HTTP/1.1 200 OK
Date: Fri, 20 May 2016 11:36:17 GMT
Server: Apache
Last-Modified: Fri, 20 May 2016 11:33:32 GMT
Accept-Ranges: bytes
Content-Length: 2680
Cache-Control: max-age=2592000, public
Expires: Sun, 19 Jun 2016 11:36:17 GMT
Vary: User-Agent
Content-Type: image/jpeg
Weird. curl doesn't show it, but it is still showing as a response header in console view. I did search the whole www space for "nosniff", and it only show here:

library/XenForo/ViewAdmin/Attachment/View.php: $this->_response->setHeader('X-Content-Type-Options', 'nosniff');
library/XenForo/ViewAdmin/Log/EmailBounceView.php: $this->_response->setHeader('X-Content-Type-Options', 'nosniff');
library/XenForo/ViewAdmin/Log/ImageProxyView.php: $this->_response->setHeader('X-Content-Type-Options', 'nosniff');
library/XenForo/ProxyOutput.php: $this->_response->setHeader('X-Content-Type-Options', 'nosniff');
library/XenForo/ViewPublic/ImageProxy/View.php: $this->_response->setHeader('X-Content-Type-Options', 'nosniff');
library/XenForo/ViewPublic/Attachment/View.php: $this->_response->setHeader('X-Content-Type-Options', 'nosniff');
attachment.php:header('X-Content-Type-Options: nosniff');

nothing is found in Apache config files for "nosniff"... I've been looking into this for the past 8-10 hours the last 2 days, not a good place to be...
Yes, but only on the 'normal' images... (not on avatars) when I switched it off, there was no difference. Tested again, but that header is still being set :(

Need to get some lunch...


XenForo developer
Staff member
What do you mean by "normal" images? I didn't mean the image proxy that XF provides. I meant a reverse proxy that sits between your server and the end user (an example would be CloudFlare, though you're not using that as far as I can see).
I'm running a reverse proxy (so no, not visible for users) that serves images from a lighttpd server. But not serving anything from the /data or /internal_date folders.


XenForo developer
Staff member
Note that I do see this when requesting via curl:
$ curl -I https://www.windowsbbs.com/data/avatars/m/54/54046.jpg
HTTP/1.1 200 OK
Date: Fri, 20 May 2016 15:10:13 GMT
Server: Apache
Content-Length: 2680
Last-Modified: Fri, 20 May 2016 11:33:32 GMT
Accept-Ranges: bytes
Cache-Control: max-age=2592000, public
Expires: Sun, 19 Jun 2016 15:08:57 GMT
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1;mode=block
Vary: User-Agent
Etag: W/"PSA-FHtiUhZNkW"
X-Content-Type-Options: nosniff
Content-Type: image/jpeg
It also adds a few other elements.

Are you running mod_pagespeed? The "PSA" part of the Etag makes me think that, so that could be adding these headers.
Yea, I'm running mod_pagespeed, but that's also running on my test forum where I have no problems. I'll switch it off for a test...
WOW... mod pagespeed is the problem... that's weird. It only affects the secure site. Test forum running on normal http site. I had switched off all default filters and was just running with:

ModPagespeedRewriteLevel PassThrough

ModPagespeedEnableFilters combine_css,combine_javascript
ModPagespeedEnableFilters collapse_whitespace
ModPagespeedEnableFilters remove_comments

I'll see if I can figure out if one of these is the problem...
ModPagespeedEnableFilters remove_comments is the problem. That filter adds the X-Content-Type-Options: nosniff tag. I'll have to find out how/from where...

It's strange to me that it doesn't set that same tag when not on an SSL site!

Thanks for helping me troubleshoot this.
Actually, after some more testing I cant seem to pin it down to a specific filter. I would probably have to disable all caches... too much work, I'll just switch it off completely.