Porém, finalmente coloquei o site no ar. Se chama BFUT.net. BFUT é um instituto que ensina aos americanos técnicas de futebol brasileiro e surgiu da incorporação de uma empresa chamada BRUSA (cujo site eu também havia desenvolvido) pela Traffic Sports, conhecida empresa de marketing esportivo, atuante no Brasil, América Latina e Estados Unidos.

O layout foi criado pelo Diego Eis e implementado por nós dois. Na verdade, o markup (XHTML Strict, enviado como HTML) foi todo desenvolvido por mim e o CSS parte por mim parte por ele.

O mais interessante no desenvolvimento desse site foi ter sofrido a pior ameaça que um desenvolvedor web pode sofrer: o site precisaria ser hospedado em um servidor IIS. Sério, pare e pense. Em um servidor IIS não há arquivos .htaccess, o mais próximo que se pode chegar da funcionalidade do mod_rewrite é usando alguma ferramenta de terceiros como o ISAPI Rewrite (que faz um trabalho minimamente decente, nada mais que isso) e em um servidor windows não há acesso SSH. Ou seja, é como capar o pobre desenvolvedor. Dizer a ele que nunhuma das ferramentas que tornam a vida dele mais fácil podem ser usadas.

Felizmente o administrador dos servidores não era lá muito íntimo do PHP e MySQL (pelo menos não no IIS) e, depois de intermináveis tentativas de fazer o negócio funcionar, decidiu por me entregar um servidor linux, com apache, PHP, MySQL e liberdade pra instalar qualquer ferramenta e fazer qualquer configuração que fosse necessária. Respirei aliviado.

A parte triste é que, a essa altura, eu já havia desistido de usar o CakePHP, já que ele não roda lá muito bem no servidorzinho meia-boca da empresa do tio (seu, não meu) Gates. O cake é um framework MVC, fortemente baseado na estrutura do Ruby on Rails, que facilita muito a vida do programador, aumenta a produtividade e ajuda a criar um código mais limpo e fácil de manter (estou investigando atualmente o Symfony, que parece ser muito interessante também).

Mas, apesar dos pesares, o site está no ar e eu fiquei bastante satisfeito com o resultado (e, felizmente, o cliente também ). Criei um CMS simples para que o próprio cliente possa gerenciar com facilidade o conteúdo do site.

Usei o WidgEditor, um excelente editor HTML feito pelo Cameron Adams que, apesar de ostentar a assustadora sigla WYSIWYG em sua descrição, gera um markup limpo e, ao menos pelo que pude ver até agora, válido. É fácil de customizar e muito simples de usar pelo usuário leigo (desde que você diga a ele em letras maiúsculas com negrito e itálico, para não colar texto copiado direto do Word dentro da área de edição). Aquele papinho que ouvimos por aí de que não é possível gerar HTML válido porque os editores não entendem da linguagem pode ser classificado de uma vez por todas de “bullshit”. Um elemento SCRIPT no HEAD do HTML e uma class=”widgEditor” em qualquer TEXTAREA e pronto.

Acho que não há muito o que falar sobre o código do site. XHTML simples, CSS, nenhuma técnica muito avançada de marcação ou estilo. Simplesmente o bom e velho feijão com arroz, que é a melhor opção em 99% dos casos. O menu dropdown foi feito usando o Suckerfish, que funciona 100% via CSS nos browsers e via um pequeno script javascript naquele negócio que atende pelo nome de Internet Explorer.

Por agora é isso. O site está no ar e eu gostaria de ouvir os comentários de vocês. Fiquem à vontade.

[update]
Se você usa WordPress, pode usar o WordPress Feedburner Plugin. Eu não testei, mas pelo que li parece que ele faz todo o trabalho sujo pra você. Se alguém tiver testado, por favor, me conte como é e eu posto aqui.

[update2]
Atualizei o post pra dizer que, se você usa o wordpress e não está afim de usar o plugin citado acima, você tem que colocar qualquer regra de reescrita deste artigo antes das regras do wordpress. Da seguinte forma, por exemplo:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !feedBurner [NC]
RewriteRule ^feed/?$ http://feeds.feedburner.com/meufeed [R=302,L]
RewriteEngine Off
# BEGIN WordPress 

Se as regras forem colocadas depois das do wordpress, ele simplesmente vai aplicar as regras dele e finalizar a reescrita, sem nem ao menos ler as regras que você fez.

Outro motivo para o update é que é interessante fazer a checagem do user agent de forma que seja ignorada a caixa das letras. Ou seja, usando o [NC], como acima.
[/update2]

E para os usuários de Movable Type também tem um plugin. Acho que a Simone está usando e, pelo jeito, está funcionando muito bem.
[/update]

Como eu disse, para fazer esse tipo de coisa, é necessário pelo menos um mínimo de conhecimento sobre HTTP. Você precisa saber manipular redirecionamentos e verificar User Agents seja pelo seu servidor HTTP, seja por alguma linguagem que rode no servidor.

Como vejo que há muitas pessoas com dúvidas sobre isso, vou explicar rapidamente como configurar os tais redirecionamentos.

Vou usar três hipóteses e dar a solução para cada uma delas: feeds estáticos, feeds dinâmicos acessados por uma URL sem query string (variáveis na URL, do tipo ?var1=valor1&var2=valor2) e feeds dinâmicos com query string.

Feeds estáticos

Feeds estáticos são meros arquivos em XML plano, que podem ser acessados via uma URL que reflita sua posição no sistema de arquivos abaixo da root do site ou por alguma URL customizada, seja por meio de mod_rewrite, PHP ou algum outro meio.

Vamos ver como proceder nos dois casos.

Para o nosso exemplo, vamos imaginar um arquivo chamado feed.xml, localizado na raiz do seu site. Normalmente ele pode ser acessado pela URL http://seusite.com/feed.xml.

Vamos assumir também que a URL do novo feed gerado no feedburner seja http://feeds.feedburner.com/meufeed.

Nesse caso, há duas maneiras de você fazer com que seus leitores continuem acessando a url dentro do seu site e sejam redirecionadas para o feedburner: mantendo o mesmo arquivo e verificando o user agent ou mudando o nome do arquivo.

Se você mudar o nome do arquivo, a coisa se simplifica. Nesse caso o mod_rewrite nem é necessário. Por exemplo, se seus usuários acessam /feed.xml, voce pode trocar o nome desse arquivo pra feed-fb.xml, usar essa URL no feedburner e redirecionar a URL que seus usuários acessam com uma regra de redirecionamento (mod_alias):

Redirect /feed.xml http://feeds.feedburner.com/meufeed

Note que o arquivo feed.xml não existe mais. O que há agora é uma URL, /feed.xml, que simplesmente redireciona para um outro local.

Se você mantiver o arquivo com o mesmo nome, o que você precisa fazer é apenas incluir as linhas abaixo no seu arquivo .htaccess, na raiz do site (no mesmo diretório onde está o feed):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !feedBurner [NC]
RewriteRule ^feed\.xml$ http://feeds.feedburner.com/meufeed [R=302,L]

Isso significa: se o user agent não for o feedburner, ao receber uma requisição para feed.xml, redirecione para http://feeds.feedburner.com/meufeed. Esse redirecionamento é temporário (R=302), e essa regra deve ser a última a ser processada (L), ou seja, qualquer regra abaixo desta deve ser ignorada.

A primeira linha é necessária porque o feedburner precisa continuar tendo acesso à URL original, e não ser redirecionado pra si mesmo.

Agora, imaginemos que o seu feed (feed.xml) seja acessado pela url http://seusite.com/feed de acordo com uma regra de reescrita, como a abaixo:

RewriteRule ^feed\/?$ /feed.xml

Os usuários devem continuar acessando essa URL (/feed) e ser redirecionados para a nova, no feedburner. Para isso, use uma regra bem parecida com a primeira:

RewriteCond %{HTTP_USER_AGENT} !feedBurner [NC]
RewriteRule ^feed\/?$ http://feeds.feedburner.com/meufeed [R=302,L]

RewriteRule ^feed\/?$ /feed.xml

Ou seja, qualquer um, menos o feedburner, vai ser redirecionado. Acho que você já pegou a idéia, né? Que bom…

Feeds dinâmicos sem query string

Mesmo que o seu feed seja dinâmico, leia a parte acima, sobre feeds estáticos, para entender como funciona o esquema do redirecionamento. A mágica com os arquivos dinâmicos é exatamente a mesma.

Digamos que o seu feed se chame feed.php e esteja localizado na raiz do seu site. E a URL do feed no feedburner é a mesma que usamos acima.

No caso de você fornecer a seus leitores a url com a localização do arquivo PHP (http://seusite.com/feed.php), use a seguinte regra:

RewriteCond %{HTTP_USER_AGENT} !feedBurner [NC]
RewriteRule ^feed\.php$ http://feeds.feedburner.com/meufeed [R=302,L]

A explicação é a mesma dada acima.

No caso de você fornecer uma URL customizada, como por exemplo http://seusite.com/feed, use a regra:

RewriteCond %{HTTP_USER_AGENT} !feedBurner [NC]
RewriteRule ^feed\/?$ http://feeds.feedburner.com/meufeed [R=302,L]

RewriteRule ^feed\/?$ /feed.php

Ou seja, funciona da mesma forma que quando o feed é estático. Mas, como eu sei que vão perguntar, acho que pecar por excesso não é o pior dos pecados .

Feeds dinâmicos com query string

Vou usar o exemplo do nosso amigo Rodrigo Ghedin. O feed do site dele tem uma URL que consiste do nome de um arquivo PHP mais uma query string. A URL é http://winajuda.com/news/rss.php?f=view. E qual o problema com isso? Bem, o mod_rewrite não intercepta a query string. Ou seja, se você reescreve um arquivo rss.php para, por exemplo, feed.rss, este último aceitaria normalmente as query strings na URL. Ou seja, você precisaria acessar por /feed.rss?f=view.

Trocando em miúdos, se você usar

RewriteRule ^rss\.php$ http://feeds.feedburner.com/meufeed [R=302,L]

e acessasse http://seusite.com/rss.php?f=view, você seria redirecionado para a URL do feedburner, com a query string no fim. Assim: http://feeds.feedburner.com/meufeed?f=view.

Isso não causa problemas, na verdade, mas fica um pouco estranho. Esse caso não é, na verdade, o melhor para demonstrar o problema com as query strings mas, se você tem algum caso em que várias variáveis sejam passadas pela query string e isso não possa ser mudado, saiba que o mod_rewrite não é muito seu amigo nesse caso. Você não pode fazer, por exemplo:

RewriteRule ^rss\.php\?f=view$ http://feeds.feedburner.com/meufeed [R=302,L] #isso é errado

Isso não vai funcionar. A melhor maneira de resolver isso é, com certeza, no próprio PHP. E é muito simples.

[update]
Estive discutindo sobre isso com o Danilo hoje e ele me mostrou um texto que mostra como lidar com query strings com mod_rewrite. No caso do nosso exemplo, a regra seria assim:

RewriteCond %{HTTP_USER_AGENT} !feedBurner [NC]
RewriteCond %{QUERY_STRING} ^f=view$
RewriteRule ^rss\.php$ http://feeds.feedburner.com/meufeed? [R=302,L]

[/update]

Continuando a usar o exemplo do Ghedin, ele precisa apenas colocar algumas linhas no início do arquivo rss.php:

<?php
$ua = $_SERVER['HTTP_USER_AGENT'];
if ((isset($_GET['f'])) &&
  ($_GET['f'] == 'view') &&
  (! eregi('feedburner', $ua)))
  {
    header("Location: http://feeds.feedburner.com/meufeed");
    exit; # so pra garantir que não continue a execução
  }
?>

Simples assim. Acho que não é necessário explicar as linhas acima, assumindo que você entenda pelo menos um pouco de PHP.

Bom, é isso. Acho que com esse texto você tem o básico para brincar com redirecionamentos. Mas, lembre-se, HTTP é a base da web. Você precisa entendê-lo pelo menos um pouco. Portanto, vale a pena dar uma estudada sobre o assunto. Uma busca no google é um bom começo.

Mas isso causa um problema: se você fizer alguma modificação no CSS, o browser só vai baixar a nova versão do arquivo se você der
um reload (F5, em geral). Isso é muito chato e pode “quebrar” totalmente o layout de uma determinada página se forem feitas
modificações também no (X)HTML.

Vejamos como esse problema pode ser resolvido.

Uma solução seria trocar o nome do arquivo CSS. Bom, mas trocar o nome do arquivo não é lá uma solução muito boa. Imagine um site com 100 páginas (X)HTML estáticas. Se você
trocar o nome do arquivo CSS, vai ser obrigado a editar todos os (X)HTML para trocar o nome do CSS no link ou style e
subir todos os arquivos pro servidor. No caso de um site dinâmico com um template para todas as páginas o trabalho seria menor, mas mesmo
assim não é uma solução muito elegante.

Outra solução seria gerar o CSS a partir de um script, por exemplo, PHP. Mas isso está fora de questão já que evitaria o caching
pra sempre, a ṇo ser que voc̻ controlasse o caching pelo PHP Рo que ṇo ̩ a mais trivial das tarefas.

Diante do problema, ponderei sobre algumas possíveis soluções e a melhor que achei foi fazer uso do
mod_rewrite do apache.

O processo é bem simples. Digamos que você tenha um arquivo chamado estilo.css. Ao atualizá-lo, salve-o como
estilo2.css e use a seguinte regra de reescrita no seu arquivo .htaccess

RewriteEngine On
RewriteRule ^estilo.css$ /estilo2.css

Simples e indolor. Agora é só subir os dois arquivos (.htaccess e estilo2.css) para o servidor e pronto, o CSS vai ser atualizado
automaticamente. Feito isso você pode apagar o arquivo estilo.css original.

[update]A técnica do Élcio é bem mais simples, elegante e eficiente. Hoje em dia, é a que uso.[/update]

Neste texto vou tentar explicar o funcionamento e as vantagens do gerenciamento de URLs com PHP em relação ao gerenciamento de URLs usando apenas mod_rewrite.

Este artigo não é uma tradução, mas é fortemente baseado no artigo de Till Quack para o A List Apart, How to succeed with URLs.

A principal vantagem de se usar PHP ao invés de apenas o mod_rewrite é que o PHP é bem mais simples. O mod_rewrite é conhecido tanto pelo seu poder quanto pela sua complexidade, não apenas pelo fato de ser necessário um bom entendimento de expressões regulares para poder usá-lo mas também por ser um tanto obscuro e difícil de entender, principalmente para os iniciantes.

É importante que você entenda o que eu quero dizer com o termo gerenciamento de URLs antes de ler o restante deste texto. Dois textos escritos por mim podem ajudá-lo a entender melhor o que isso significa: Gerenciamento de URLs – Criando URLs amigáveis e URLs amigáveis – esclarecendo dúvidas.

O principal conceito a ser entendido sobre as URLs é que elas nem sempre se referem a um arquivo ou diretório existente no disco. Na realidade, URLs nunca devem se referir a arquivos diretamente. Isso torna suas URLs voláteis, vulneráveis a mudanças. Afinal, como diria Tim Berners-Lee, cool URIs don’t change.

Para usar as técnicas descritas neste texto você precisa do servidor web Apache com o mod_rewrite habilitado, PHP e, principalmente, um bom planejamento. Antes de qualquer coisa, planeje como você quer que suas URLs sejam. Use URLs que resumam de maneira adequada e sucinta o conteúdo do recurso que descrevem.

Bem, agora que você já tem seu esquema de URLs bem planejado, vamos ao que interessa. Mãos à obra.

Crie um script PHP. Vamos chamá-lo de urls.php. Todo tráfego do site (com algumas exceções) será direcionado para esse script. Para fazer isso, crie um arquivo .htaccess na raiz do seu site com o seguinte conteúdo:

RewriteEngine On
RewriteRule !\.(gif|jpg|png|css)$ /raiz_do_site/urls.php

A primeira linha serve para ligar o mod_rewrite e a segunda é a que direciona o tráfego para urls.php. O conteúdo entre parêntesis define as extensões de arquivo que devem ser excluídas desse processo, ou seja, devem ser tratadas da maneira padrão pelo servidor web. Você pode querer incluir mais algumas extensões nessa lista (swf, svg, xml, js, txt, por exemplo), de acordo com a sua necessidade.

Você deve substituir raiz_do_site pelo caminho completo do seu site no servidor, por exemplo, /home/httpd/dominio.com/. Porém, em algumas configurações do apache (todas que eu particularmente já usei), apenas o caminho relativo já é o suficiente, no caso /urls.php ou apenas urls.php.

Agora vamos começar a escrever o script urls.php.

O primeiro passo é verificar se a requisição refere-se a um arquivo existente.

<?php
//Código retirado do A List Apart
$DOCUMENT_ROOT = $_SERVER['DOCUMENT_ROOT'];
$REQUEST_URI = $_SERVER['REQUEST_URI'];
$SCRIPT_FILENAME = $_SERVER['SCRIPT_FILENAME'];
if(file_exists($DOCUMENT_ROOT.$REQUEST_URI)
and ($SCRIPT_FILENAME!=$DOCUMENT_ROOT.$REQUEST_URI)
and ($REQUEST_URI!="/")){
    $url=$REQUEST_URI;
    include($DOCUMENT_ROOT.$url);
    exit();
}

Simplesmente verificamos se a URL refere-se a um arquivo existente, incluimos este arquivo e encerramos o script.

O próximo passo é dividir a URL em pedaços separados por “/” e verificar se o user-agent fez uma requisição pela index do site.

$url=strip_tags($REQUEST_URI);
$url_array=explode("/",$url);
array_shift($url_array); //o primeiro índice sempre será vazio
if(empty($url_array)){
	include("site_index.php");
exit();
}

Trivial, não? Se $REQUEST_URI estiver vazia significa que o usuário está requisitando a index do site. Neste caso, incluimos o script referente à index e encerramos o script.

Bom, se o usuário não requisitou um arquivo existente nem a index do site, chegou a hora de verificar se o que ele está tentando acessar é um conteúdo dinâmico. Provavelmente algo armazenado em um banco de dados, arquivos XML ou o que quer que você use pra armazenar o conteúdo dinâmico do seu site.

Neste caso não há uma fórmula pronta. Cada caso é um caso. Como você já planejou previamente o seu esquema de URLs, com certeza você sabe o que cada URL descreve. Portanto, você deve cuidar dessa parte.

Vou usar uma função fictícia verifica_conteudo() que retorna true caso a URL requisitada corresponda a algum dado presente, por exemplo, no seu banco de dados e uma outra exibe_conteudo() que cuidará para que este conteúdo seja exibido da forma adequada.

if (verifica_conteudo()){
	exibe_conteudo();
	exit();
}

Se também não houver conteúdo dinâmico referente à URL requisitada, só nos resta enviar um erro 404, informando ao user agent que o recurso requisitado não existe.

header("HTTP/1.1 404 Not Found");
exit();

Alguns cuidados devem ser tomados em relação a usuários maliciosos que queiram tentar acessar arquivos do seu sistema que podem causar danos ou garantir acesso privilegiado. Para prevenir esse tipo de coisa, adicione no início do script algumas linhas de código verificando se o usuário está requisitando algo como “../../../algum_script” ou coisas do tipo.

Acessos a URLs longas demais também devem ser prevenidos. Para isso, inclua o seguinte no início do script:

if(strlen($REQUEST_URI)>100){
	header("HTTP/1.1 404 Not Found");
	exit();
}

E é isso. O desenvolvimento desse script vai depender exclusivamente do seu caso específico. A idéia é essa. Se você a entendeu vai ser fácil adaptá-la para a sua necessidade.

Mas, além disso, há outra coisa interessante que se pode fazer com esse script que – para mim pelo menos – não é possível fazer usando apenas regras do mod_rewrite.

Lembra quando você ainda não conhecia as vantagens de se usar URLs amigáveis e usava URLs do tipo index.php?var1=valor1&var2=valor2…? Então, agora você está usando URLs totalmente diferentes e não é legal deixar “quebrados” todos os links e bookmarks que apontam para as URLs antigas, concorda?

Desde que haja alguma correspondência (é bem provável que haja) entre as URLs antigas e as novas, é possível mantê-las funcionando, lançando mão de redirecionamentos permanentes (código HTTP 301).

Como? Bem, a o código vai variar de acordo com o esquema de URLs usado. Você pode criar um código que analise a URL e redirecione para a URL nova. Exemplo: digamos que suas URLs antigas fossem da forma index.php?s=secao&a=artigo e as novas sejam da forma /secao/artigo. Neste caso, ao dividir a URL em pedaços teríamos $url_array[0] = “index.php?s=secao&a=artigo”. O que precisamos fazer é dividí-la novamente em pedaços, pegar os valores das variáveis que nos interessam, manipulá-las se for necessário e redirecionar para a URL correta.

$url = explode("?", $url_array[0]);
array_shift($url);
$url = explode("&", $url[0]);
$secao = explode("=", $url[0]);
$secao = $secao[1];
$artigo = explode("=", $url[1]);
$artigo = $artigo[1];
$url = "http://dominio.com/$secao/$artigo";
header("HTTP/1.1 301 Moved Permanently");
header("Location: " . $url);

Acho que não preciso explicar esse pedaço de código, não é? Bom, de qualquer maneira, você precisa adaptá-lo para o seu caso.

Por último temos que cuidar dos diretórios que eventualmente precisem ser manipulados diretamente pelo servidor web, sem a interferência do mod_rewrite e do nosso script. Por exemplo, você pode ter um diretório “/unsorted/” onde você guarda arquivos aleatórios e deseja que o conteúdo desse diretório seja listado da maneira padrão pelo apache. Ou então, diretórios com arquivos index.html que devem se comportar da maneira padrão. Ou ainda diretórios protegidos por senha.

Neste caso, será necessário adicionar uma regra de reescrita em nosso .htaccess para cada diretório desses. Em princípio eu imaginei que fosse possível colocar todos em uma regra só, utilizando o alternador “|” mas, por algum motivo que desconheço, não funciona. A regra é a seguinte:

RewriteRule   ^unsorted/.*$ - [L]

O “-” informa ao mod_rewrite para sair do caminho e deixar o apache cuidar sozinho da requisição e o “[L]” faz com que essa regra, se satisfeita, seja a última a ser executada. Nenhuma RewriteRule posterior será avaliada. No caso, seu .htaccess deve ficar mais ou menos assim:

RewriteEngine On
RewriteRule   ^unsorted/.*$ - [L]
RewriteRule !\.(gif|jpg|png|css)$ /raiz_do_site/urls.php

Concluindo, mais uma vez deixo claro que não há fórmula mágica para gerenciar suas URLs. Mas o processo não é complicado e, uma vez entendido, é simples aplicá-lo a qualquer caso. Desde que você planeje seu esquema de URLs da maneira adequada.

Vou tentar explicar um pouco melhor esse processo.

A primeira coisa que precisa ficar clara é que o google — assim como qualquer outra search engine — não tem acesso aos arquivos dinâmicos do seu site. Os spiders acessam apenas o código (X)HTML gerado por eles.

É importante entender que um spider é como um usuário qualquer. A diferença é que ele é uma ferramenta automatizada que percorre os links que encontra e cria um índice que será usado pelo sistema de busca.

Outra coisa que também precisa ser entendida é que os spiders associam um recurso (uma página HTML, por exemplo) com a URL usada para chegar até ele. Exemplificando: digamos que você decida usar o mod_rewrite para criar URLs amigáveis.

Sendo assim, uma página que antes seria acessada pela URL www.seusite.com/index.php?data=01-02-2005&nome =meu-artigo¹ agora será acessada por www.seusite.com/01/02/2005/meu-artigo. A URL antiga continuará funcionando e o google só passará a listar a nova URL se todos os links para a referida página forem atualizados para a nova URL.

A troca — ou reescrita — das URLs é feita pelo apache de maneira transparente ao usuário, portanto, apenas o servidor
tem conhecimento desta reescrita. O usuário, assim como o spider, não consegue perceber este processo.

Reescrita de URL é diferente de redirecionamento. Um redirecionamento informa ao user agent (browser, spider, leitor de tela, etc) que um recurso encontra-se acessível por outra URL. O user agent aponta para a nova URL e acessa o recurso. O processo de redirecionamento não é transparente ao usuário.

Já a reescrita (feita pelo mod_rewrite) é um processo interno ao servidor web. Este analisa uma regra de reescrita (RewriteRule)
existente em um arquivo .htaccess, executa um redirecionamento e entrega o recurso ao user agent sem informar uma nova URL.
Vou tentar explicar com um exemplo:

Consideremos a URL citada acima: www.seusite.com/index.php?data=01-02-2005&nome=meu-artigo¹. Esta URL chama um script PHP, com duas variáveis e seus respectivos valores. O script executa alguma ação com esses valores (lê os dados de um banco de dados, por exemplo) e entrega ao user agent um documento HTML.

Para reescrever essa URL para www.seusite.com/01/02/2005/meu-artigo podemos usar a seguinte regra de reescrita:

RewriteEngine On #Liga o mecanismo de reescrita (mod_rewrite)
RewriteRule ^([0-9]+)\/([0-9]+)\/([0-9]+)\/([A-Za-z-]+)$ /index.php?data=$1-$2-$3&nome=$4

Explicar a regra acima está fora do escopo deste artigo. Leia o artigo Gerenciamento de URLs – Criando URLs amigáveis.

O que quero deixar claro é como o apache vai executar esta tarefa.

O arquivo .htaccess é processado pelo apache toda vez que ele acessa um arquivo dentro do diretório onde ele (o .htaccess) se encontra. Quando um usuário tentar acessar a URL www.seusite.com/01/02/2005/meu-artigo o apache vai casar o padrão desta URL com a expressão regular presente na RewriteRule. Havendo compatibilidade — e neste caso há — ele vai verificar a segunda parte da regra (/index.php?data=$1-$2-$3&nome=$4) e fazer uma requisição ao arquivo com as substituições necessárias (no caso /index.php?data=01-02-2005&nome=meu-artigo). O script vai realizar as operações necessárias para gerar o conteúdo HTML e o apache entregará este conteúdo direto ao user agent. Processo transparente, lembra-se?

Mais uma vez, para essa troca de URL fazer alguma diferença nos sites de busca é necessário que se troquem todas as referências. Ou seja, trocar <a href=”http://www.seusite.com/index.php?data=01-02-2005&nome=meu-artigo”>Meu artigo</a>¹ por <a href=”http://www.seusite.com/01/02/2005/meu-artigo”>Meu artigo</a>.

Outra coisa importante são os links vindos de outros sites. Se você puder, peça aos administradores dos sites para trocarem os links.

Espero com este texto ter esclarecido as dúvidas que restaram sobre mod_rewrite e URLs amigáveis. Se houver algum ponto que não tenha sido esclarecido, por favor, comentem.

[1] O espaço antes do ‘=’ foi incluído para proporcionar quebra de linha quando necessário e não faz parte da URL.

Isto é muito interessante, mas gera um problema: URLs grandes ou complicadas demais, difíceis de memorizar e sem significado, que podem até mesmo dificultar a indexação do site por mecanismos de busca.

Vamos aprender como criar URLs amigáveis, indexáveis e que resumam, de alguma forma, o recurso que elas descrevem.

Introdução

É comum vermos URLs do tipo:
index.php?section=artigos&data=09-08-2004
ou
index.php?s=web&p=1
ou piores que isso, como:
/cgi-bin/index.cgi?id=7288731803928617293&page=6

Os exemplos acima são fictícios mas, com certeza você já se deparou com URLs bem parecidas com essas, inclusive em sites muito conhecidos.

Qual o problema dessas URLs?

A princípio você pode pensar que não há problema algum com essas URLs. Mas pense um segundo. Você consegue decorar uma URL desse tipo? Não seria muito melhor que fosse algo do tipo:
www.site.com/artigos/09/08/2004
ou
www.site.com/web/1

Além do problema da complexidade, essas URLs geram outros problemas:

• Alguns mecanismos de busca podem deixar de indexar estas páginas, por causa dos caracteres ‘?’ e ‘&’
• A tecnologia usada na construção do site está sendo exposta
• Se você resolver mudar a tecnologia do seu site (php para asp, por exemplo), todas as URLs terão que ser mudadas

Expor a tecnologia usada para fazer um site pode ser um problema de segurança e, hoje em dia, qualquer cuidado com segurança, mesmo que pequeno, é importante.

E, além disso, com a mudança da tecnologia usada, todos os links e bookmarks que existam para o seu site serão quebrados, e isso não é nem um pouco interessante.

O que fazer então?

A solução que vou apresentar serve para os usuários do servidor web apache.

É necessário que esteja habilitado no servidor o módulo mod_rewrite e que seja possível o uso de arquivos htaccess.

A solução é simples: mapear as URLs reais para URLs “virtuais”, mais fáceis de compreender e indexar, e independentes da tecnologia utilizada.

É necessário um pouco de conhecimento de expressões regulares.

O que é o mod_rewrite

mod_rewrite é um módulo do apache que realiza a reescrita transparente de URLs usando expressões regulares.

É como se fosse um redirecionamento, só que o usuário não fica sabendo que a página foi reescrita, já que o endereço na barra de endereços do browser não muda e nenhum cabeçalho HTTP 3xx é enviado.

Mãos a obra

O primeiro passo é criar um arquivo htaccess no diretório raiz do seu site (DocumentRoot e acrescentar a linha:
RewriteEngine On
Esta linha habilita o uso do mod_rewrite no seu site.

Agora vamos ? reescrita da URL. Vamos utilizar os exemplos acima. São exemplos simples, mas meu intuito é mostrar o funcionamento da técnica. Você pode usar a sua criatividade para fazer o que quiser e o que for necessário para o seu caso.

Primeiro exemplo: index.php?s=web&p=1

Analisando esta URL podemos perceber que temos duas variáveis (‘s’ e ‘p’), provavelmente referentes a seção e página, respectivamente.

Vamos transformá-la em: /web/1

A regra ficaria assim:
RewriteRule ^(.+)\/?([0-9]*)\/?$ /index.php?s=$1&p=$2

Vamos entender a linha acima:
RewriteRule: define o início de uma regra de reescrita.

^(.+)\/?([0-9]*)\/?$: a url “virtual”, ou seja, a url que será usada nos links para esta página. Para que entende um pouco de expressões regulares, esta expressão é bem simples de entender, vamos dissecá-la:
(.+): significa um ou mais caracteres (.). O significado dos parêntesis vai ser explicado mais adiante.
\/?: zero ou uma barra (/). A contrabarra (\) serve para “escapar” o caractere /, informando que ele deve ser interpretado literalmente, e não como um metacaractere.

([0-9])*: qualquer quantidade de dígitos (números), ou seja, zero ou mais.
/index.php?s=$1&p=$2: esta é a URL real, ou seja, a url que vai estar sendo acessada por meio do mod_rewrite.
As expressões ‘$1′ e ‘$2′ significam o primeiro e segundo conjunto de caracteres agrupados por parênteses na expressão da esquerda. Ou seja, é guardada uma referência para esses grupos de caracteres para que você possa usá-los.

Exemplos do resultado desta regra:

/web/1 ou /web/1/ = /index.php?s=web&p=1
/outrasecao/5 ou /outrasecao/5/ = /index.php?s=outrasecao&p=5
/web ou /web/ = index.php?s=web&p=

Vamos a mais um exemplo:
RewriteRule ^artigos\/?([0-9]+)\/([0-9]+)\/([0-9]+)\/?$ index.php?section=artigos&data=$1-$2-$3
(Perceba que a linha pode estar quebrada para caber no espaço, mas trata-se de uma linha só, sem quebras).

Assim, você poderia acessar a URL index.php?section=artigos&data=09-08-2004 pela URL “virtual” artigos/09/08/2004, bem mais amigável do que a primeira.

Não apenas páginas dinâmicas podem ser reescritas por meio do mod_rewrite. Conteúdo estático também.

Um exemplo:
www.site.com/noticias/09-08-2004.html
poderia ser reescrita para
www.site.com/noticias/09/08/2004

usando a regra
RewriteRule ^noticias\/?([0-9]+)\/([0-9]+)\/([0-9]+)\/?$ /noticias/$1-$2-$3

Conclusão

O intuito deste artigo foi apresentar o mod_rewrite e mostrar como criar URLs mais amigáveis, tanto para o usuário quanto para os mecanismos de busca. Você pode fazer praticamente qualquer mapeamento de URLs utilizando o mod_rewrite, o que você precisa é identificar um padrão nas URLs do seu site e criar as regras de reescrita. O limite é o da sua criatividade.

Alguns links para artigos semelhantes e recursos interessantes que podem ajudar bastante:

• Artigo de Bill Humphries para o site A list apart que serviu de base para este
• Documentação do mod_rewrite
• Guia de expressões regulares
• Cool URIs don’t change por Tim Berners-Lee
• URL as UI por Jakob Nielsen