Facebook fb_xd_fragment cached pages.

I noticed that I have and one additional variant of the cached pages:
page_fbc_channel=1.html

It seems, that Facebook redirect to my site with address:
example.com/myarticle&fb_xd_fragment
So the cached page is stored once as myarticle_.html when visited normally and when visited from FB - myarticle_fb_xd_fragment_html. So 2 copies of the page are stored.

In fact we know how FB redirects to pages- the arguments that FB uses. The arguments that FB passes are in my first post. So maybe it's possible to filter them.
So, if I visit my site with any argument that I add to the end of the URL, will reflect in generation of cached page. example.com/myarticle&blabla will make new version - myarticle_blabla=.html
If we imagine, this can be successful scenario for attack. It's enough somebody to write script with random generator that produce different arguments to the url and to visit all of them one by one. So the attacked site will be overloaded with many cache versions (CPU cycles - generate, store cached page).
This attack will never use the already cached pages, but will produce CPU load.
I don't know how to solve this.. filter can break other functionality maybe, like custom pagers and so on. I will think for idea.

Hmm, they banned me from advertising there "For Lifetime", because they said "you used the advertising for spam", something like this. I wroted to them that I never used their advertising solutions, never entered my CC there to use it, so it's very strange, why I am banned "for lifetime". And they lifted the ban. I will try to write to them.
I will quote 2 messages from there:

Does any one notice that after adding a like button to a page, the page gets hits with a querystring like "?fb_xd_fragment="?

This showing up on google analytics with a high pageviews, especially the top pages of our site.

If I copy and paste the url to the browser with this querystring, the page will flash and then go blank. I tried google "fb_xd_fragment", other sites with this querystring appended to the url are blank too.

And one possible solution, that I am not sure that it can help:

At the bottom of the page, just before closing your tag, put the following code:

Code:

<!-- Correct fb_xd_fragment Bug Start --> 
<script> 
document.getElementsByTagName('html')[0].style.display='block';
</script> 
<!-- Correct fb_xd_fragment Bug End -->

This will reset the html display style from 'none' to 'block'.

By the way, I noticed that If the user click on the message from the wall published yesterday, in boost cache we have generated new version called page_yesterday
But it's strange, because i have and such pages _page=34&part=yesterday.html- and i think that nobody published link to page=34 (there are many files like this, not only one.) And again new version _page=40&part=week.html
Another strange thing is _page=79&action=login.html - again, this is not article page, but pager page.
And last thing - _page=122&iframe=true&width=900&height=450.html
I start to think that maybe not only FB Like is involved here. I will try to see what Application settings I have in Facebook. Before month or two I had FB Connect module activated, but I uninstalled it. Maybe this is something caused from the PHP Library that comes with the module...
First I will disable FB Like for 1 day to see if this will stop generating of such cache pages. Maybe this can help me to trace the origin.

I think, that I found solution!
You need to put in your page.tpl right before the closing tag this code:

<!-- Correct fb_xd_fragment Bug Start --> 
<script> 
document.getElementsByTagName('html')[0].style.display='block';
</script> 
<!-- Correct fb_xd_fragment Bug End -->

I've implemented this and almost half a hour I don't have such cached pages. The server load was reduced!
It seems, that this is old bug in Facebook Like.
You can read more for this bug here:
http://forum.developers.facebook.net/viewtopic.php?pid=232516
And here:
http://bugs.developers.facebook.net/show_bug.cgi?id=9777
So, maybe Boost users with FB Like buttons is good to implement this workaround. I will report later if this workaround continues to work fine (i hope!)

Stephane, this is great info, it shows that this is problem to many others...
But in Boost there is problem, because it creates pages and pages in the cache.
My fix didn't help. My boost directory is again full with pages. My website have 3000 nodes and for one or two days in cache directory I collect more than 9000 cached pages. The correct pages are no more than 2 or 3000. All other cached pages are caused from this Facebook behaviour.
All other pages, caused from the Facebook URL arguments are useless pages. They make my PHP to produce more and more cached pages and additionally loads my CPU.
I am very surprised, that I am the only one, that reports this and few other guys suffer from this behavior...