1. 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 ?

Discussion in 'XenForo Suggestions' started by eva2000, Aug 29, 2014.

  1. eva2000

    eva2000 Well-Known Member

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


    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

    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

    Last edited: Aug 30, 2014
    Divvens, we_are_borg, Alfa1 and 38 others like this.
  2. Floren

    Floren Well-Known Member

    Looking forward to have this implemented. :)
    RoldanLT likes this.
  3. RoldanLT

    RoldanLT Well-Known Member

    /proxy/ A must have for us using ngx_pagespeed. :)

    But having proxy timeout adjustable within admin.php is a must have for everyone.

    Having this as an option on admin would be great:
    Last edited: Aug 30, 2014
    Floren, eva2000 and DeltaHF like this.
  4. DeltaHF

    DeltaHF Well-Known Member

    I have also reduced the timeout in ImageProxy.php and it has greatly improved my site's performance when the image proxy attempts to access images from slow origin servers. (y)
    eva2000 and RoldanLT like this.
  5. ekool

    ekool Member

    Add my vote to getting this taken care of.
  6. Andy.N

    Andy.N Well-Known Member

    Mine too
  7. eberkund

    eberkund Active Member

    What application is that you are using to make those graphs?
  8. DeltaHF

    DeltaHF Well-Known Member

    Those graphs are from NewRelic. I use it, too, and it's great.
  9. eberkund

    eberkund Active Member

  10. DeltaHF

    DeltaHF Well-Known Member

    Yep, that's the page for their "Server Monitoring" service, which is great, but their application monitoring provides the more granular data like what you see above.

    eberkund likes this.
  11. digitalpoint

    digitalpoint Well-Known Member

    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:

    Both output this:

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


    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).
    Eagle, Mert, Amin Sabet and 6 others like this.
  12. digitalpoint

    digitalpoint Well-Known Member

    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://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.
    Eagle, Mert, semprot and 3 others like this.
  13. Mr. Goodie2Shoes

    Mr. Goodie2Shoes Well-Known Member

    I have created a nice little add-on for gfnlabs that serves CSS like this:
    <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" />
    eva2000 likes this.
  14. DeltaHF

    DeltaHF Well-Known Member

    I just used CloudFlare page rules to "cache everything" from www.example.com/forum/proxy.php?image=* and checking the headers confirmed it worked great; it offloaded more than 70% of my bandwidth to CF and reduced CPU usage by 15-20%.

    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.
  15. digitalpoint

    digitalpoint Well-Known Member

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

  16. DeltaHF

    DeltaHF Well-Known Member

    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.
  17. digitalpoint

    digitalpoint Well-Known Member

    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.
  18. Fred.

    Fred. Well-Known Member

    So many good suggestions here. :)
    Looking forward to have this implemented. :cool:
  19. Xon

    Xon Well-Known Member

    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 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.
    DeltaHF and eva2000 like this.
  20. RoldanLT

    RoldanLT Well-Known Member

    Same here :)
    Mine also.

Share This Page