Rafael Marin

[update] O Emanuel fez uma consideração importantíssima: se o servidor/DNS não está preparado a receber determinado site sem o www, o endereço será visto como inválido e, logo, não funciona a solução abaixo. Alguém tem uma solução, ou sabe a origem exata dessa questão de alguns sites funcionarem sem o prefixo e outros não?

O Emanuel começou um post muito interessante, defendendo a não utilização de www no início dos endereços. E ele está certíssimo. Quer um bom motivo?

Por padrão, os browsers atuais já reconhecem o protocolo HTTP como o padrão. Isso quer dizer que quando o browser faz a requisição ao servidor, já inclui o http://, e o www é apenas um subdomínio, indicando redundantemente o propósito da requisição. Seria o mesmo que incluir um subdomínio em um endereço de e-mail como rafael@mail.rafaelmarin.net.

Digitar, então, o www no início é apenas uma perda de tempo. Muitos sites funcionam sem que o www seja digitado, mas outros ainda são inacessíveis sem este prefixo. O Emanuel preferiu não trazer nenhuma solução prática para resolver este problema. Mas eu trouxe.

Ora bolas, o que fazer?

O objetivo é criar um redirecionamento, onde sites digitados sem www funcionem da mesma maneira. Em geral, alguns servidores permitem isso automaticamente (teste o seu). Caso não funcione, no seu arquivo .htaccess, acrescente as seguintes linhas de código:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.dominio\.com$ [NC]

RewriteRule ^(.*)$ http://dominio.com/$1 [R=301,L]

Não esqueça de que o mod_rewrite deve estar habilitado para que esta alteração faça efeito.

Se temos direito de ir e vir, por que não teríamos o de escolher entre digitar www ou não? É pura perda de tempo. Ah, e existe até o site No-WWW, que valida seu site e sustenta uma campanha contra o uso do www.

Embora o XHTML devesse ser servido com o MIME application/xhtml-xml, nem todos os browsers estão aptos a entender este MIME Type. Neste contexto, técnicas de negociação de conteúdo - ou content negotiation em inglês - podem ser utilizadas para enviar ao agente de usuário diferentes MIME Types, de acordo com o que cada um deles aceita. A esmagadora maioria utiliza o MIME Type text/html para servir documentos XHTML, embora não seja a maneira correta. De acordo com a nota não-normativa da W3C, XHTML Media Types,

‘application/xhtml+xml’ SHOULD be used for serving XHTML documents to XHTML user agents. Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as ‘text/html’ and XHTML documents as ‘application/xhtml+xml’.

Ou seja, o autor que deseja dar suporte tanto para user agents XHTML quanto para HTML, deve utilizar negociação de conteúdo para servir documentos com o MIME Type adequado a situação. Um simples script em PHP resolve o problema:

<?php
if (stristr($_SERVER[HTTP_ACCEPT], “application/xhtml+xml”) ||
stristr($_SERVER["HTTP_USER_AGENT"], “W3C Validator”)) {
header(”Content-Type: application/xhtml+xml; charset=iso-8859-1″);
header(”Vary: Accept”);
echo(”<?xml version=\”1.0\” encoding=\”iso-8859-1\” ?>\n”);
} else {
header(”Content-Type: text/html; charset=iso-8859-1″);
header(”Vary: Accept”);
}
?>


O script verifica se o agente de usuário suporta o application/xhtml+xml, ou se o agente de usuário é o W3C Validator. Caso um deles seja verdadeiro, o documento é servido como application/xhtml+xml, caso contrário, ele é servido como text/html. Além disso, se um deles for verdadeiro, o documento recebe a declaração XML.

O cabeçalho Vary: Accept é enviado para que agentes intermediários de cache, como proxy servers, saibam que o MIME Type varia, de acordo com o suporte que o agente de usuário oferece.

O benefício disso tudo é que em browsers como Firefox e Mozilla, que suportam o MIME Type application/xhtml+xml, o código XHTML é tratado como XML no que se refere a intolerância a erros. Ou seja, se um documento XHTML, com MIME Type application/xhtml+xml possuir erros de sintaxe, estes browsers não irão mostrá-lo, assim como acontece com o XML inválido. Somente serão exibidos os documentos assim que os erros de sintaxe estiverem corrigidos. Assim, nem o W3C Validator é necessário para apontar erros.

Veja também

• Content negotiation - 456 Berea Street
• Content negotiation, AdSense, and comments - 456 Berea Street
• Content negotiation - Japs.etc.br