XF 2.0 Image proxy randomizing images

Lukas W.

Formerly katsulynx
#1
After moving to my new server, I missed setting the directory permission for data and internal_data to writeable for a few hours. Some of my members posted some images meanwhile and ever since then, the image proxy seems to be completely broken. Whenever some images are requested, he seems to be randomly drawing some out of his proxy cache. Every time one reloads the page, different images are loaded. It's really weird... (Video) Are there any tools I can use or measures I can take to correct these issues?
 

Mike

XenForo developer
Staff member
#2
To confirm, is this just happening to one user? You mention "his proxy cache" so I'm not sure. If so, that's certainly an issue with the proxy on his end.

However, if you have a reverse proxy involved, that could be the cause here, notably if it's disregarding the query string in terms of considering what to return from the cache.
 

Lukas W.

Formerly katsulynx
#3
To confirm, is this just happening to one user? You mention "his proxy cache" so I'm not sure.
Ah no, by "him" I was referring to the XF image proxy. It's happening to my users and me as well. If I open up the image proxy log on the backend, it's the same phenomenon. I disabled the proxy for a few minutes and the images went through (as expected) without randomization, after enabling it again, it stayed like that for another 5 minutes, then it started to randomly shuffle them again.

However, if you have a reverse proxy involved, that could be the cause here, notably if it's disregarding the query string in terms of considering what to return from the cache.
How could I check that? I've installed the server software myself, so unless there is some default caching that comes with apache2 or php7.0, there should be none.

Also, if I open the images directly, the correct image is loaded.
 

Mike

XenForo developer
Staff member
#6
While I'm not 100% positive, a lot of testing seems to point to this likely being a Chrome/Chromium bug (thus in Opera too). It's possible it may also depend on server response specifics. It doesn't appear to be something we can really workaround.

It isn't something that I could reproduce with Chrome Beta (63), so hopefully it will resolve itself in the coming weeks.
 

Lukas W.

Formerly katsulynx
#7
@Mike My chrome just updated to Version 63.0.3239.84 (Official Build) (64-bit), so I gave this another try and turned on the image proxy once again. However, the issue is still present and images keep getting randomized.
 

Mike

XenForo developer
Staff member
#8
I've replied to your conversation about this. I can reproduce this now in the Chrome dev channel (64) though not currently in canary (65), so it's very possible that the relevant changes are being deferred. If possible, the next step may be to produce a reduced test case that we can report to them.
 

Lukas W.

Formerly katsulynx
#9
@Mike, as adviced, I've posted the images in question here, but the image proxy seems to work. I've tried to refresh a couple of dozen times, but they were never shuffled randomly.
 

Fethi.dz

Active member
#10
I had the same problem above, many users who use chrome/android devices complained about pictures take random places when I enable the XF Proxy.

So I did some search and found this .htaccess code which solved my problem.

Code:
<IfModule mod_deflate.c>
        # Insert filter
        SetOutputFilter DEFLATE

        # Netscape 4.x has some problems...
        BrowserMatch ^Mozilla/4 gzip-only-text/html

        # Netscape 4.06-4.08 have some more problems
        BrowserMatch ^Mozilla/4\.0[678] no-gzip

        # MSIE masquerades as Netscape, but it is fine
        # BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

        # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
        # the above regex won't work. You can use the following
        # workaround to get the desired effect:
        BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

        # Don't compress images
        SetEnvIfNoCase Request_URI \
        \.(?:gif|jpe?g|png)$ no-gzip dont-vary

        # Make sure proxies don't deliver the wrong content
        Header append Vary User-Agent env=!dont-vary
</IfModule>
 

Lukas W.

Formerly katsulynx
#11
As of Chrome 66 this is unfortunately still an issue that is preventing me from using the image proxy. Any recommended workaround @Mike ? I don't understand what the above posted .htaccess config does, so even if it wouldn't trigger a missconfiguration error on my server, I wouldn't want to use it.
 

Chris D

XenForo developer
Staff member
#15
I know what you're saying, but I'm not sure there's much we can do about it at this point.

It is happening to very few people, so it would suggest a server configuration issue somewhere more than anything. It doesn't happen here, for example, and we've not had to do anything here to make sure it doesn't happen.
 

Lukas W.

Formerly katsulynx
#16
Anything we can do to investigate in this? My servers running basic, out of the box configurations, nothing special I'd be aware of. I can provide full ssh and ftp access if it helps.
 

Fethi.dz

Active member
#17
To update, I use the following line ONLY in my .htaccess to solve the problem:

Code:
<IfModule mod_deflate.c>
    # Make sure proxies don't deliver the wrong content
    Header append Vary User-Agent env=!dont-vary
</IfModule>
 

Lukas W.

Formerly katsulynx
#19
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at webmaster@localhost to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.
The error from the error log:
Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration, referer: [...]
Mod-deflate is active as far as I can tell:
# apachectl -t -D DUMP_MODULES |grep def
deflate_module (shared)

Attachments are affected too it seems.
 
Last edited:
Top