1

We run a pretty vanilla Centos 7 LAMP server ( Apache 2.4 with mod_pagespeed PHP 5.6, MariaDB 5.5 ), and recently started embedding html5 videos on the background of some pages as per code:

<video class="banner-video" loop autoplay poster="img/poster.jpg">
    <source src="videos/intro.mp4" type="video/mp4">
</video>

The video works as expected, and auto-loop as expected, most of our clients load the video once and reload the video from the cache after the first run, but we have some clients ( I am counting 3 at the moment ) that keep re-downloading every time after the first run and this blows our bandwidth quota pretty fast ( sometimes the same ip address downloads 35gb worth of the same 7mb video file ).

I am pretty sure that this behavior is not malicious ( in this case at least, i am willing to believe it is some misconfiguration at their proxy server or some such ), and so I am looking at ways to limit the bandwidth used by one ip address, or to better inform the client browser to cache the video file, we already tried to use in the apache virtual-host and via .htaccess this config and it doesn't seems to make a difference.

<FilesMatch "\.(mp4)">
    Header set Cache-Control "max-age=604800, must-revalidate"
</FilesMatch>

I've already tested moving the video file to another server with a different configuration ( an even more vanilla Centos 6.6 LAMP ) to test if it was not some misconfiguration on our part

so my question is is there an easy way to block using apache configuration (temporarily by 24 hours or one week maybe) only the loading of a file by certain ip addresses after say 10 loadings, while maintaining the ability to load the rest of the site ?

or is there a better way to inform the client to follow the cache rules ?

I probably could write an PHP script that counted the times the file has been loaded and responded with a 403 in case that it has been downloaded more than X times by the same IP but i don't think this solution is optimal.

as by apache logs our client is running windows 10 x64 with google chrome 48 ( maybe this is a know bug )

Rafael Rotelok
  • 121

1 Answers1

0

Just a small follow-up answer to this question so it don't end up unanswered forever, it doesn't actually fix the problem but at least it lowers the bill we had to pay.

I was able to replicate the issue with a badly configured squid server acting as a proxy.

What I did in this case was host the video, and other videos we had to host since then, in another server that had a higher latency but extremely cheap bandwidth.

The overall client experience doesn't change much because as we are only hosting the video files in the cheap server we are not paying the high latency price for every file, just for the request to the video.

Rafael Rotelok
  • 121