En la web se puede subir cualquier fichero, código en Perl, y el sistema internamente analiza el código conforme a las reglas específicas de un buen programador de Perl. Tiene cinco niveles de gravedad: gentle (gentil), stern (severo), harsh (duro), cruel y brutal.

Es un buen punto de inicio para refactorizar nuestro código, ya que lo adaptamos al uso de buenas prácticas y hacemos que el código deje de ser, tal y como catalogan a todos los códigos hechos en Perl, de tipo write-only (solo escritura).

El código de Perl::Critic está disponible también, como software libre (GPL), en CPAN, por lo que puede ser instalado de forma local para poder hacer las pruebas de código sin necesidad de subir código a la web.

A través del propio CPAN se puede descargar e instalar:

perl -MCPAN -e "install Perl::Critic"

En el fichero README nos da un ejemplo sencillo de como hacer el validador:

use Perl::Critic;
my $file = shift;
my $critic = Perl::Critic->new();
my @violations = $critic->critique($file);
print @violations;

Poniendo esto en un script Perl, ya solo tendríamos que ejecutarlo pasando el nombre de fichero como parámetro que queramos comprobar. Sencillo, ¿no?

Conceptos

Antes de comenzar a entrar en el tema, vamos a definir algunos conceptos muy útiles y a tener en cuenta, para no perdernos. Es importante conocer estas palabras y el significado que conllevan para poder entender, a posteriori, cómo funciona el sistema web:

• web: en inglés, telaraña, se refiere al entramado que se imagina cuando de una página se pasa a otra enlazándose entre sí todas ellas, formando una imagen como de telaraña, o web.
• URL: Uniform Resource Locator, o lo que quiere decir como Localizador de Recurso Uniforme. En sí es la dirección completa de un recurso que se solicita a través de Internet (y más específicamente del protocolo HTTP). Este tiene la forma:

  http://host:port/uri

  o

  https://host:port/uri

• URI: Uniform Resource Identifier, o Identificador de Recurso Uniforme. Lo que es la parte de la ruta dentro de la URL, como se había visto más arriba. La URI puede contener, a su vez, particiones, que se indicarán con la barra inclinada (/) y zona de consulta, que comenzará con el signo de interrogación (?) y tendrá pares de clave valor separados entre sí por el signo de igualdad (=) y entre cada par por el símbolo del ampersand (&):

  /miruta/mifichero.ext?clave1=valor1&clave2=valor2

• Host: del inglés máquina. Se refiere al nombre del servidor donde se alberga la URI que se solicita. El nombre debe de ser un nombre que se pueda resolver vía DNS, pudiendo ser un conjunto de letras, símbolos (válidos: guión (-) y subrayado (_)) y números: www.midominio.com
• Port: o puerto. Es el número en el que escucha el servidor web. No hace falta indicarlo explícitamente, a menos que sea diferente del puerto estándar, que es el 80. Se indica en formato decimal.
• Servidor web: es el programa que se mantiene a la escucha para atender las peticiones de los navegadores, a modo de servir las páginas web. También puede ejecutar códigos para generar páginas, imágenes y otros contenidos para cada petición. Hay servidores de pago y gratuitos, y libres, algunos ejemplos de los más usados: Apache, Cherokee y Microsoft IIS.
• Navegador web: es una aplicación de escritorio que permite, dando una URL, visualizar una página web, escrita en lenguaje HTML. Los navegadores web tienen la posibilidad de emplear plugins de forma que puedan: reproducir vídeos, sistemas interactivos Java, Flash, Silverlight, …; reproducir audio, usar hojas de estilo, o código JavaScript…; algunos ejemplos de navegadores web más usados son: Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Opera y Safari.

Peticiones: modo Cliente/Servidor

El sistema web se diseño para ser de modo cliente/servidor. Eso quiere decir que hay un elemento activo, en este caso el navegador web, que haría las veces de cliente, y un elemento pasivo, en este caso el servidor web, que haría las veces de servidor.

La dinámica siempre es la misma, el cliente realiza una conexión a través de la red para solicitar una página web, mediante una URL, y el servidor responde a esta URL con un mensaje en el que puede indicarle el contenido de lo solicitado (200 OK), que no encuentra la página (404 Not Found), que no tiene acceso a ese recurso (403 Forbidden), que necesite autenticarse antes (401 Authorization Required), que el recurso solicitado está en otra ubicación (302 Redirect), etc.

Formato de las Peticiones

Las peticiones pueden ser de varios tipos, pero básicamente, se nombran, para navegadores, dos: GET y POST. Cuando un cliente realiza una petición de URL de forma normal, esta se realiza siempre vía GET. En cambio, cuando se realiza mediante el envío de un formulario, presionando en el botón de tipo submit de una página web, este puede realizarse mediante POST (a menos que se explicite, en el propio código HTML, que se hará mediante GET u otro método que soporte el navegador web).

Por tanto, una petición se envía en formato texto, como sigue:

GET / HTTP/1.1
Host: www.google.es
User-Agent: Mozilla Firefox
Connection: close

La petición se divide en:

• Primera línea: es en la que se especifica el método de solicitud, seguida por la URI, y por último el protocolo usado (normalmente HTTP/1.1).
• Cabeceras: es el espacio destinado a dar información al servidor sobre la solicitud. Las cabeceras son frases cortas de letras y guiones que terminan con los dos puntos (:), para dar lugar al valor de la clave. El host se indica siempre para informar al servidor del dominio al que queremos solicitar la página, así como el user-agent, en el que le informamos desde qué navegador (o tipo de navegador) estamos realizando la petición. En este enlace se puede ver cómo se construyen los user-agent para cada navegador, y el porqué son tan largos.
• Cuerpo del mensaje: una petición de tipo GET no suele tener cuerpo de mensaje, por lo que no se especifica una cabecera de tipo Content-lenght, que indicaría que hay cuerpo de mensaje, y el tamaño del mismo. También se puede indicar que el contenido irá por trozos. Entre la línea de cabeceras y el cuerpo, se deja siempre una línea en blanco.

Formato de la respuesta

La respuesta que emite el servidor viene formada por una serie de líneas de texto en las que se indica el protocolo en el que se responde (normalmente HTTP/1.1), seguido de tres dígitos, el código de retorno, y un texto informativo sobre el retorno.

Al igual que en el caso de la solicitud, se incluyen cabeceras, y el cuerpo de la respuesta, que está separado de las cabeceras por una línea en blanco. Un ejemplo:

HTTP/1.1 200 OK
Date: Tue, 16 Nov 2010 02:30:00 GMT
Server: Apache/2.2.9 (Debian)
Content-Length: 4
Content-Type: text/plain

hola

En este caso, como se puede ver, el servidor también responde informando de su huella (la cabecera Server), donde especifica el tipo de servidor que es. En este caso, la respuesta tiene cuerpo de mensaje, de 4 bytes y de tipo texto plano (en formato MIME: text/plain).

Tipos de Respuestas

Las respuestas que puede dar un servidor web pueden ser:

Para más información sobre los códigos se puede ver el anexo de códigos HTTP de la wikipedia.

Cookies

Debido a que el sistema web es lo que se conoce como stateless, es decir, que cada petición se realiza independientemente de las anteriores y siguientes, por lo que, en muchos sitios, para poder establecer una sesión o identificar a un usuario para poder usar sus preferencias preguardadas, o información sobre su navegación en nuestro sitio, se usan las polémicas cookies.

Una cookie es un dato que indica el servidor para el cliente, que debe de almacenarlo y enviarlo cada vez, hasta que se cumpla el tiempo límite en el que expira. Por ejemplo:

HTTP/1.1 200 OK
...
Set-Cookie: name=value; expire=Tue, 16-Nov-2010 15:00:00 GMT; path=/; domain=www.google.es
...

Las cookies tienen 4 partes,

• la primera se establece el par clave-valor, esto quiere decir que se establece, como si de una variable se tratase, el nombre de la cookie, con el valor que contendrá,
• la segunda es la expiración de la cookie, o caducidad. Pasada esa fecha, la cookie debe de ser destruida del navegador web para no volver a ser usada,
• la ruta, en la tercera posición, es la URI base de la que cuelga la cookie. Para tenerla como referencia en su uso, y solo enviar la cookie cuando la ruta base se cumpla en la URI solicitada.
• por último, se especifica el dominio para el que se configura la cookie. Este debe de ser igual a la cabecera host enviado en la petición, a menos que haya cambiado de dominio.

Una vez el servidor ha enviado esta información al navegador web, el navegador almacena (o solicita antes si se desea almacenar) dicha información como cookie, para reenviarla cada vez que se visite el dominio con la misma URI base. El navegador realiza las peticiones de la siguiente forma:

GET / HTTP/1.1
Host: www.google.es
Cookie: name=value
...

El tema de las cookies y la privacidad ha sido muy discutido y hay legislaciones (la de EEUU y Europa) que han incluido artículos para su regulación, ya que puede ser empleado como un medio para minar nuestra privacidad. Esto se puede leer de forma más amplia en este enlace.

Conclusiones

El protocolo HTTP, en el que se basa el sistema web, es el más usado en internet, junto con el correo electrónico. Con este artículo se pretende dar una visión un poco más a bajo nivel sobre cómo funciona dicho sistema, y se espera ampliar en un futuro con más artículos referentes a otros aspectos que conforman y completan al propio protocolo.

Tener este tipo de URLs, o URIs en nuestro dominio, se puede hacer mediante la creación de directorios y especificando los ficheros dentro de los mismos que tengan los nombres (sin extensión) que queremos que se visualicen en la barra del navegador… pero no es nada útil y es complejo, sobre todo cuando se usan entornos como WordPress o similares, donde el contenido de la base de datos dicta lo que aparece en la página, y es totalmente dinámico.

La solución que se puede emplear: rewrite. En Apache, a través del módulo mod_rewrite, se pueden crear reglas de redireccionado de modo que una URL que es:

http://midominio.com/?p=129&a=crea-usuario

Se puede convertir en:

http://midominio.com/crea-usuario/129

En el caso concreto, tan solo bastaría con agregar un bloque de configuración como el siguiente:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/(.+)/([0-9]+)$    /index.php?p=$2&a=$1

Para más información vea la documentación oficial de Apache.