[RT] Tarea 1: RFC 1738 "Uniform Resource Locators (URL)"

Introducción

El documento RFC1738 establece la la sintaxis y semántica para realizar una cadena de caracteres que representa un recurso en internet. Éstas cadenas son llamadas URL (Uniform Resource Locator, Localizador de Recursos Uniforme).

Los recursos en internet pueden ser documentos de texto, multimedia, etcétera.

Las URL fueron utilizadas por primera vez por Tim Barners-Lee en el año de 1991 para establecer el uso de hipervínculos en la web

Las URL son mejor conocidas como "direcciones de internet" y por medio de ellas el navegador puede localizar el contenido en la web y mostrarlo correctamente; cabe mencionar que existe una dirección única para todos y cada uno de los recursos disponibles en la web.

A continuación explicaré  un poco de qué de habla en cada uno de los puntos del documento.

Fuente: http://www.grafikamarketing.com/blog/?p=568

2. Sintaxis general de las URL

En ésta sección se nos habla sobre los diferentes métodos que existen para accesar a los recursos en línea y los distintos esquemas que son permitidos, así como la sintaxis permitida.

Se menciona también la posibilidad de añadir nuevos esquemas y protocolos a los ya establecidos gracias al framework incluido en el sistema de sintaxis general.

2.2 Las partes de las URL's

En general, las URL's se escriben siempre de la siguiente manera:

<esquema>:<parte-especifica-del-esquema>

El esquema, seguido de dos puntos y a continuación una cadena que es específica para cada esquema y se interpreta dependiendo del esquema utilizado.

El esquema es una sencilla secuencia de caracteres en cuya sintaxis solo se admiten:

• Letras en minúscula ("a"-"z") (Mayúsculas se interpretan como minúsculas)
• Digitos (0 - 9)
• Solo algunos caracteres especiales ("+", ".", "-")

2.2 Problemas de codificación en los caracteres de las URL

Como ya vimos, las ULR's son secuencias de diferentes caracteres  cuya interpretación depende del esquema a utilizar, pero, ¿qué pasa si ciertos caracteres son utilizados para otros fines en cierto esquema? Por ejemplo, las letras "abcdef" pueden ser utilizadas también como valores hexadecimales.

La solución al problema fue codificar los caracteres que estuvieran reservados para otros fines, y para ello se utilizo el código ASCII.

Los caracteres presentes del código ASCII se codifican utilizando valores hexadecimales desde 00 hasta FF dando el total de los 256 caracteres  El par de valores hexadecimales correspondiente a cada caracter se complementa con el símbolo "%".

Algunos ejemplos de caracteres que pueden ser utilizados de forma insegura son:

• "<" y ">" ya que sirven de delimitadores en las URL
• """ (comillas) se usa como delimitador en algunos esquemas
• "#" sirve para delimitar en las URL fragmentos o anclas
• "%" pues se usa para codificar caracteres especiales
• "=", "&" y "?" para enviar datos de formularios por el método GET

Así, por ejemplo:

• El caracter dos puntos ":" se codifica como %3A
• El caracter diagonal "/" se codifica como %2F
• Las letras "a,b,c,d,e,f" se codifican como %61, %62, %63, %64, %65 y %66

En ésta tabla se muestra la codificación de los demás caracteres especiales.

2.3 Jerarquía

Aquí se obedece el mismo ordenamiento jerárquico que vemos en los sistemas de archivos de las computadoras. Los recursos alojados en un servidor obedecen la forma

medio de almacenamiento > carpeta > subcarpeta > recurso

En algunos esquemas como el HTTP y FTP, la jerarquía de los recursos suele separarse por el caracter "/"

medio de almacenamiento/carpeta/subcarpeta/recurso

3. Los esquemas

Los esquemas permitidos en el éstandar de las URL's son:

Esquema	Descripción
ftp	Protocolo para transferencia de archivos
http	Protocolo de transferencia de hipertexto
gopher	Protocolo Gopher
mailto	Dirección de correo electrónico
news	Noticias de USENET
nntp	Noticias de USENET utilizando acceso NNTP
telnet	Referencia para sesiones interactivas
wais	Servidores de información de área amplia
file	Nombres específicos de archivos en un host
prospero	Servicio de directorio de prospero

Como podemos ver, la mayoría de los esquemas son nombres de protocolos de comunicación que ya conocemos

3.1 Sintaxis para el esquema común de internet

Éste esquema es el que se utiliza para accesar a las páginas web por medio de los protocolos basados en IP, la sintaxis especificada para éste esquema obedece la forma:

//<user>:<password>@<host>:<port>/<url-path>

Como se puede ver, la sintaxis no resulta familiar, ésto es porque en el esquema HTTP, FTP y otros las partes<user>:<password>@, :<port> y <url-path> no son necesarias y no se requiere escribirlas en el navegador. El caracter "//" (doble diagonal) indica que la URL a proporcionar cumple con la sintaxis del esquema comun de internet.

Explicando cada uno de los componentes de la sintaxis:

• user: Algunos servidores requieren del nombre de un usuario que tenga autorizado el acceso.
• password: Una vez proporcionado el nombre de usuario autorizado, se proporciona la contraseña para autenticar la cuenta.
• host: Es un nombre o dominio calificado o la dirección IP del servidor.
• port: El número de puerto donde se está ejecutando el servicio al que intentamos accesar.
• url-path: El resto de la URL que ayuda a localizar algun recurso.

Como prueba, si cuentan con módem de la compañía TELMEX, verán que si acceden a la dirección http://192.168.1.254 (la dirección del módem)  saltará una ventana que les pedirá autenticarse para accesar a las configuraciones del módem,  pueden saltarse esta ventana (y comprobar el esquema que acabamos de explicar) escribiendo en la barra de direcciones:

http://TELMEX:wepkey@192.168.1.254/

donde sustituyen la palabra "wepkey" por la wep-key original de su módem (la encuentran pegada en la etiqueta del mismo)

Cabe mencionar que se le llama "sintaxis común" ya que la misma sintaxis o partes de la sintaxis se utilizan por la mayoría de los esquemas.

3.2 FTP

Se utiliza para localizar y acceder a archivos y directorios disponibles en internet utilizando el protocolo FTP.

La sintaxis es la misma a la utilizada en el punto 3.1.

Se pueden proveer los campos "user" y "password" dependiendo de los permisos del servidor y el campo "port" se omite ya que el puerto por default es el 21.

El campo "url-path" obedece la sintaxis del punto 2.3, exceptuando el medio de almacenamiento el cual es directamente el host al que estamos accediendo.

3.3 HTTP

Utilizado para designar a los recursos accesibles utilizando el protocolo HTTP, la sintaxis para una URL HTTP es de la forma:

http://<host>:<port>/<path>?<searchpath>

Los campos ya fueron explicados en el punto 3.1, en éste caso el campo "port" suele omitirse porque el puerto por default es el 80. El campo "searchpath" se utiliza para peticiones de tipo GET

3.4 GOPHER

Esquema para designar los recursos accesibles por medio del protocolo GOPHER.

La sintaxis de una URL GOPHER tiene la forma

gopher://<host>:<port>/<gopher-path>

El campo "port" puede ser omitido ya que el puerto por default para GOPHER es el 70. Actualmente ya no existen muchos servidores de éste tipo y la mayoría de los navegadores han abandonado su soporte debido a ciertas vulnerabilidades.

GOPHER se especifica en el documento RFC 1436

3.5 MAILTO

Se utiliza para designar a las direcciones de correo de internet de alguna persona o servicio. Las URL's de éste esquema no representan un objeto accesible directamente y la mayoría de los navegadores lo relacionan con algún tipo MIME.

La sintaxis es: <mailto>:<rfc822-address-spec>

Los demás esquemas son menos conocidos y mucho más especificos.

4. Para el registro de nuevos esquemas

La IANA (Internet Assigned Numbers Authority) se encarga de mantener el registro de nuevos esquemas de URL's. Si se quiere proponer un nuevo esquema es necesario incluir el algoritmo que permite localizar los recursos en internet junto con la especificación de la sintaxis (teniendo como base éste estándar) y la descripción cada campo necesario para acceder a un recurso en internet.

Algunos esquemas que se encuentran en lista de espera para su aprobación son:

Esquema	Descripción
afs	Andrew File System global file names/td>
mid	Message identifiers for electronic mail
cid	Content identifiers for MIME body parts
nfs	Network File System (NFS) file names
tn3270	Interactive 3270 emulation sessions.
mailserver	Access to data available from mail servers.
z39.50	Access to ANSI Z39.50 services.

6. Seguridad

En éste punto se discuten los asuntos de seguridad con las URL's. Hace una aclaración importante que resulta ser cierta, en sí, las URL no representan ningún tipo de amenaza contra la seguridad de los usuarios ya que solo se limitan a apuntar a un recurso en internet, tampoco ofrecen ninguna garantía de si el recurso esta disponible o no en la red, es responsabilidad del usuario verificar que la URL no apunte a un recurso equivocado o peligroso; ésto se puede hacer analizando la URL ver si el recurso al que apunta es el requerido o si dentro de la URL se incluye un número de puerto diferente al reservado para ofrecer el protocolo de comunicación.

Critica constructiva

Al ir leyendo poco a poco el estándar de las URL me di cuenta que es un estándar bastante completo, que prevee todos los posibles escenarios que puedan existir, desde sintaxis y semántica, pasando por un framework que permite la actualización y crecimiento del mismo.

La única critica que tengo respecto al estándar es sobre la manera en la que se deslinda de los problemas de seguridad; si bien el único trabajo de las URL es apuntar a un recurso o servicio en internet, debería de existir algún método de garantizar la seguridad de los usuarios. Cabe mencionar que en la actualidad hay programas antivirus que son capaces de detectar cuando una conexión maliciosa está siendo establecida para así proceder a detener la transmisión y recepción de paquetes desde esa URL, no hay un método generalizado (tomando en cuenta por ejemplo los equipos que no cuentan con programas antivirus) que otorgue seguridad a todos los usuarios. 

Es necesario crear un sistema que permita verificar la integridad de los recursos que se ofrecen en internet, si bien el problema de un recurso inexistente es resuelto con un simple mensaje de error por parte del navegador, también puede existir un sistema que indique cuales recursos son seguros y cuales no para evitar posibles amenazas de seguridad, ya sea por DNS especializados, o algún tipo de índice estándarizado en los navegadores.

Pienso que así se podrían evitar tantos problemas de seguridad para los usuarios.

Por todo lo demás, parece que el estándar de las URL's es muy completo y sencillo de aprender.

Referencias

• http://tools.ietf.org/html/rfc1738