• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Removing .php extension from proxy.php images ?

eva2000

Well-known member
#1
Sort of related to https://xenforo.com/community/threa...oxy-to-slow-origin-servers.81774/#post-818153

Suggestion:

For Xenforo default image proxy url to be customised without the .php extension i.e. /proxy/ instead of /proxy.php similar to Digitalpoint's proxy image addon which serves proxied images from /proxy/image https://marketplace.digitalpoint.com/image-proxy.2306/item and maybe also make the proxy timeout adjustable within admin.php

Why
  1. Seems to alleviate issues reported at https://xenforo.com/community/threads/how-sensitive-is-the-image-proxy-to-slow-origin-servers.81774/ for broken images
  2. I use Nginx with ngx_pagespeed module for better performance and pagespeed can't optimise proxy.php served images and auto convert to webp format using Xenforo default proxy image feature. While pagespeed can if the proxied images were served via /proxy/image without the .php extension - see benefits at https://community.centminmod.com/threads/benefits-of-ngx_pagespeed.1032/.
broken images served via Xenforo default image proxy

xenforo_proxy_image_hog_process_newrelic_01.png
xenforo_proxy_image_hog_process_newrelic_02.png
xenforo_proxy_image_hog_process_newrelic_03.png
 
Last edited:

digitalpoint

Well-known member
#11
I know it's old but I just ran across this... there are additional reasons to not use the .php extension for the serving of proxy images, although if caching systems were smarter and looked at the HTTP headers, it might be moot. But right now most caching systems rely on the URI extension rather than the content type headers.

I ended up adding ".png" extension to the image proxy I built, even though the extension is ignored by XenForo's routing system.

For example these two URLs are identical as far as XenForo is concerned:
https://forums.digitalpoint.com/proxy/Rx0STmZmm7qNyyA=/thumb.png
https://forums.digitalpoint.com/proxy/Rx0STmZmm7qNyyA=/thumb

Both output this:


But if you look at the underlying HTTP headers from each request:

https://tools.digitalpoint.com/headers?url=https://forums.digitalpoint.com/proxy/Rx0STmZmm7qNyyA%3D/thumb.png
https://tools.digitalpoint.com/headers?url=https://forums.digitalpoint.com/proxy/Rx0STmZmm7qNyyA%3D/thumb

You can see that CloudFlare is able to serve up the request with the .png extension from cache in whatever CloudFlare data center is closest to the user (better performance when the user is able to get the image from a CloudFlare data center cache).
 

digitalpoint

Well-known member
#12
Oh, and while we are at it, let's make CSS files not served up from css.php files either. Same sort of caching advantages can happen if you use something like css.css as the script.

I've done that on my site already, but it requires a little hacking on the PHP source files since there's no way to intercept the css.php prefix of the CSS URLs without just changing it in the source.

But same general idea... my XF CSS is this: https://x.dpstatic.com/css.css?css=xenforo,form,public&style=1&dir=LTR&d=1424195706

Which again allows it to be treated as static content by CloudFlare and served up from the closest data center:

https://tools.digitalpoint.com/head...foro,form,public&style=1&dir=LTR&d=1424195706

https://x.dpstatic.com/css.php?css=xenforo,form,public&style=1&dir=LTR&d=1424195706 is the same thing ultimately, but not cacheable by CloudFlare due to .php extension.
 
#13
I have created a nice little add-on for gfnlabs that serves CSS like this:
HTML:
<link rel="https://cache.gfnstatic.com/assets/Bgz1u-i0hyc3QIT6.css?_v=1423413650" />
<link rel="https://cache.gfnstatic.com/assets/nTyv7ZsPUcxT.css?_v=1423413650" />
<link rel="https://cache.gfnstatic.com/assets/l8vojbJN.css?_v=1423413650" />
:D
 

digitalpoint

Well-known member
#15
Unfortunately, I had to ditch CF due to reliability issues (users reporting bogus 502/504 errors daily, no help from CF support). Not sure how you guys are able to use it.
It's worked great for me... I know some people have had issues with it, but I think mostly it's people that don't have total control over their servers/network. For example I've seen people have issues where their server has some anti-DDoS mitigation system in place and they don't whitelist CloudFlare's IPs, so that keeps kicking in for them since ALL requests at the network level are coming from CloudFlare IPs.

The other thing I've seen people do is try to enable crazy beta features like Rocket Loader and then they wonder why their site is messed up when Rocket Loader is going in and mucking with the site's JavaScript. lol Maybe useful for basic sites, but not for complex ones like XF.

I've been nothing but happy with CloudFlare myself... 40M requests in the last week that never had to come to my servers (static content served direct from CloudFlare local data center caches).

upload_2015-2-17_12-1-29.png
 

DeltaHF

Well-known member
#16
Are you on a premium or free plan? I only used the free service to try it out, after the poor experience I decided to drop it. My server's just a plain Centminmod box at Linode...whitelisted IPs and all but the most basic CF features disabled, but I still had people reporting intermittent problems in different regions.
 

digitalpoint

Well-known member
#17
Are you on a premium or free plan? I only used the free service to try it out, after the poor experience I decided to drop it. My server's just a plain Centminmod box at Linode...whitelisted IPs and all but the most basic CF features disabled, but I still had people reporting intermittent problems in different regions.
On a paid plan, but the free ones work fine for me as well... only reason I'm on paid plan is for the better SSL certificate.
 

Xon

Well-known member
#19
Oh, and while we are at it, let's make CSS files not served up from css.php files either. Same sort of caching advantages can happen if you use something like css.css as the script.
Thanks for the heads up with this. I've setup a cloudflare page rule to force caching of css.php for the moment, and it looks quite handy for reducing the number of requests hitting the php workers.

I've done that on my site already, but it requires a little hacking on the PHP source files since there's no way to intercept the css.php prefix of the CSS URLs without just changing it in the source.
I've nearly finished an addon which will do this. You need a post render template hook on the PAGE_CONTAINER template (and possible a few others). This lets you intercept the magic marker used to inject xen:require output.

I need to write some bits so the installer will automatically generate template modifications to patch any template directly linking to css.php and if they have the marker for xen:require used anywhere. But it hasn't been a massive issue over getting some other features working.