Strict Standards: Only variables should be passed by reference in /home2/chato/sites/tejedoresdelweb.com/wiki/skins/GuMax.php on line 191
  • Iniciar sesión

URI y URL

De TW

Saltar a: navegación, buscar
Este artículo ha sido reformateado automáticamente desde http://www.tejedoresdelweb.com/307/article-5671.html y su formato necesita ser revisado
Este artículo es bastante antiguo. Su contenido posiblemente está obsoleto y necesita ser actualizado.

En este documento se muestran los diferentes (pero confluyentes) esfuerzos por dar a la Web un marco en el cual definir una codificación para nombres y direcciones de recursos disponibles en ella. En la Web existe un sinnúmero de objetos, a los que se puede acceder mediante una variedad de protocolos, inventados, en desarrollo o a ser ideados en el futuro. Para poder abstraer la idea de "objeto genérico", se necesita disponer de conceptos que den sentido a nombres y direcciones en la Web.

Un Identificador Universal de Recursos (URI) es un miembro de este conjunto universal de nombres, en un cierto espacio de nombres y con una dirección referida a un cierto protocolo, ambos previamente registrados. un Localizador Uniforme de Recursos (URL), es báciamente un caso particular de URI que expresa una dirección, mapeada a un algoritmo de recuperación del objeto que sua protocolos de comunicación a través de la red. Por último, un Nombre Uniforme de Recursos (URN) es algo que aún está en debate y que pretende definir un espacio de nombres para etiquetar objetos persistentes.

Un recurso es cualquier cosa distinguible. Por ejemplo, un documento electrónico, una imagen, un servicio, etc. Cabe notar que no todos los recursos son recuperables a través de la red (por ej.: seres humanos, corporaciones y libros impresos, que también se consideran recursos). Un recurso es, básicamente, un concepto que puede mapearse a una o a varias entidades, y que puede permanecer constante a pesar de ver alterados sus contenidos.

Diagrama correspondiente a la especificación de URI, URL y URN, según el RFC 23 96.

_______________________________________________________
 |         ________________                              |
 |        |  ftp:          |                             |
 |        |  gopher:       |                             |
 |        |  http:       __|____________                 |
 |        |  etc        |  |  urn:      |                |
 |        |_____________|__|            |                |
 |                URLs  |               |                |
 |                      |_______________|                |
 |                             URNs                      |
 |_______________________________________________________|

Contenido

¿Sintaxis universal?

La pregunta ahora es, ¿por qué es necesario uniformizar identificadores, localizadores y nombres?

La respuesta está en la gran cantidad de protocolos usados hoy en día para encontrar y recuperar recursos en la red, y en la cierta aparición de muchos protocolos más debido al carácter explosivo de la expansión de este campo.

Los sistemas en los que se distribuye toda la información alcanzable utilizan una variedad de plataformas y formatos en constante evolución, que de no ser por los protocolos y convertidores de formato adecuados, no podrían ofrecer el acceso global que se da hoy en día. Sin embargo, esto no es posible de realizar al nivel de direcciones y nombres de los objetos, dado que son usados para identificarlos y distinguirlos. Además, estos nombres y direcciones son "transmitidos" de las más diversas maneras, desde memorándums hasta hipertextos, por lo que debe suponerse que estos identificadores tendrán una larga existencia.

De todas las ideas desarolladas en este aspecto, aparece una característica común mapeable a la idea de un "objeto" y su correspondiente nombre/etiqueta/identificador. De esta manera se puede definir un conjunto de espacies de nombres en los que se dice que existen los objetos.

En la práctica, estos sistemas deben tratar con una mezcla de objetos, definidos por distintas propuestas. De aquí se desprende la necesidad del concepto de conjunto universal de objetos, y por ende del conjunto universal de espacios de nombres. con esto se permite tratar de una manera similar a objetos pertenecientes a espacios de nombres distintos, incluso entre los que tienen características totalmente distintas.

URIs: Identificadores Universales de Recursos

Corresponden a una forma de encapsular un nombre en un espacio de nombres registrados, y etiquetarlo con el espacio de nombres, produciendo un miembro del conjunto universal.

La sintaxis universal permite el acceso a objetos disponibles utilizando protocolos existentes, y es capaz de ser extendida con el tiempo.

Es necesario decir que la especificación de la sintaxis URI no dice nada acerca de las propiedades de los nombres y las direcciones de los espacios de nombres que mapea. Las propiedades salen de la especificación de protocolos y las convenciones de cada esquema.

URLs: Localizadores Uniformes de Recursos

Para los protocolos de acceso a Internet existentes, en la mayoría de los casos se hace necesario definir la codificación del algortimo de acceso en algo suficientemente conciso para llamarse "dirección". Las URIs que referencias objetos a los que se accede mediante protocolos existentes se conocen como URLs.

Aunque muchos esquemas de URLs son bautizados según el protocolo que utilizan, esto no implica que la única forma de acceder al recurso de la URL sea mediante ese único protocolo. En particular, los servicios de gateway, proxy, cache y resolución de nombres pueden llegar a ser usados para acceder a ciertos recursos, independientemente del protocolo original, y la resolución de algunas URLs puede requerir el uso de más de un protocolo (por ejemplo, HTTP y DNS típicamente son usados para acceder un recurso de URL "http" cuando no se encuentre en el cache local).

URNs: Nombres Uniformes de Recursos

Un URN difiere de una URL en que su propósito principal es etiquetar persistentemente un recurso con un identificador. Este identificador es obtenido de un conjunto de espacios de nombres definidos, cada uno de los cuales tiene establecida su propia estructura de nombres y procedimientos de asignación. El esquema "urn" se encuentra reservado para establecer una estandarización de los requerimientos del espacio de nombres URN.

Diseño

Criterios para el diseño

Dentro de los requerimientos críticos para la sintaxis del esquema URI, se encuentran:

  • Que sea extensible. En otras palabras, que pudiesen agregarse nuevos esquemas de nombres a medida que fuese necesario.
  • Que sea completa. Que sea posible codificar cualquier esquema existente
  • Que se pueda imprimir. Si es necesario, un URI debe poder ser "transmitida" usando papel y lápiz, por lo que debe ser posible expresarla usando sólo caracteres ASCII de 7 bits.

Además, hay varios aspectos del diseño relevantes al proceso de transmisión de URIs:

  • Un URI es una secuencia de caracteres, la cual no siempre es representada como una secuencia de bytes.
  • Un URI puede ser obtenido desde una fuente desconectada de la red, y por lo tanto debe consistir de caracteres tipeables en un computador, con la restricciones impuestas por los dispositivos de entrada en cada idioma y configuración local.
  • A menudo se necesita que un URI sea recordado por la gente, y para eso es conveniente que sus componentes tengan algún sentido.

Estos aspectos del diseño no siempre compatibilizan entre sí. Por ejemplo, si se quisiera describir acabadamente una componente de URI caeríamos en la utilización de caracteres prohibitivos para ciertos sistemas. La necesidad de poder transcribir fácil y universalmente un URI fue elegida como prioritaria.

Satisfacción de criterios

Extensibilidad

Se resolvió permitiendo una cadena arbitraria (pero registrada) como prefijo. La selección de los dos puntos (":") como separador entre el prefijo y el resto de la URI fue totalmente arbitraria.

Completitud

Fue satisfecho permitiendo que los nombres extraños (o incluso binarios) se codificaran en base 16 o base 64 usando los caracteres aceptables.

Imprimibilidad

Inicialmente, s pertendió establecer que debía codificarse cualquier carácter que no perteneciese a un set básico; pero la discusión se desvió a definir cuál sería el set básico, considerando que, por ejemplo, los sistemas que manejaran adecuadamente el set de caracteres ISO Latin-1 no tendrían problemas en utilizar esos caracteres localmente, pero que el problema se suscitaría al transportar dichos caracteres. La solución fue especificar un conjunto de caracteres "seguro", y un esquema general de escapado de caracteres que puede utilizarse para escapar caracteres "peligrosos".

Sintaxis

Sintaxis general y componentes principales de URLs

Así como hay diferentes métodos de acceder a los recursos, hay varios esquemas para describir su ubicación.

La sintaxis genérica para URLs provee un marco de trabajo extensible, que permite incorporar protocolos aún no considerados o incluso aún no inventados

Las URL's, como su nombre lo indica, localizan recursos mediante una identificación abstracta. Una vez identificado el recurso, un sistema puede operar de diversas formas sobre él, como por ejemplo realizando accesos, actualizándolo, reemplazándolo o recuperando sus atributos. En general, sólo se necesita especificar el método de acceso para cada esquema URL.

En general, las URLs son de la siguiente forma:

<esquema>:<sección_específica_al_esquema>

Una URL contiene el esquema al cual corresponde, seguido de dos puntos y posteriormente la cadena que localiza al recurso en cuestión, y cuya interpretación pasa a ser responsabilidad del esquema.

Los nombres de los esquemas son secuencias de caracteres, dentro de los que se permiten los literales "a".."z", los dígitos, los símbolos "+", "." y "-". Para evitar confusiones, las interpretaciones de URLs debieran ignorar distinciones entre mayúsculas y minúsculas (por ejemplo, "HTTP" debiera permitirse y significar lo mismo que "http").

Codificación y caracteres especiales

Las URIs están compuestas de letras, dígitos y caracteres con significado especial. Las convenciones sobre los caracteres especiales son las siguientes:

Escape (%)

El signo porcentaje (hexadecimal 25) se usa para anular el significado especial de los caracteres especiales.

Jerarquización (/)

El slash (hexadecimal 2F) se reserva para delimitar substrings de relación estrictamente jerárquica. Las subcadenas "." y ".." son igualmete reserados. EL significado del salsh entre dos segmentos es que el segmento de la izquierda es más significativo que el de la derecha.

Identificador de fragmentos (#)

El carácter "#" (hexadecimal 23) se reserva como delimitador para separar la URI de un objecto de un identificador de fragmento (resuelto en el cliente).

Prefijo de consulta (?)

Delimita la URI de un objeto suscetpible de ser consultado, de la subcadena que representa la consulta en sí misma. Cuando se usa una URI con una consulta, la URI resultante referencia al objeto que resulta de aplicar la consulta al objeto original. Dentro de la cadena de consulta, el símbolo "+" se reserva como una abreviación del espacio (" "). Por lo tanto, paa colocar un signo "+" tal cual debe codificarse. Este método fue establecido para facilitar el traspaso de URIs con consultas a sistemas que no permiten espacios.

Otros (*, !)

EL asterisco ("*", hexadecimal 2A) y el signo de exclamación ("!", hexadecimal 21) se reservan para darles un significado especial dentro de los esquemas específicos.

Además, la forma canónica de las URIs establece que algunos caracteres, como el espacio (" "), caracteres de control, aquellos que varián su codificación en ASCII de 7 bits al pasar de un set nacionalizado a otro, y todos los caracteres de 8 bits más allá del 7F hexadecimal (DEL) del set ISO Latin-1, nodebieran usarse sin codificar. Esta codificación utiliza el símbolo de escape "%", seguido por dos sígitos hexadecimales (0-9, A-F), que corresponden al código del craácter en ISO Latin-1.

Jerarquizaciones y formas relativas de URIs

Cuando se referencia una URL absoluta desde el contexto de un documento, se está incluyendo mucha información tal vez ya conocida, y que podría extraerse del contexto del documento original (como por ejemplo el esquema, la ubicación dentro de la red, y partes de la ruta de acceso). En estos casos es cuando se justifica usar URL's relativas. En ellas se identifica el recurso describiendo la diferencia con un espacio de nombres jerárquico ente el contexto actual y un identificador absoluto del recurso

Algunos esquemas URI soportan un sistema de nombres jerárquico, donde la jerarquía del nombre se denota por el delimitador "/" ente componentes del esquema. Esta forma de jerarquización es independiente del esquema y puede ser usada junto con una URI "base" para producir otra URI.

Esquemas y Aplicaciones

Algunos de los esquemas URL existentes hoy en día son:

ftp                     File Transfer protocol
http                    Hypertext Transfer Protocol
gopher                  The Gopher protocol
mailto                  Electronic mail address
news                    USENET news
nntp                    USENET news using NNTP access
telnet                  Reference to interactive sessions
wais                    Wide Area Information Servers
file                    Host-specific file names
prospero                Prospero Directory Service

Sintaxis usual

Mientras que la sintaxis para el resto de la URL puede variar dependiendo del esquema del que se trate, los esquemas URL que incluyen el uso directo de un protocolo basado en IP a un host específico en Internet usan una sintaxis común para la parte específica al esquema:

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

Algunas de o todas las partes (exceptuando <host>) pueden ser omitidas. Se comienza con un doble slash para indicar que se ajusta a la sintaxis común de Internet. Cada una de las partes se explica a continuación:

user

Algunos esquemas (como el ftp) permiten especificar un username (opcionalmente)

password

Si se presenta, debe estar separado del username por dos puntos (":") El username (o el password), de estar presente, debe ir seguido de un símblo arroba "@" al final. Dentro del username y el password, cualquier ":", "@" o "/" debe estar respectivamente codificado.

host

Un nombre de dominio (completo) o host, o su dirección IP.

port

El número del puerto al cual conectarse. La mayoría de los protocolos tienen ya un número de puerto asignado por defecto.

url-path

El resto corresponde a datos específicos del esquema, y contiene detalles de cómo el recurso especificado debiera ser accedido. El "/" entre el host (o número de puerto) y el url-path noes parte del url-path.

Ejemplo: FTP

El esquema URL para FTP es usado para designar archivos y directorios en hosts alcanzables por medio del protocolo FTP en Internet.

Una URL de FTP sigue la sintaxis usual descrita anteriormente. Si se omite :<port>, se toma el valor por defecto, 21

Nombre y password

Si se especifican un username y password como se definió en el punto anterior, éstos se utilizan en los comandos ftp "USER" y "PASS" luego de realizar la conexión con del servidor FTP. Si no se provee ninguno de los dos y el servidor los requiere, se utilizan las convenciones de FTP anónimo, que son:

  • Se suministra el usename "anonymous".
  • El password entregado es la dirección e-mail del usuario accediendo al recurso.

Si la URL incluye un username pero no un password, y el servidor remoto requiere un password, el programa que esté interpretando la URL FTP debiera pedírselo al usuario.

url-path de FTP

El url-path de una URL FTP tiene la siguiente sintaxis: <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode> Donde <cwd1> hasta <cwdn> y <name> son cadenas (posiblemente codificadas) y <typecode> es uno de los caracteres "a", "i" o "d". Esta última parte puede además ser omitida, así como también toda la parte del url-path (incluyendo el "/"). El url-path es interpretado de la siguiente forma:

  • Cada uno de los elementos <cwd> es suministrado como argumento al comando CWD, secuencialmente.
  • Si el <typecode> es "d", realizar un comando NLST (listar nombres) con <name> como argumento, e iterpretar los resultados como un listado de directorio.
  • De otro modo, ejecutar un comando TYPE con <typecode> como argumento, y luego acceder al archivo cuyo nombre es <name> (usando, por ejemplo, el comando RETR)

Implicancias, Críticas y Limitaciones

Registro de nuevos esquemas

Se introduce un nuevo esquema, definiendo el mapeado correspondiente según la sintaxis de URLs, y usando un prefijo nuevo. En particular, los esquemas URL en experimentación son utilizables en común acuerdo entre las partes involucaradas (los esquemas con nombres que comiencen en "x-" se reservan para experimentación).

Se mantiene un registro de esquemas URL, a cargo de IANA (Internet Assigned Numbers Authority). Cualquier proposición de esquema URL debe incluir la definición de un algoritmo de acceso a recursos localizables dentro de ese esquema, y la sintaxis para representarla.

Los esquemas deben ser (demostrablemente) útiles y operables. Deben tratar, además, de seguir las mismas convenciones sintácticas de los ya existentes.

Seguridad

Un esquema URL no es en sí una amenaza a la seguridad. Los usuarios debieran estar al tanto de que no hay una garantía general de que una el objeto referenciado por una URL sea siempre el mismo.

La amenaza de seguridad relativa a las URLs consiste en que algunas veces es posible construir una URL tal que un intento por realizar alguna operación inocua (como recuperar el objeto) cause en realidad una operación remota peligrosa. Esta URL insegura aparece por lo general cuando se especifica un puerto distinto del asignado por defecto al protocolo en cuestión. El cliente desinformadamente contacta a un servidor que está atendiendo oyto protocolo por ese puerto; y los contenidos de la URL le proveen instrucciones le proveen instrucciones a este protocolo, que pueden causar resultados inesperados. (Por ejemplo, gonectar a un cliente gopher al pueto SMTP de un servidor puede ocasionar que se distribuyan mensajes de contenido "bizarro", por decir lo menos). Es por esto que se debe ser muy cauteloso al usar una URL que especifique un puerto distinto de asignado al protocolo, sobre todo cuando este nombre "choca" con alguno también ya definido.

Otro riesgo se da cuando la url contiene (codificados) delimitadores para un cierto protocolo (por ejemplo, CR y LF en el caso de telnet) que no hayan sido decodificados antes de ser transmitidos. Esto ocasionaría que se simulara un parámetro u operación extra, causando tal vez que se ejecutara alguna operación dañina.

Por último, es obviamente no recomendable el utilizar URLs que contenags passwords que no deban ser dadas a conocer

Referencias

  • Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994.
  • Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994.
  • Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9,
    1. RFC 959, USC/Information Sciences Institute, October 1985.

Apendice: Gramática para URI

La siguiente es la gramática en BNF que corresponde a la especificación de URI.

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
   absoluteURI   = scheme ":" ( hier_part | opaque_part )
   relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]
   hier_part     = ( net_path | abs_path ) [ "?" query ]
   opaque_part   = uric_no_slash *uric
   uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                   "&" | "=" | "+" | "$" | ","
   net_path      = "//" authority [ abs_path ]
   abs_path      = "/"  path_segments
   rel_path      = rel_segment [ abs_path ]
   rel_segment   = 1*( unreserved | escaped |
                       ";" | "@" | "&" | "=" | "+" | "$" | "," )
   scheme        = alpha *( alpha | digit | "+" | "-" | "." )
   authority     = server | reg_name
   reg_name      = 1*( unreserved | escaped | "$" | "," |
                       ";" | ":" | "@" | "&" | "=" | "+" )
   server        = [ [ userinfo "@" ] hostport ]
   userinfo      = *( unreserved | escaped |
                      ";" | ":" | "&" | "=" | "+" | "$" | "," )
   hostport      = host [ ":" port ]
   host          = hostname | IPv4address
   hostname      = *( domainlabel "." ) toplabel [ "." ]
   domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
   toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
   IPv4address   = 1*digit "." 1*digit "." 1*digit "." 1*digit
   port          = *digit
   path          = [ abs_path | opaque_part ]
   path_segments = segment *( "/" segment )
   segment       = *pchar *( ";" param )
   param         = *pchar
   pchar         = unreserved | escaped |
                   ":" | "@" | "&" | "=" | "+" | "$" | ","
   query         = *uric
   fragment      = *uric
   uric          = reserved | unreserved | escaped
   reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                   "$" | ","
   unreserved    = alphanum | mark
   mark          = "-" | "_" | "." | "!" | "~" | "*" | "'" |
                   "(" | ")"
   escaped       = "%" hex hex
   hex           = digit | "A" | "B" | "C" | "D" | "E" | "F" |
                           "a" | "b" | "c" | "d" | "e" | "f"
   alphanum      = alpha | digit
   alpha         = lowalpha | upalpha
   lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
              "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
              "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
   upalpha  = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
              "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
              "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
   digit    = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
              "8" | "9"
Este artículo fue escrito por Cristian Gutierrez en 2001