MyBB Community Forums

Full Version: query strings on avatars
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
(2015-10-09, 06:33 AM)andrewjs18 Wrote: [ -> ]@Euan T..have you tried that htaccess code?

OOps, sorry not yet. I'll give it a go this evening and see if I can work it out. .htaccess isn't my strong suit unfortunately.
(2015-10-04, 11:45 PM)andrewjs18 Wrote: [ -> ]I display avatars on my forum index and forum display so it'd be ideal if they got cached from the cdn, but they're not because of the query strings.

is there a way to optimize this?

Your given link is not open at my side ?
(2015-10-10, 06:34 AM)bradyvictor77 Wrote: [ -> ]
(2015-10-04, 11:45 PM)andrewjs18 Wrote: [ -> ]I display avatars on my forum index and forum display so it'd be ideal if they got cached from the cdn, but they're not because of the query strings.

is there a way to optimize this?

Your given link is not open at my side ?

if you're in China, you'll likely get blocked. other than that, the site should be accessible as I'm using it right now.
Other possible solution maybe, since MyBB uses a proper way for displaying avatar, using a centralized format_avatar function, so change the function (could be adding one setting whether the admin wants to use the query string or not).

	if(!$avatar)
	{
		// Default avatar
		$avatar = $mybb->settings['useravatar'];
		$dimensions = $mybb->settings['useravatardims'];
	}
	else
	{
		if($mybb->settings['avatar_query_string'] == 0)
		{
			$avatar = substr($avatar,0,-20);
		}
	}
(2015-10-12, 03:42 PM)RateU Wrote: [ -> ]Other possible solution maybe, since MyBB uses a proper way for displaying avatar, using a centralized format_avatar function, so change the function (could be adding one setting whether the admin wants to use the query string or not).

	if(!$avatar)
	{
		// Default avatar
		$avatar = $mybb->settings['useravatar'];
		$dimensions = $mybb->settings['useravatardims'];
	}
	else
	{
		if($mybb->settings['avatar_query_string'] == 0)
		{
			$avatar = substr($avatar,0,-20);
		}
	}

This can be solved by using the .htaccess I provided earlier. Since the query string is the time when the avatar was last updated (I misunderstood this unfortunately) the .htaccess alone will ensure that the image is cached, since the query string doesn't change until the avatar is updated. Removing the query string doesn't solve the cache issue nor is it required to solve it, since the query string does not change until the avatar itself changes.
@SentoWeb the problem Andrew wants to solve isn't the cache issue, it's the fact that Incapsula is apparently broken and will not serve resources with query arguments from their CDN system.
(2015-10-12, 05:50 PM)Euan T Wrote: [ -> ]@SentoWeb the problem Andrew wants to solve isn't the cache issue, it's the fact that Incapsula is apparently broken and will not serve resources with query arguments from their CDN system.

I don't think this is confined to incapsula though. I think a lot of proxy CDNs might be like this.
(2015-10-13, 07:23 AM)andrewjs18 Wrote: [ -> ]
(2015-10-12, 05:50 PM)Euan T Wrote: [ -> ]@SentoWeb the problem Andrew wants to solve isn't the cache issue, it's the fact that Incapsula is apparently broken and will not serve resources with query arguments from their CDN system.

I don't think this is confined to incapsula though. I think a lot of proxy CDNs might be like this.

Is Incapsula:
a) not sending cache headers to the client (browser) in case the request url contains a query string but respects your cache headers and doesn't query your server until the cache must be reset; treats the content as cached dynamic content

b) not sending cache headers to the client (browser) in case the request url contains a query string and also doesn't respect your cache headers so every request for these resources hits the server; treats the content as dynamic content which can't be cached

There could be workarounds for either scenarios. If your website generates enough revenue I would switch to a vanilla pull CDN. You not only have more control over the data, but they are generally faster. I see "proxy CDNs" as 3 kilo Swiss knives, in theory they cover all your needs but they don't excel in anything, including the CDN functionality.
(2015-10-13, 08:32 AM)SentoWeb Wrote: [ -> ]
(2015-10-13, 07:23 AM)andrewjs18 Wrote: [ -> ]
(2015-10-12, 05:50 PM)Euan T Wrote: [ -> ]@SentoWeb the problem Andrew wants to solve isn't the cache issue, it's the fact that Incapsula is apparently broken and will not serve resources with query arguments from their CDN system.

I don't think this is confined to incapsula though.  I think a lot of proxy CDNs might be like this.

Is Incapsula:
a) not sending cache headers to the client (browser) in case the request url contains a query string but respects your cache headers and doesn't query your server until the cache must be reset; treats the content as cached dynamic content

b) not sending cache headers to the client (browser) in case the request url contains a query string and also doesn't respect your cache headers so every request for these resources hits the server; treats the content as dynamic content which can't be cached

There could be workarounds for either scenarios. If your website generates enough revenue I would switch to a vanilla pull CDN. You not only have more control over the data, but they are generally faster. I see "proxy CDNs" as 3 kilo Swiss knives, in theory they cover all your needs but they don't excel in anything, including the CDN functionality.

according to gtmetrix, my avatars are not being cached.

a benefit with proxy cdns that I've seen is their bot protection and reduction in spam. when I used to use maxcdn on a forum with over 500k posts, we'd get spammers here and there. when I switched it over to incapsula, I don't recall there being a single spam registration. on my new forum that is a little over 3 months old with almost 1,000 users and around 16k posts that's been using incapsula since the beginning, we've haven't seen a single spammer on the site yet.
(2015-10-14, 05:56 AM)andrewjs18 Wrote: [ -> ]
(2015-10-13, 08:32 AM)SentoWeb Wrote: [ -> ]
(2015-10-13, 07:23 AM)andrewjs18 Wrote: [ -> ]
(2015-10-12, 05:50 PM)Euan T Wrote: [ -> ]@SentoWeb the problem Andrew wants to solve isn't the cache issue, it's the fact that Incapsula is apparently broken and will not serve resources with query arguments from their CDN system.

I don't think this is confined to incapsula though.  I think a lot of proxy CDNs might be like this.

Is Incapsula:
a) not sending cache headers to the client (browser) in case the request url contains a query string but respects your cache headers and doesn't query your server until the cache must be reset; treats the content as cached dynamic content

b) not sending cache headers to the client (browser) in case the request url contains a query string and also doesn't respect your cache headers so every request for these resources hits the server; treats the content as dynamic content which can't be cached

There could be workarounds for either scenarios. If your website generates enough revenue I would switch to a vanilla pull CDN. You not only have more control over the data, but they are generally faster. I see "proxy CDNs" as 3 kilo Swiss knives, in theory they cover all your needs but they don't excel in anything, including the CDN functionality.

according to gtmetrix, my avatars are not being cached.

a benefit with proxy cdns that I've seen is their bot protection and reduction in spam. when I used to use maxcdn on a forum with over 500k posts, we'd get spammers here and there. when I switched it over to incapsula, I don't recall there being a single spam registration. on my new forum that is a little over 3 months old with almost 1,000 users and around 16k posts that's been using incapsula since the beginning, we've haven't seen a single spammer on the site yet.

Can you share the URL so that I can take a look at the response headers?
Pages: 1 2 3 4 5