Bases de la web ii:
uniform resource locators (url)

Copyright © Eduardo G. Mercovich 1996.

Resúmen

En la nota de Cliente-Servidor y HTTP vimos algunos conceptos básicos como arquitectura cliente-servidor y HiperText Transfer Protocol, el lenguaje que utilizan para comunicarse entre ellos.

En esta nota veremos cómo se hace para ubicar algo en la Web, es decir cómo se especifican las direcciones y repasaremos el significado del famoso http://.


Contenidos

  1. Resumen
  2. Nota
    1. Conceptos
      1. El problema
      2. La especificación y su uso
    2. URL relativos
    3. ¿Y los URN?
    4. OK, finalizando
  3. Bibliografía
  4. Apéndices
    1. Algunas definiciones.
    2. Algunos esquemas usuales de URL
  5. Autor

Nota

Conceptos

El problema

Si yo les tengo que indicar cómo llegar hasta un lugar cualquiera como el Obelisco y les tengo que dar instrucciones necesito indicarles en qué viajar y cómo hacerlo.

Por ejemplo, si vas en subte bajate en la estación 9 de Julio; si vas en auto desde el norte agarrá corrientes hasta el 0 de altura, si vas en el bondi número tal, bajate en la parada X.

De la misma manera, si quiero ubicar algo en la Web tengo que especificar:

La respuesta a este problema fue plasmada por el correspondiente IETF (Internet Engineering Task Force, es decir algo así como Grupo de Trabajo de Ingeniería de Internet) hace un par de años y -cosa increíble- sigue casi sin cambios desde entonces.

El nombre general es URI [§], Universal Resource Identifier que incluye a los URL [§] y URN [§].

¡Alto! No desesperen por las siglas, ya explicaremos que es cada una de ellas.

La especificación y su uso

La forma general de la especificación es:

nombre-de-esquema://nombre-de-usuario:palabra-clave@host:port/camino-del-objeto

(palabra-clave es password); host [§], esquema [§], camino [§] y objeto [§] están definidos.

Este formato general se llama CISS (Common Internet Scheme Sintax, Sintaxis Común de Esquemas de Internet).

Muchos dirán que eso es mucho mas largo de lo que usualmente se ve. Tienen razón. :-)

Lo que pasa es que existen estándares (o defaults, datos tomados por omisión, excepto que se indique algo en contrario) para muchas porciones de la forma.

Por ejemplo cada esquema o protocolo tiene un port estándard asociado de manera que excepto que el server esté configurado extrañamente fuera de lo normal, no hace falta indicar el port.

Si seguimos con las analogías de las direcciones, si yo te doy la dirección de una persona y no te digo ni piso ni departamento vos asumís que es una casa. Si te doy piso y ningún departamente asumís que hay un sólo depto por piso. Si no te doy piso o departamento y es un eduficio, preguntás al portero o encargado.

Los URL funcionan igual.

Veamos un ejemplo de la vida real.

El URL para el sitio en la Web de GaiaSur es: http://planeta.gaiasur.com.ar.

Como ven a primera vista, el www no es necesario, sólo en una costumbre que en este caso no fue considerada relevante por los autores del sitio.

Analizando el URL vemos primero el esquema, es decir http. Esto indica al cliente (el browser en el caso de la Web) que debe "hablar" con un server HTTP o sea que debe utilizar el protocolo http cuando "llame" a esa dirección (en el ejemplo de las direcciones en que idioma deben hablar cuando en una ciudad cosmopolita tocan un timbre).

Por otro lado esta el nombre completo del host, es decir planeta.gaiasur.com.ar, pero no hay usuario ni password y esto es porque el protocolo HTTP no utiliza estas porciones de la especificación.

Si seguimos observando, veremos la ausencia de camino o path [§]. Esto es porque existe un objeto estándard (el "/")que se entrega si no hay otro especificado, como sería el caso en http://planeta.gaiasur.com.ar/infoteca/links/l-hipertexto.htm. En este caso sí existe un path que es /links/l-hipertextos.htm y corresponde a un directorio y un archivo aunque esto no siempre es verdad, podría ser un objeto generado en el momento con un programa y entregado al cliente (browser en la Web) sin que jamás se grabecomo un archivo en disco.

Otro ejemplo distinto puede ser el FTP, donde es común observar algo así como ftp://ftp.mi.server.com/shareware/gleditw.zip. Aca se asume usuario=anonymous (anónimo), el password es la dirección de mail de cada uno y el port es 21.

Otro ejemplo es el de un servicio maravilloso, el Metacrawler, que atiende via http pero en el port 8080 que como no es el estándard, hay que especificarlo en el URL (http://metacrawler.cs.washington.edu:8080/).

Una ayuda para los navegantes hispanoparlantes: existe una adaptación al castellano de las páginas de búsqueda y ayuda del Metacrawler, gentileza de GaiaSur.

[Contenidos]


URL relativos

Muchas veces podrán observar que hay en documentos en la Web links sin la especificación completa, a los que le falta el esquema y el host o hasta el path.

Esos son URL relativos y veremos más sobre ellos cuando lleguemos a la nota sobre HTML.

[Contenidos]


¿Y los URN?

Los URN pretenden ser una forma más permanente y sencilla de acceder objetos pero aún no se utiliza.

Entonces podría llamar a http://tripulantes-de-gaiasur en vez de http://planeta.gaiasur.com.ar/gaiasur/index.html#quienes-somos.

Para que esto funcione debe existir un servicio que traduzca de URN a URL. Esto permitiría que si muevo ese objeto de lugar, al actualizar la posición en este servicio de traducción, el URN permanezca siempre igual.

Debido a esto, el URN sería más permanente y además más fácil de recordar siempre y cuando se utilice algo parecido a un nombre.

Otra ventaja de los URN, es que si mi cliente (browser en el caso de la Web) pide este URN y existen varias copias en distintos lugares del mismo recurso [§], este servicio de traducción podría indicarle cuál es la copia más cercana, y todo esto sin que yo ni siquiera me entere.

Pero como decíamos, aún no se utiliza.

[Contenidos]


OK, finalizando...

Los URL (URI's en general) sirven para ubicar objetos en Internet.

La mayoría sigue un formato estándard llamado CISS que es nombre-de-esquema://nombre-de-usuario:palabra-clave@host:port/camino, aunque algunos de ellos omiten o presuponen algunas de sus partes.

Conocerlos nos permitirá utilizar mejor los recursos a nuestra disposicion y navegar más eficientemente.

Algunos consejos finales muy breves son:

No juegue con las mayúsculas, algunas partes del URL son sensibles a las mismas. Para estar seguro use siempre minúsculas.

Autores: cuando diseña URL trate de no utilizar los caracteres espacio, tab, enter, #, y ?, ya que éstos tienen un significado especial. Reemplácelos por sus equivalentes ESC+valor ASCII hexadecimal o mejor, trate de no ponerlos del todo.

Espero que les haya servido y como siempre, ante cualquier duda, pueden preguntarme en mi dirección de e-mail.

Hasta la próxima...

[Contenidos]


Bibliografía


Apéndices

Algunas definiciones.

Creo que podría ayudar aclarar algunos términos (no se preocupen, son pocos). :-)

URI
Universal Resource Identifier (Identificador de Recursos Universal), es la especificación "padre" que incluye a los URL y URN.
URL
Uniform Resource Locator (Ubicador Uniforme de Recursos), la especificación de uso actual más difundido. Ejemplos de URN son el http, ftp, etc.
URN
Uniform Resource Name (Nombre Uniforme de Recursos), actualmente bajo desarrollo por el IETF correspondiente. Pretende ser más facil de recordar y entender y más permanente que los actuales URL, es decir que si yo muevo un recurso siga siendo válido -situación que no ocurre actualmente por ejemplo si muevo un archivo de lugar el URL de FTP que tenía ya no sirve para traerlo-.
objeto
ver recurso.
recurso
(resource en inglés) un objeto representado por un archivo que puede contener cualquier cosa (una página en HTML, un juego zipeado, un archivo de texto).
path
ver camino
camino
(path en inglés) la indicación de cómo llegar a un objeto. Muchas veces es una indicación de directorios y/o nombres de archivos pero no siempre es verdad eso.
esquema
básicamente un protocolo.
host
(¿anfitrión o alojador? en castellano) es un computadora conectada a la red que posee un nombre identificatorio.

[Contenidos]


Algunos esquemas usuales de URL

formato CISS (Sintaxis Común de Esquemas de Internet)

nombre-de-esquema://nombre-de-usuario:palabra-clave@host:port/camino

nombre-de
-esquema
nombre-de
-usuario
palabra
-clave
host port camino formato
FTP default: anónimo default: dirección de e-mail del usuario indicar default: 21 indicar (opcional) ftp://usuario:password@host:port/path
HTTP no utiliza no utiliza indicar default: 80 indicar (opcional) http://host:port/path?cadena-de-búsqueda *1
Gopher no utiliza no utiliza indicar default: 70 indicar gopher://host:port/path *2
Mailto nombre de cuenta no utiliza indicar no utiliza no utiliza mailto:cuenta@host (la dirección de e-mail) *3
News no utiliza no utiliza no utiliza no utiliza nombre-newsgroup news:nombre-newsgroup o news:número-del-mensaje *3
NNTP no utiliza no utiliza indicar default: 119 nombre-newsgroup/ número-del-mensaje nntp://host:port/nombre-newsgroup/ número-del-mensaje*3
Telnet usuario si no está especificada se pregunta indicar default: 23 no utiliza telnet://usuario:password@host:port
File no utiliza no utiliza indicar no utiliza indicar file://host/path*4

*1 Este protocolo no utiliza usuario y password. Las últimas dos partes (path y ?cadena-de-búsqueda), son opcionales y si no están se toma como estándard el recurso "/".

*2 Igual que el HTTP, Gopher no utiliza usuario y password.

*3 Estos esquemas no siguen estrictamente el formato CISS.

*4 Igual que el HTTP o Gopher, el File no utiliza usuario y password ni tampoco port.

Existen otros protocolos mucho menos utilizados y todos poseen sus propios estándares (Próspero y WAIS).

[Contenidos]


Autor