Copyright © Eduardo G. Mercovich 1996.
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://.
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 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.
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.
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.
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...
Creo que podría ayudar aclarar algunos términos (no se preocupen, son pocos). :-)
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).