Se o seu servidor não está apto a trasnferir adequadamente certos tipos de arquivos, como ocorre com alguma frequência com MP3 ou até arquivos SWF, é muito fácil corrigir este “defeito”:

AddType application/x-shockwave-flash swf

AddType especifica que estamos adicionando um tipo MIME. A string da aplicação é o parâmetro do MIME que está sendo adicionado. No exemplo é swf para um arquivo ShockWave.

Uma dica: para forçar o download de um arquivo através do item de menu “Salvar como” do browser, simplesmente ajuste o tipo de MIME para application/octet-stream. Isto faz com que apareça imediatamente a janela para a confirmação de download.

Evitar hot linking

Na comunidade webmaster, “hot linking” é uma expressão amaldiçoada. Também conhecido como “roubo de banda” (bandwidth stealing), refere-se a links apontando diretamente para objetos não- html em servidores que não sejam do proprietário do site. Geralmente são gráficos, arquivos de javascript e de flash referenciados a partir de um site concorrente. O servidor da vítima, neste caso, é espoliado em largura de banda uma vez que o safado se diverte mostrando o conteúdo de uma área que não lhe pertence. O tipo mais comum de roubo de banda está relacionado a imagens gráficas.

Usando o htaccess é possível impedir o hot linking de modo que os que tentarem roubar imagens hospedadas no seu site recebam uma “porta” (the door - uma imagem quebrada) ou a “boca do leão” (the lion’s mouth - uma imagem à sua escolha, hehehe). Tem apenas um pequeno senão: seu servidor precisa apoiar mod_rewrite. Consulte seu servidor a este respeito.

Explicado o assunto, veja a seguir como desabilitar o hot linking de imagens no seu site. Simplesmente adicione o código a seguir ao seu arquivo htaccess e faça o upload para o diretório que desejar:

RewriteEngine onRewriteCond %{HTTP_REFERER}
!^$RewriteCond %{HTTP_REFERER} !^http://(www\.)?seudominio.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ - [F]

Certifique-se de ter trocado “seudominio.com” pelo seu verdadeiro domínio. O código acima faz com que a imagem fornecida apareça quebrada. Se você preferir determinar a imagem que deve substituir a solicitada através de uma hot link, acrescente o seguinte:

RewriteEngine onRewriteCond %{HTTP_REFERER}
!^$RewriteCond %{HTTP_REFERER} !^http://(www\.)?seudominio.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ http://www.seudominio.com/porcaria.gif [R,L]

O efeito do código acima é fornecer a imagem “porcaria.gif” ao invés da solicitada. Do mesmo modo, troque “seudominio.com” pelo seu verdadeiro.

Está mais do que na hora de acabar com a farra do roubo de banda! Um balde de água fria nos espertos.

Autor/fonte: Vovó Vicki

Se você tem diretórios cheios de gráficos ou arquivos zip e não quer que usuários possam simplesmente listar estes diretórios, existem várias opções se a possibilidade de listar diretórios já não esteja desabilitada pelo seu servidor: criar um arquivo index.html, vazio ou não, e colocá-lo em cada um dos diretórios pretendidos - ou, mais uma vez, fazendo uso do htaccess. O código é o seguinte:

IndexIgnore *

O asterisco é um coringa indicando que todo e qualquer arquivo NÃO deve ser listado. Bingo! Colocando o arquivo htaccess no diretório raiz faz com que nenhum diretório possa ser listado.

Por outro lado, se você quiser especificar o tipo de arquivo que não deve ser listado, faça o seguinte:

IndexIgnore *. gif *.jpg

Neste caso, arquivos como .html, .txt, etc serão listados normalmente. Os .gif e .jpg não serão mostrados.

Agora, na situação oposta: seu servidor não permite a listagem de diretórios mas você quer que o faça. Adicione o seguinte:

Options +Indexes

Se você usar esta opção, cuidado para não colocar quaisquer arquivos comprometedores neste diretório. E você já deve ter percebido: o sinal de mais (+) antes de Indexes força a listagem, então, Options -Indexes bloqueia inteiramente a listagem. É como o servidor Apache deveria estar configurado, mas nem sempre está…

Se a listagem for permitida, então você pode mostrar que é um expert no assunto. Crie um arquivo com nome HEADER, ponha nele a descrição da listagem do diretório e coloque no diretório alvo. O conteúdo deste arquivo será mostrado antes da listagem do seu conteúdo. Também é possível criar um rodapé, que deve ter o nome de README. O conteúdo deste arquivo, que deve estar no mesmo diretório, é mostrado logo após a listagem do conteúdo.

Conclusão

É claro que não é possível explorar todas as possibilidades do uso do arquivo htaccess neste tutorial, mesmo porque o objetivo foi apenas o de apresentar as mais importantes. Existem muitas diretivas do Apache que podem ser usadas, se bem que nem todas se referem ao htaccess. Consulte a documentação e garanto que terá muitas surpresas.

Informações precisas e detalhadas do servidor Apache são uma verdadeira mina de ouro para webmasters. Não perca a oportunidade de ganhar tempo com a manutenção do(s) seu(s) site(s). Quem pretende atualizar 4000 ou 5000 páginas na unha não pode ser um webmaster sério - deve estar com brincadeira, né não?

Bem, em todo caso, espero ter ajudado um pouco a esclarecer um assunto dos bastidores mas, sem dúvida alguma, de extrema importância. Em caso de dúvida, façam contato - estou à disposição. Em caso de críticas, enviem-nas para que o site possa sempre melhorar. Em casos de elogios - não se façam de rogados e boa sorte com o htaccess!

Autor/fonte: Vovó Vicki

Estive lendo sobre o projeto do Apache 2.0 e estou gostando muito das novidades.

Tem uma que eu li no CHANGES do 2.0 e se for o que estou pensando será muito útil para quem trabalha com CGI, pois acho que irá eliminar o suexec:

“When mod_cgid is started as root, the cgi daemon now switches to the configured User/Group (like other httpd processes) instead of continuing as root”. [Jeff Trawick]

Porém, eu iria ficar feliz mesmo se me dissessem que agora o Apache irá executar scripts em PHP como usuários diferentes. Se é que eu quem não sei que isso já existe.

A maioria ainda usa o Apache 1.3X que funciona legal. O que resta agora é verificar se o novo Apache vai funcionar legal com o nosso PHP.

Creio que sim mas sempre há aquele medo de migrar e correr o risco de perder performace com o PHP. Isso porque o PHP foi criado com o Apache 1.3X e não com o novo.

Provavelmente a equipe de desenvolvimento do PHP já esté pensando nisso por nós mas não custa ficarmos atentos. Afinal, o que iriamos usar em termos de Linux se não o Apache?

Mais informações:

http://www.apache.org
http://httpd.apache.org/dist/CHANGES_2.0a

Autor/fonte: Roberto Bertó