cache de tags de vídeo html5

Question

Nós rodamos um bonito servidor Centos 7 LAMP (Apache 2.4 com mod_pagespeed PHP 5.6, MariaDB 5.5), e recentemente começamos a incorporar vídeos html5 no plano de fundo de algumas páginas conforme o código:

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

O vídeo funciona como esperado, e auto-loop como esperado, a maioria dos nossos clientes carrega o vídeo uma vez e recarrega o vídeo do cache após a primeira execução, mas temos alguns clientes (estou contando 3 no momento) que mantêm o download novamente toda vez após a primeira execução e isso acaba com nossa cota de largura de banda muito rápido (às vezes, o mesmo endereço IP baixa 35gb do mesmo arquivo de vídeo de 7mb).

Tenho certeza de que esse comportamento não é mal-intencionado (nesse caso, pelo menos, estou disposto a acreditar que há algum erro de configuração em seu servidor proxy ou algo assim) e, portanto, estou procurando maneiras de limitar a largura de banda usada por um endereço IP, ou para informar melhor o navegador do cliente para armazenar em cache o arquivo de vídeo, nós já tentamos usar o apache virtual-host e via .htaccess esta configuração e isso não parece fazer a diferença.

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

Eu já testei o movimento do arquivo de vídeo para outro servidor com uma configuração diferente (uma ainda mais baunilha do Centos 6.6 LAMP) para testar se não era algum erro de configuração da nossa parte

então minha pergunta é Existe uma maneira fácil de bloquear usando a configuração do Apache (temporariamente por 24 horas ou uma semana talvez) apenas o carregamento de um arquivo por determinados endereços IP após 10 cargas, mantendo a capacidade de carregar o restante do site?

ou existe uma maneira melhor de informar o cliente para seguir as regras de cache?

Eu provavelmente poderia escrever um script PHP que contasse as vezes que o arquivo foi carregado e respondido com um 403, caso ele tenha sido baixado mais de X vezes pelo mesmo IP, mas eu não acho que esta solução seja ótima.

como por logs do apache, nosso cliente está executando o windows 10 x64 com o google chrome 48 (talvez este seja um bug conhecido)

    

Answer 1

Apenas uma pequena resposta a essa pergunta para que não fique sem resposta para sempre, não resolve o problema, mas pelo menos diminui a conta que tivemos de pagar.

Consegui replicar o problema com um servidor de squid mal configurado, agindo como um proxy.

O que eu fiz neste caso foi hospedar o vídeo e outros vídeos que tivemos que hospedar desde então, em outro servidor que tinha uma maior latência, mas largura de banda extremamente barata.

A experiência geral do cliente não muda muito porque, como estamos hospedando apenas os arquivos de vídeo no servidor barato, não estamos pagando o preço de alta latência para cada arquivo, apenas para a solicitação ao vídeo.