Instituto Tecnolgico de Pinotepa

Trabajo de Investigacin

Por: Rogelio Mata Flores

7 B de Ingeniera en Sistemas Computacionales

Santiago Pinotepa Nacional A 26 de Agosto de 2009.

Unidad I Introduccin a las tecnologas Web.1.1 Perspectiva histrica del Internet Historia de Internet Internet surgi de un proyecto desarrollado en Estados Unidos para apoyar a sus fuerzas militares. Luego de su creacin fue utilizado por el gobierno, universidades y otros centros acadmicos. Internet ha supuesto una revolucin sin precedentes en el mundo de la informtica y de las comunicaciones. Los inventos del telgrafo, telfono, radio y ordenador sentaron las bases para esta integracin de capacidades nunca antes vivida. Internet es a la vez una oportunidad de difusin mundial, un mecanismo de propagacin de la informacin y un medio de colaboracin e interaccin entre los individuos y sus ordenadores independientemente de su localizacin geogrfica. Orgenes de Internet La primera descripcin documentada acerca de las interacciones sociales que podran ser propiciadas a travs del networking (trabajo en red) est contenida en una serie de memorndums escritos por J.C.R. Licklider, del Massachusetts Institute of Technology, en Agosto de 1962, en los cuales Licklider discute sobre su concepto de Galactic Network (Red Galctica). El concibi una red interconectada globalmente a travs de la que cada uno pudiera acceder desde cualquier lugar a datos y programas. En esencia, el concepto era muy parecido a la Internet actual. Licklider fue el principal responsable del programa de investigacin en ordenadores de la DARPA desde Octubre de 1962. Mientras trabaj en DARPA convenci a sus sucesores Ivan Sutherland, Bob Taylor, y el investigador del MIT Lawrence G. Roberts de la importancia del concepto de trabajo en red. En Julio de 1961 Leonard Kleinrock public desde el MIT el primer documento sobre la teora de conmutacin de paquetes. Kleinrock convenci a Roberts de la factibilidad terica de las comunicaciones va paquetes en lugar de circuitos, lo cual result ser un gran avance en el camino hacia el trabajo informtico en red. El otro paso fundamental fue hacer dialogar a los ordenadores entre s. Para explorar este terreno, en 1965, Roberts conect un ordenador TX2 en Massachusetts con un Q-32 en California a travs de una lnea telefnica conmutada de baja velocidad, creando as la primera (aunque reducida) red de ordenadores de rea amplia jams construida. El resultado del experimento fue la constatacin de que los ordenadores de tiempo compartido podan trabajar juntos correctamente, ejecutando programas y recuperando datos a discrecin en la mquina remota, pero que el sistema telefnico de conmutacin de circuitos era totalmente inadecuado para esta labor. La conviccin de Kleinrock acerca de la necesidad de la conmutacin de paquetes qued pues confirmada. A finales de 1966 Roberts se traslad a la DARPA a desarrollar el concepto de red de ordenadores y rpidamente confeccion su plan para ARPANET, publicndolo en 1967. En la conferencia en la que present el documento se expona tambin un trabajo sobre el concepto de red de paquetes a cargo de Donald Davies y Roger Scantlebury del NPL. Scantlebury le habl a Roberts sobre su trabajo en el NPL as como sobre el de Paul Baran y otros en RAND. El grupo RAND haba escrito un documento sobre redes de conmutacin de paquetes para comunicacin vocal segura en el mbito militar, en 1964. Ocurri que los trabajos del MIT (1961-67), RAND (1962-65) y NPL (1964-67) haban discurrido en paralelo sin que los investigadores hubieran conocido el trabajo de los dems. La palabra packet (paquete) fue adoptada a partir del trabajo del NPL y la velocidad de la lnea propuesta para ser usada

en el diseo de ARPANET fue aumentada desde 2,4 Kbps hasta 50 Kbps (5). En Agosto de 1968, despus de que Roberts y la comunidad de la DARPA hubieran refinado la estructura global y las especificaciones de ARPANET, DARPA lanz un RFQ para el desarrollo de uno de sus componentes clave: los conmutadores de paquetes llamados interface message processors (IMPs, procesadores de mensajes de interfaz). El RFQ fue ganado en Diciembre de 1968 por un grupo encabezado por Frank Heart, de Bolt Beranek y Newman (BBN). As como el equipo de BBN trabaj en IMPs con Bob Kahn tomando un papel principal en el diseo de la arquitectura de la ARPANET global, la topologa de red y el aspecto econmico fueron diseados y optimizados por Roberts trabajando con Howard Frank y su equipo en la Network Analysis Corporation, y el sistema de medida de la red fue preparado por el equipo de Kleinrock de la Universidad de California, en Los Angeles (6). A causa del temprano desarrollo de la teora de conmutacin de paquetes de Kleinrock y su nfasis en el anlisis, diseo y medicin, su Network Measurement Center (Centro de Medidas de Red) en la UCLA fue seleccionado para ser el primer nodo de ARPANET. Todo ello ocurri en Septiembre de 1969, cuando BBN instal el primer IMP en la UCLA y qued conectado el primer ordenador host . El proyecto de Doug Engelbart denominado Augmentation of Human Intelect (Aumento del Intelecto Humano) que inclua NLS, un primitivo sistema hipertexto en el Instituto de Investigacin de Standford (SRI) proporcion un segundo nodo. El SRI patrocin el Network Information Center , liderado por Elizabeth (Jake) Feinler, que desarroll funciones tales como mantener tablas de nombres de host para la traduccin de direcciones as como un directorio de RFCs ( Request For Comments ). Un mes ms tarde, cuando el SRI fue conectado a ARPANET, el primer mensaje de host a host fue enviado desde el laboratorio de Leinrock al SRI. Se aadieron dos nodos en la Universidad de California, Santa Brbara, y en la Universidad de Utah. Estos dos ltimos nodos incorporaron proyectos de visualizacin de aplicaciones, con Glen Culler y Burton Fried en la UCSB investigando mtodos para mostrar funciones matemticas mediante el uso de "storage displays" ( N. del T. : mecanismos que incorporan buffers de monitorizacin distribuidos en red para facilitar el refresco de la visualizacin) para tratar con el problema de refrescar sobre la red, y Robert Taylor y Ivan Sutherland en Utah investigando mtodos de representacin en 3-D a travs de la red. As, a finales de 1969, cuatro ordenadores host fueron conectados cojuntamente a la ARPANET inicial y se hizo realidad una embrionaria Internet. Incluso en esta primitiva etapa, hay que resear que la investigacin incorpor tanto el trabajo mediante la red ya existente como la mejora de la utilizacin de dicha red. Esta tradicin contina hasta el da de hoy. Se siguieron conectando ordenadores rpidamente a la ARPANET durante los aos siguientes y el trabajo continu para completar un protocolo host a host funcionalmente completo, as como software adicional de red. En Diciembre de 1970, el Network Working Group (NWG) liderado por S.Crocker acab el protocolo host a host inicial para ARPANET, llamado Network Control Protocol (NCP, protocolo de control de red). Cuando en los nodos de ARPANET se complet la implementacin del NCP durante el periodo 1971-72, los usuarios de la red pudieron finalmente comenzar a desarrollar aplicaciones. En Octubre de 1972, Kahn organiz una gran y muy exitosa demostracin de ARPANET en la International Computer Communication Conference . Esta fue la primera demostracin pblica de la nueva tecnologa de red. Fue tambin en 1972 cuando se introdujo la primera aplicacin "estrella": el correo electrnico. En Marzo, Ray Tomlinson, de BBN, escribi el software bsico de envo-recepcin de mensajes de correo electrnico, impulsado por la necesidad que tenan los desarrolladores de ARPANET de un

mecanismo sencillo de coordinacin. En Julio, Roberts expandi su valor aadido escribiendo el primer programa de utilidad de correo electrnico para relacionar, leer selectivamente, almacenar, reenviar y responder a mensajes. Desde entonces, la aplicacin de correo electrnico se convirti en la mayor de la red durante ms de una dcada. Fue precursora del tipo de actividad que observamos hoy da en la World Wide Web , es decir, del enorme crecimiento de todas las formas de trfico persona a persona. Conceptos iniciales sobre Internetting La ARPANET original evolucion hacia Internet. Internet se bas en la idea de que habra mltiples redes independientes, de diseo casi arbitrario, empezando por ARPANET como la red pionera de conmutacin de paquetes, pero que pronto incluira redes de paquetes por satlite, redes de paquetes por radio y otros tipos de red. Internet como ahora la conocemos encierra una idea tcnica clave, la de arquitectura abierta de trabajo en red. Bajo este enfoque, la eleccin de cualquier tecnologa de red individual no respondera a una arquitectura especfica de red sino que podra ser seleccionada libremente por un proveedor e interactuar con las otras redes a travs del metanivel de la arquitectura de Internetworking (trabajo entre redes). Hasta ese momento, haba un slo mtodo para "federar" redes. Era el tradicional mtodo de conmutacin de circuitos, por el cual las redes se interconectaban a nivel de circuito pasndose bits individuales sncronamente a lo largo de una porcin de circuito que una un par de sedes finales. Cabe recordar que Kleinrock haba mostrado en 1961 que la conmutacin de paquetes era el mtodo de conmutacin ms eficiente. Juntamente con la conmutacin de paquetes, las interconexiones de propsito especial entre redes constituan otra posibilidad. Y aunque haba otros mtodos limitados de interconexin de redes distintas, stos requeran que una de ellas fuera usada como componente de la otra en lugar de actuar simplemente como un extremo de la comunicacin para ofrecer servicio end-to-end (extremo a extremo). En una red de arquitectura abierta, las redes individuales pueden ser diseadas y desarrolladas separadamente y cada una puede tener su propia y nica interfaz, que puede ofrecer a los usuarios y/u otros proveedores, incluyendo otros proveedores de Internet. Cada red puede ser diseada de acuerdo con su entorno especfico y los requerimientos de los usuarios de aquella red. No existen generalmente restricciones en los tipos de red que pueden ser incorporadas ni tampoco en su mbito geogrfico, aunque ciertas consideraciones pragmticas determinan qu posibilidades tienen sentido. La idea de arquitectura de red abierta fue introducida primeramente por Kahn un poco antes de su llegada a la DARPA en 1972. Este trabajo fue originalmente parte de su programa de paquetera por radio, pero ms tarde se convirti por derecho propio en un programa separado. Entonces, el programa fue llamado Internetting . La clave para realizar el trabajo del sistema de paquetera por radio fue un protocolo extremo a extremo seguro que pudiera mantener la comunicacin efectiva frente a los cortes e interferencias de radio y que pudiera manejar las prdidas intermitentes como las causadas por el paso a travs de un tnel o el bloqueo a nivel local. Kahn pens primero en desarrollar un protocolo local slo para la red de paquetera por radio porque ello le hubiera evitado tratar con la multitud de sistemas operativos distintos y continuar usando NCP. Sin embargo, NCP no tena capacidad para direccionar redes y mquinas ms all de un destino IMP en ARPANET y de esta manera se requeran ciertos cambios en el NCP. La premisa era que ARPANET no poda ser cambiado en este aspecto. El NCP se basaba en ARPANET para proporcionar seguridad

extremo a extremo. Si alguno de los paquetes se perda, el protocolo y presumiblemente cualquier aplicacin soportada sufrira una grave interrupcin. En este modelo, el NCP no tena control de errores en el host porque ARPANET haba de ser la nica red existente y era tan fiable que no requera ningn control de errores en la parte de los host s. As, Kahn decidi desarrollar una nueva versin del protocolo que pudiera satisfacer las necesidades de un entorno de red de arquitectura abierta. El protocolo podra eventualmente ser denominado "Transmisson-Control Protocol/Internet Protocol" (TCP/IP, protocolo de control de transmisin /protocolo de Internet). As como el NCP tenda a actuar como un driver (manejador) de dispositivo, el nuevo protocolo sera ms bien un protocolo de comunicaciones. Ideas a prueba DARPA formaliz tres contratos con Stanford (Cerf), BBN (Ray Tomlinson) y UCLA (Peter Kirstein) para implementar TCP/IP (en el documento original de Cerf y Kahn se llamaba simplemente TCP pero contena ambos componentes). El equipo de Stanford, dirigido por Cerf, produjo las especificaciones detalladas y al cabo de un ao hubo tres implementaciones independientes de TCP que podan interoperar. Este fue el principio de un largo periodo de experimentacin y desarrollo para evolucionar y madurar el concepto y tecnologa de Internet. Partiendo de las tres primeras redes ARPANET, radio y satlite y de sus comunidades de investigacin iniciales, el entorno experimental creci hasta incorporar esencialmente cualquier forma de red y una amplia comunidad de investigacin y desarrollo [REK78]. Cada expansin afront nuevos desafos. Las primeras implementaciones de TCP se hicieron para grandes sistemas en tiempo compartido como Tenex y TOPS 20. Cuando aparecieron los ordenadores de sobremesa ( desktop ), TCP era demasiado grande y complejo como para funcionar en ordenadores personales. David Clark y su equipo de investigacin del MIT empezaron a buscar la implementacin de TCP ms sencilla y compacta posible. La desarrollaron, primero para el Alto de Xerox (la primera estacin de trabajo personal desarrollada en el PARC de Xerox), y luego para el PC de IBM. Esta implementacin operaba con otras de TCP, pero estaba adaptada al conjunto de aplicaciones y a las prestaciones de un ordenador personal, y demostraba que las estaciones de trabajo, al igual que los grandes sistemas, podan ser parte de Internet. En los aos 80, el desarrollo de LAN, PC y estaciones de trabajo permiti que la naciente Internet floreciera. La tecnologa Ethernet, desarrollada por Bob Metcalfe en el PARC de Xerox en 1973, es la dominante en Internet, y los PCs y las estaciones de trabajo los modelos de ordenador dominantes. El cambio que supone pasar de una pocas redes con un modesto nmero de hosts (el modelo original de ARPANET) a tener muchas redes dio lugar a nuevos conceptos y a cambios en la tecnologa. En primer lugar, hubo que definir tres clases de redes (A, B y C) para acomodar todas las existentes. La clase A representa a las redes grandes, a escala nacional (pocas redes con muchos ordenadores); la clase B representa redes regionales; por ltimo, la clase C representa redes de rea local (muchas redes con relativamente pocos ordenadores). Como resultado del crecimiento de Internet, se produjo un cambio de gran importancia para la red y su gestin. Para facilitar el uso de Internet por sus usuarios se asignaron nombres a los host s de forma que resultara innecesario recordar sus direcciones numricas. Originalmente haba un nmero muy limitado de mquinas, por lo que bastaba con una simple tabla con todos los ordenadores y sus direcciones asociadas. El cambio hacia un gran nmero de redes gestionadas independientemente (por ejemplo, las LAN)

signific que no resultara ya fiable tener una pequea tabla con todos los host s. Esto llev a la invencin del DNS ( Domain Name System , sistema de nombres de dominio) por Paul Mockapetris de USC/ISI. El DNS permita un mecanismo escalable y distribuido para resolver jerrquicamente los nombres de los host s (por ejemplo, www.acm.org o www.ati.es ) en direcciones de Internet. El incremento del tamao de Internet result tambin un desafo para los routers . Originalmente haba un sencillo algoritmo de enrutamiento que estaba implementado uniformemente en todos los routers de Internet. A medida que el nmero de redes en Internet se multiplicaba, el diseo inicial no era ya capaz de expandirse, por lo que fue sustituido por un modelo jerrquico de enrutamiento con un protocolo IGP ( Interior Gateway Protocol , protocolo interno de pasarela) usado dentro de cada regin de Internet y un protocolo EGP ( Exterior Gateway Protocol , protocolo externo de pasarela) usado para mantener unidas las regiones. El diseo permita que distintas regiones utilizaran IGP distintos, por lo que los requisitos de coste, velocidad de configuracin, robustez y escalabilidad, podan ajustarse a cada situacin. Los algoritmos de enrutamiento no eran los nicos en poner en dificultades la capacidad de los routers , tambin lo haca el tamao de la tablas de direccionamiento. Se presentaron nuevas aproximaciones a la agregacin de direcciones (en particular CIDR, Classless Interdomain Routing , enrutamiento entre dominios sin clase) para controlar el tamao de las tablas de enrutamiento. A medida que evolucionaba Internet, la propagacin de los cambios en el software, especialmente el de los host s, se fue convirtiendo en uno de sus mayores desafos. DARPA financi a la Universidad de California en Berkeley en una investigacin sobre modificaciones en el sistema operativo Unix, incorporando el TCP/IP desarrollado en BBN. Aunque posteriormente Berkeley modific esta implementacin del BBN para que operara de forma ms eficiente con el sistema y el kernel de Unix, la incorporacin de TCP/IP en el sistema Unix BSD demostr ser un elemento crtico en la difusin de los protocolos entre la comunidad investigadora. BSD empez a ser utilizado en sus operaciones diarias por buena parte de la comunidad investigadora en temas relacionados con informtica. Visto en perspectiva, la estrategia de incorporar los protocolos de Internet en un sistema operativo utilizado por la comunidad investigadora fue uno de los elementos clave en la exitosa y amplia aceptacin de Internet. Uno de los desafos ms interesantes fue la transicin del protocolo para host s de ARPANET desde NCP a TCP/IP el 1 de enero de 1983. Se trataba de una ocasin muy importante que exiga que todos los host s se convirtieran simultneamente o que permanecieran comunicados mediante mecanismos desarrollados para la ocasin. La transicin fue cuidadosamente planificada dentro de la comunidad con varios aos de antelacin a la fecha, pero fue sorprendentemente sobre ruedas (a pesar de dar la lugar a la distribucin de insignias con la inscripcin "Yo sobreviv a la transicin a TCP/IP"). TCP/IP haba sido adoptado como un estndar por el ejrcito norteamericano tres aos antes, en 1980. Esto permiti al ejrcito empezar a compartir la tecnologa DARPA basada en Internet y llev a la separacin final entre las comunidades militares y no militares. En 1983 ARPANET estaba siendo usada por un nmero significativo de organizaciones operativas y de investigacin y desarrollo en el rea de la defensa. La transicin desde NCP a TCP/IP en ARPANET permiti la divisin en una MILNET para dar soporte a requisitos operativos y una ARPANET para las necesidades de investigacin. As, en 1985, Internet estaba firmemente establecida como una tecnologa que ayudaba a una amplia comunidad de investigadores y desarrolladores, y empezaba a ser empleada por otros grupos en sus comunicaciones diarias entre ordenadores. El correo electrnico se empleaba ampliamente entre varias

comunidades, a menudo entre distintos sistemas. La interconexin entre los diversos sistemas de correo demostraba la utilidad de las comunicaciones electrnicas entre personas. La transici1n hacia una infraestructura global Al mismo tiempo que la tecnologa Internet estaba siendo validada experimentalmente y usada ampliamente entre un grupo de investigadores de informtica se estaban desarrollando otras redes y tecnologas. La utilidad de las redes de ordenadores (especialmente el correo electrnico utilizado por los contratistas de DARPA y el Departamento de Defensa en ARPANET) sigui siendo evidente para otras comunidades y disciplinas de forma que a mediados de los aos 70 las redes de ordenadores comenzaron a difundirse all donde se poda encontrar financiacin para las mismas. El Departamento norteamericano de Energa (DoE, Deparment of Energy ) estableci MFENet para sus investigadores que trabajaban sobre energa de fusin, mientras que los fsicos de altas energas fueron los encargados de construir HEPNet. Los fsicos de la NASA continuaron con SPAN y Rick Adrion, David Farber y Larry Landweber fundaron CSNET para la comunidad informtica acadmica y de la industria con la financiacin inicial de la NFS ( National Science Foundation , Fundacin Nacional de la Ciencia) de Estados Unidos. La libre diseminacin del sistema operativo Unix de ATT dio lugar a USENET, basada en los protocolos de comunicacin UUCP de Unix, y en 1981 Greydon Freeman e Ira Fuchs disearon BITNET, que una los ordenadores centrales del mundo acadmico siguiendo el paradigma de correo electrnico como "postales". Con la excepcin de BITNET y USENET, todas las primeras redes (como ARPANET) se construyeron para un propsito determinado. Es decir, estaban dedicadas (y restringidas) a comunidades cerradas de estudiosos; de ah las escasas presiones por hacer estas redes compatibles y, en consecuencia, el hecho de que durante mucho tiempo no lo fueran. Adems, estaban empezando a proponerse tecnologas alternativas en el sector comercial, como XNS de Xerox, DECNet, y la SNA de IBM (8). Slo restaba que los programas ingleses JANET (1984) y norteamericano NSFNET (1985) anunciaran explcitamente que su propsito era servir a toda la comunidad de la enseanza superior sin importar su disciplina. De hecho, una de las condiciones para que una universidad norteamericana recibiera financiacin de la NSF para conectarse a Internet era que "la conexin estuviera disponible para todos los usuarios cualificados del campus". En 1985 Dennins Jenning acudi desde Irlanda para pasar un ao en NFS dirigiendo el programa NSFNET. Trabaj con el resto de la comunidad para ayudar a la NSF a tomar una decisin crtica: si TCP/IP debera ser obligatorio en el programa NSFNET. Cuando Steve Wolff lleg al programa NFSNET en 1986 reconoci la necesidad de una infraestructura de red amplia que pudiera ser de ayuda a la comunidad investigadora y a la acadmica en general, junto a la necesidad de desarrollar una estrategia para establecer esta infraestructura sobre bases independientes de la financiacin pblica directa. Se adoptaron varias polticas y estrategias para alcanzar estos fines. La NSF opt tambin por mantener la infraestructura organizativa de Internet existente (DARPA) dispuesta jerrquicamente bajo el IAB ( Internet Activities Board , Comit de Actividades de Internet). La declaracin pblica de esta decisin firmada por todos sus autores (por los grupos de Arquitectura e Ingeniera de la IAB, y por el NTAG de la NSF) apareci como la RFC 985 ("Requisitos para pasarelas de Internet") que formalmente aseguraba la interoperatividad entre las partes de Internet dependientes de DARPA y de NSF. El backbone haba hecho la transicin desde una red construida con routers de la comunidad investigadora (los routers Fuzzball de David Mills) a equipos comerciales. En su vida de ocho aos y

medio, el backbone haba crecido desde seis nodos con enlaces de 56Kb a 21 nodos con enlaces mltiples de 45Mb.Haba visto crecer Internet hasta alcanzar ms de 50.000 redes en los cinco continentes y en el espacio exterior, con aproximadamente 29.000 redes en los Estados Unidos. El efecto del ecumenismo del programa NSFNET y su financiacin (200 millones de dlares entre 1986 y 1995) y de la calidad de los protocolos fue tal que en 1990, cuando la propia ARPANET se disolvi, TCP/IP haba sustituido o marginado a la mayor parte de los restantes protocolos de grandes redes de ordenadores e IP estaba en camino de convertirse en el servicio portador de la llamada Infraestructura Global de Informacin. El papel de la documentacin Un aspecto clave del rpido crecimiento de Internet ha sido el acceso libre y abierto a los documentos bsicos, especialmente a las especificaciones de los protocolos. Los comienzos de Arpanet y de Internet en la comunidad de investigacin universitaria estimularon la tradicin acadmica de la publicacin abierta de ideas y resultados. Sin embargo, el ciclo normal de la publicacin acadmica tradicional era demasiado formal y lento para el intercambio dinmico de ideas, esencial para crear redes. En 1969 S.Crocker, entonces en UCLA, dio un paso clave al establecer la serie de notas RFC ( Request For Comments , peticin de comentarios). Estos memorndums pretendieron ser una va informal y de distribucin rpida para compartir ideas con otros investigadores en redes. Al principio, las RFC fueron impresas en papel y distribuidas va correo "lento". Pero cuando el FTP ( File Transfer Protocol , protocolo de transferencia de ficheros) empez a usarse, las RFC se convirtieron en ficheros difundidos online a los que se acceda va FTP. Hoy en da, desde luego, estn disponibles en el World Wide Web en decenas de emplazamientos en todo el mundo. SRI, en su papel como Centro de Informacin en la Red, mantena los directorios online . Jon Postel actuaba como editor de RFC y como gestor de la administracin centralizada de la asignacin de los nmeros de protocolo requeridos, tareas en las que contina hoy en da. El efecto de las RFC era crear un bucle positivo de realimentacin, con ideas o propuestas presentadas a base de que una RFC impulsara otra RFC con ideas adicionales y as sucesivamente. Una vez se hubiera obtenido un consenso se preparara un documento de especificacin. Tal especificacin seria entonces usada como la base para las implementaciones por parte de los equipos de investigacin. Con el paso del tiempo, las RFC se han enfocado a estndares de protocolo las especificaciones oficiales- aunque hay todava RFC informativas que describen enfoques alternativos o proporcionan informacin de soporte en temas de protocolos e ingeniera. Las RFC son vistas ahora como los documentos de registro dentro de la comunidad de estndares y de ingeniera en Internet. El acceso abierto a las RFC libre si se dispone de cualquier clase de conexin a Internet- promueve el crecimiento de Internet porque permite que las especificaciones sean usadas a modo de ejemplo en las aulas universitarias o por emprendedores al desarrollar nuevos sistemas. El e-mail o correo electrnico ha supuesto un factor determinante en todas las reas de Internet, lo que es particularmente cierto en el desarrollo de las especificaciones de protocolos, estndares tcnicos e ingeniera en Internet. Las primitivas RFC a menudo presentaban al resto de la comunidad un conjunto de ideas desarrolladas por investigadores de un solo lugar. Despus de empezar a usarse el correo electrnico, el modelo de autora cambi: las RFC pasaron a ser presentadas por coautores con visiones en comn, independientemente de su localizacin. Las listas de correo especializadas ha sido usadas ampliamente en el desarrollo de la especificacin de

protocolos, y continan siendo una herramienta importante. El IETF tiene ahora ms de 75 grupos de trabajo, cada uno dedicado a un aspecto distinto de la ingeniera en Internet. Cada uno de estos grupos de trabajo dispone de una lista de correo para discutir uno o ms borradores bajo desarrollo. Cuando se alcanza el consenso en el documento, ste puede ser distribuido como una RFC. Debido a que la rpida expansin actual de Internet se alimenta por el aprovechamiento de su capacidad de promover la comparticin de informacin, deberamos entender que el primer papel en esta tarea consisti en compartir la informacin acerca de su propio diseo y operacin a travs de los documentos RFC. Este mtodo nico de producir nuevas capacidades en la red continuar siendo crtico para la futura evolucin de Internet. El futuro: Internet 2 Internet2 es el futuro de la red de redes y est formado actualmente por un consorcio dirigido por 206 universidades que junto a la industria de comunicaciones y el gobierno estn desarrollando nuevas tcnicas de conexin que acelerarn la capacidad de transferencia entre servidores. Sus objetivos estn enfocados a la educacin y la investigacin acadmica. Adems buscan aprovechar aplicaciones de audio y video que demandan ms capacidad de transferencia de ancho de banda.

1.2

Protocolo http (protocolo de transferencia de hipertexto).RFC 1945 (HTTP/1.0, 1996)

Estndares:

RFC 2616 (HTTP/1.1, 1999) RFC 2774 (HTTP/1.2, 2000)

El protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) es el protocolo usado en cada transaccin de la Web (WWW). HTTP fue desarrollado por el consorcio W3C y la IETF, colaboracin que culmin en 1999 con la publicacin de una serie de RFC, siendo el ms importante de ellos el RFC 2616, que especifica la versin 1.1. HTTP define la sintaxis y la semntica que utilizan los elementos software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema peticin-respuesta entre un cliente y un servidor. Al cliente que efecta la peticin (un navegador o un spider) se lo conoce como "user agent" (agente del usuario). A la informacin transmitida se la llama recurso y se la identifica mediante un URL. Los recursos pueden ser archivos, el resultado de la ejecucin de un programa, una consulta a una base de datos, la traduccin automtica de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna informacin sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es informacin que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la nocin de "sesin", y tambin permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. Transacciones HTTP Una transaccin HTTP consiste de un encabezado seguido, opcionalmente, por una lnea en blanco y algn dato. El encabezado especificar cosas como la accin requerida del servidor, o el tipo de dato retornado, o el cdigo de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos

permiten que se enve informacin descriptiva en la transaccin, permitiendo as la autenticacin, cifrado e identificacin de usuario. Un encabezado es un bloque de datos que precede a la informacin propiamente dicha, por lo que muchas veces se hace referencia a l como metadato porque tiene datos sobre los datos. Si se reciben lneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier carcter guin ( - ) del nombre del encabezado se convierte a caracteres "_". El servidor puede excluir cualquier encabezado que ya est procesado, como Authorization, Content-type y Content-length. El servidor puede elegir excluir alguno o todos los encabezados si incluirlos excede algn lmite del ambiente de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT.

HTTP_ACCEPT. Los tipos MIME que el cliente aceptar, dado los encabezados HTTP. Otros protocolos quizsnecesiten obtener esta informacin de otro lugar. Los elementos de esta lista deben estar separados por una coma, como lo dice la especificacin HTTP: tipo, tipo.

HTTP_USER_AGENT. El navegador que utiliza el cliente para realizar la peticin. El formato general para estavariable es: software/versin librera/versin. El servidor enva al cliente:

Un cdigo de estado que indica si la peticin fue correcta o no. Los cdigos de error tpicos indican que el archivo solicitado no se encontr, que la peticin no se realiz de forma correcta o que se requiere autenticacin para acceder al archivo. La informacin propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como grficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP. Informacin sobre el objeto que se retorna.

Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos de ellos slo tienen sentido en una direccin. Versiones HTTP ha pasado por mltiples versiones del protocolo, muchas de las cuales compatibles con las anteriores. El RFC 2145 describe el uso de los nmeros de versin de HTTP. El cliente le dice al servidor al principio de la peticin la versin que usa, y el servidor usa la misma o una anterior en su respuesta. 0.9 Obsoleta. Soporta slo un comando, GET, y adems no especifica el nmero de versin HTTP. No soporta cabeceras. Como esta versin no soporta POST, el cliente no puede enviarle mucha informacin al servidor. HTTP/1.0 (mayo 1996) Esta es la primera revisin del protocolo que especifica su versin en las comunicaciones, y todava se usa ampliamente, sobre todo en servidores proxy. HTTP/1.1 (junio 1999) Versin actual; las conexiones persistentes estn activadas por defecto y funcionan bien con los proxies. Tambin soporta peticiones en paralelo (pipelining), permitiendo enviar mltiples peticiones a la vez, lo cual hace que el servidor pueda prepararse para una sobrecarga de trabajo y servir las solicitudes ms rpidamente al cliente. HTTP/1.2 Los primeros borradores de 1995 del documento PEP an Extension Mechanism for HTTP (el cul propone el Protocolo de Extensin de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envi al Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de

HTTP/1.2. En borradores posteriores, sin embargo, se elimin la referencia a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se public en febrero de 2000.

1.2.1 Arquitectura del WWW.El diseo del World-Wide Web sigue el modelo cliente-servidor: un paradigma de divisin del trabajo informtico en el que las tareas se reparten entre un nmero de clientes que efectan peticiones de servicios de acuerdo con un protocolo, y un nmero de servidores que las atienden (Malkin, 1993). En el Web, nuestras estaciones de trabajo son clientes que demandan hipertextos a los servidores. Para poner en marcha un sistema como como ste ha sido necesario: a) Disear e implementar un nuevo protocolo que permitiera realizar saltos hipertextuales, esto es, de un nodo o lexia de origen a uno de destino, que podria ser un texto o parte de un texto, una imagen, un sonido, una animacin, fragmento de vdeo, etc. Es decir, cualquier tipo de informacin en formato electrnico. Este protololo se denomina HTTP (HyperText Transfer Protocol) y es el "lenguaje" que "hablan" los servidores del WWW. b) Inventar un lenguaje para representar hipertextos que incluyera informacin sobre la estructura y el formato de representacin y, especialmente, indicar origen y destino de saltos hipertextuales. Este lenguaje es el HTML o (HyperTextex markup Language). c) Idear una forma de codificar las instrucciones para los saltos hipertextuales de un objeto a otro de la Internet. Dada la variedad de protocolos, y por tanto, formas de almacenamiento y recuperacin de la informacin, en uso en la Internet, esta informacin es vital para que los clientes (ver el siguiente punto) puedan acceder a dicha informacin. d) Desarrollar aplicaciones cliente para todo tipo de plataforma y resolver el problema de cmo acceder a informacin que est almacenada y es accesible a travs de protocolos diversos (FTP, NNTP, Gopher, HTTP, X.500, WAIS, etc.) y representar informacin multiformato (texto, grficos, sonidos, fragmentos de vdeo, etc.). A este fin se han desarrollado diversos clientes, entre los que destaca la familia Mosaic, del NCSA (National Center for Supercomputer Applications) de la Universidad de Chicago, y su sucesor Netscape Navigator, de Netscape Communications Corporation.

1.2.2 URLs.Los URL (Uniform Resource Locator) son una notacin estndar para la especificacin de recursos presentes en Internet. Constituyen la piedra angular del Web, ya que hacen posible que un link de HTML se refiera a cualquier objeto de la red. Un URL representa de un modo compacto la localizacin y el mtodo de acceso de cualquier recurso de la red (Berners-Lee, Masinter y McCahill, 1994). No slo hay ms de dos millones de ordenadores conectados a los varios miles de redes que forman la Internet, sino que existen mltiples protocolos o formas diferentes de acceder a la informacin (ftp, gopher, http, etc.). Los URL aportan esos dos datos esenciales: dnde se encuentra un recurso y cmo se puede acceder a l. La sintaxis de los URL es la siguiente: URL:: El esquema es un trmino convenido que representa el mtodo de acceso a un recurso. La parte especfica del esquema informa sobre su localizacin en la red, de un modo que depende de cada mtodo de acceso. Un ejemplo nos ayudar a entender esto. Cuando utilizamos ftp annimo para copiar un fichero de un ordenador remoto a nuestro ordenador necesitamos saber lo siguiente: host o nombre del ordenador remoto donde se encuentra el fichero y

path o via que conduce al fichero dentro de la estructura de ficheros del ordenador remoto. Supongamos que el fichero se llama README, y que est en el directorio pub del host ftp.uji.es; el URL de tal objeto sera ste: Al recuperar un fichero mediante ftp annimo usamos "anonymous" como nombre de usuario, y nuestra direccin de correo electrnico como password. En los URL esta informacin se omite dado que es conocida. Sin embargo, es posible incluirla si, por ejemplo, no se trata de ftp annimo, sino que se necesita especificar un usuario real y su password. La sintaxis genrica de los URL para objetos accesibles por ftp es la siguiente: URL:ftp://[user[:password]@]host[:port]/path[;type=] El "port" puede omitirse si el servidor de ftp emplea el port estndar de ftp (el 21). Este principio de omitir lo ya conocido se sigue en todos los URL. Si los distintos servidores siguen las recomendaciones de la Internet no es necesario incluir informacin redundante. El "path" es la lista ordenada de subdirectorios por los que hay que pasar para llegar al fichero, separados por "/", seguida del nombre del fichero. El "type" es "d", "a", "i". "d" indica que se requiere la transmisin de una lista de nombres de ficheros (un directorio). "a" solicita una transmisin de lneas de texto. "i" solicita una transmisin binaria. La utilidad, y la necesidad, de una notacin que, como sta, introduzca algo de orden en el caos de la red es obvia. Los URL se idearon para un proyecto concreto y limitado, el del WWW, pero ha cundido el ejemplo. Ahora mismo se est produciendo un amplio debate en el seno de Internet, concretado en un grupo de trabajo de la IETF (Internet Engineering Task Force) para el desarrollo de sistemas universales de designacin y caracterizacin de objetos persistentes de la red, inspirados en los URL pero que iran ms all: debera ser posible, por ejemplo, asignar un URN (Uniform Resource Name) invariable para un objeto, aunque cambiara su path e incluso su mtodo de acceso. Un sistema distribuido (similar al DNS o Domain Name System) resolveria un URN en uno o varios URL aplicando criterios de optimizacin de recursos (como proximidad al solicitante). Persistencia en http Cookies. Uno de los mecanismos ms usados para mantener persistencia es el mecanismo de cookies, inventado por Netscape y hoy en da aceptado por casi todos los browsers, en especial los ms populares. El concepto es que mediante un header del protocolo HTTP el server pueda almacenar informacin en el cliente. A esta informacin que el server guarda en el cliente se la denomina cookie. Las cookies pueden habilitarse o deshabilitarse desde el browser por lo que algunos usuarios no lo soportan, son de uso bastante general en muchos web sites a punto tal que en sites de la importancia de yahoo si el usuario no tiene habilitadas las cookies prcticamente no puede utilizar la mayora de los servicios del site. Cuando el server enva un header con un cookie el browser, si acepta cookies, guarda la informacin enviada en un archivo de texto con un formato especial. Cada vez que el browser solicita una pgina del dominio que envi la cookie re-envia la cookie al site, de esta forma es posible mantener persistencia. La informacin que puede guardarse en una cookie esta limitada por lo que habitualmente se utiliza la misma para mantener el identificador de sesin del usuario almacenndose el resto de los datos necesarios en el servidor usando el session-id de la cookie como clave. Para crear un cookie en PHP se utiliza la funcin setcookie cuya sintaxis es la siguiente: int=setcookie(nombre, valor, expiracin, path, dominio); Nombre : Nombre de la cookie a setear por ejemplo sesion

Valor : Valor que contendr la cookie, como por ejemplo khdhkfdh47 Expiracion : Fecha de vencimiento de la cookie (fecha en la cual el browser la borra del disco del usuario), debe estar en formato Unix. En general el uso ms practico es time()+tiempo donde tiempo es la cantidad de segundos de vida de la cookie. Path : En general no se usa, suele setearse en / Dominio : Dominio para el cual el cookie es valido ejemplo .prueba.com en cuyo caso sirve para algo.prueba.com, site1.prueba.com, site2.prueba.com y todos los de la misma forma. La funcin devuelve verdadero si pudo setearse la cookie o falso en caso contrario (por ejemplo si el browser no acepta cookies) Las cookies son sumamente practicas para manejar sesiones, en cada pgina se verifica si el usuario tiene seteada la cookie con nombre session si la tiene se recupera el valor de la sesin, si no la tiene se crea un identificador de sesin nuevo y nico y se setea la cookie correspondiente con el vencimiento que corresponde segn la duracin que uno considere necesaria. Luego el identificador de sesin es accesible en cada pgina para almacenar valores por ejemplo en la base de datos como el nombre del usuario, preferencias de la sesin y otros valores. La recuperacin de la cookie y su creacin en caso de no existir se puede colocar en un modulo php que luego se incluye en cada pgina por ejemplo mod_session.php solo hay que recordar en cada pgina hacer un include(mod_session.php); y luego se puede usar la variable $session_id (o el nombre que se le haya dado en el modulo) para guardar y recuperar valores correspondientes a la sesin actual.

1.2.3 Mtodos http.El conjunto de mtodos comunes para HTTP/1.1 se define a continuacin. Aunque esta serie se puede ampliar, los mtodos adicionales que no se puede suponer que comparten la misma semntica para los clientes por separado extendido y servidores. La solicitud de acogida-campo de cabecera deber acompaar todas las peticiones HTTP/1.1. Mtodos de seguridad y idempotente mtodos seguros Implementadores deben ser conscientes de que el software representa al usuario en sus interacciones a travs de Internet, y debe tener cuidado para que el usuario sea consciente de las acciones que podra adoptar medidas que puedan tener un significado inesperado a s mismos. En particular, la Convencin ha establecido que los mtodos GET y cabeza no debe tener la importancia de tomar una accin que no sea de recuperacin. Estos mtodos deben ser considerados "seguros". Esto permite a los agentes de usuario para representar a otros mtodos, como POST, PUT y DELETE, de una manera especial, para que el usuario sea consciente del hecho de que una accin que posiblemente sean inseguras se solicita. Naturalmente, no es posible garantizar que el servidor no genera efectos secundarios como consecuencia de realizar una solicitud GET, de hecho, algunos de los recursos dinmicos consideran que una caracterstica. La distincin importante aqu es que el usuario no ha solicitado los efectos secundarios, por lo tanto, no pueden ser considerados responsables de ellos.

Mtodos idempotente Los mtodos tambin pueden tener la caracterstica de "idempotencia" en el que (aparte de los errores o problemas de caducidad), los efectos secundarios de N> 0 solicitudes idnticas es el mismo que para una sola solicitud. Los mtodos GET, HEAD, PUT y DELETE comparten esta propiedad. Adems, las opciones de mtodos y TRACE no deben tener efectos secundarios, por lo que son inherentemente idempotente. Sin embargo, es posible que una secuencia de varias peticiones no es idempotente, incluso si todos los mtodos de ejecucin en esa secuencia se idempotente. (Una secuencia es idempotente si una ejecucin nica de toda la secuencia siempre produce un resultado que no sea cambiada por el reexecution total o parcial, de dicha secuencia.) Por ejemplo, una secuencia no es idempotente si su resultado depende de una valor que se modific ms tarde en la misma secuencia. Una secuencia que no tiene efectos secundarios es idempotente, por definicin (siempre que no operaciones simultneas se ejecutan en el mismo conjunto de recursos). OPTIONS El mtodo de opciones representa una solicitud de informacin sobre las opciones de comunicacin disponibles en la peticin / respuesta de la cadena identificados por el URI de la peticin. Este mtodo permite al cliente para determinar las opciones y / o requisitos relacionados con un recurso, o en las capacidades de un servidor, sin que ello implique una accin de recursos o el inicio de una recuperacin de los recursos. Las respuestas a este mtodo no son almacenables. Si la solicitud de opciones incluye una entidad-cuerpo (como lo indica la presencia de Content-Length o Transfer-Encoding), entonces el tipo de medios de comunicacin debe ser indicado por el campo Content-Type. Aunque esta especificacin no define ningn uso para ese rgano, las futuras extensiones de HTTP puede utilizar el conjunto de opciones para hacer las consultas ms detalladas sobre el servidor. Un servidor que no es compatible con dicha extensin podr descartar el cuerpo de la peticin. Si la URI de la peticin es un asterisco ("*"), la peticin OPCIONES est destinado a aplicarse en el servidor, en general, ms que a un recurso especfico. Desde las opciones de comunicacin de un servidor normalmente dependen de los recursos, el "*" solicitud slo es til como ping "o" no ", op tipo de mtodo, no hace nada ms all de permitir al cliente a probar las capacidades del servidor. Por ejemplo, esto puede ser utilizado para probar un sustituto para el cumplimiento de HTTP/1.1 Si la URI de la peticin no es un asterisco, la solicitud de OPCIONES se aplica slo a las opciones que estn disponibles cuando se comunique con ese recurso. A 200 respuesta debera incluir todos los campos de encabezado que indica las caractersticas opcionales implementadas por el servidor y aplicable a ese recurso (por ejemplo, permitir), posiblemente con extensiones incluidas, no se define en esta especificacin. El cuerpo de la respuesta, en su caso, tambin debe incluir informacin sobre las opciones de comunicacin. El formato para tal cuerpo no est definido por esta especificacin, pero podra ser definido por las prximas ampliaciones de HTTP. La negociacin de contenidos pueden ser utilizados para seleccionar el formato de respuesta adecuados. Si no se incluye ningn texto de respuesta, la respuesta debe incluir un campo ContentLength con un campo de valor de "0".

El Max-Forwards solicitud campo de encabezado puede ser utilizado para apuntar a una representacin especfica en la cadena de peticin. Cuando un servidor proxy recibe una solicitud de opciones en un absoluteURI para el que se permite el reenvo de solicitud, el cheque debe proxy para un MaxForwards campo. Si el Max-Forwards campo valor es cero ( "0"), el proxy no debera reenviar el mensaje, en cambio, la representacin debe responder con sus propias opciones de comunicacin. Si el Max-Forwards campo valor es un entero mayor que cero , el proxy debe disminuir el campo de valor cuando se enva la peticin. Si no Max-Forwards campo est presente en la solicitud, la solicitud debe remitido no incluye un Max-Forwards campo. GET El mtodo GET significa recuperar toda la informacin (en forma de una entidad) es identificado por el URI de la peticin. Si la URI de la peticin se refiere a un proceso de produccin de datos, es que los datos obtenidos debern ser devueltos a la entidad como en la respuesta y no el texto original del proceso, a menos que el texto pasa a ser el resultado del proceso. La semntica de la GET cambiar el mtodo a una "GET condicional" si el mensaje de solicitud incluye una "If-Modified-Since, si-no modificada ya que, si-Match, Si-No-Match, o si la campo de la cabecera Range. Un condicional peticiones GET mtodo que la entidad transferir slo bajo las circunstancias descritas por el campo de cabecera condicional (s). El mtodo GET condicional se destina a reducir el uso innecesario de la red permitiendo a las entidades en cach que se actualice sin necesidad de solicitudes mltiples o la transferencia de datos ya en poder del cliente. La semntica de la GET cambiar el mtodo a una "GET parcial" si el mensaje de solicitud incluye un campo de cabecera Range. Un parcial de peticiones GET que se transferir una parte de la entidad, tal como se describe en la seccin El mtodo GET parcial se destina a reducir el uso innecesario de la red, permitiendo parcialmente recuperado entidades a ser completado sin la transferencia de datos ya en poder del cliente. CABEZA El mtodo HEAD es idntico a GET, excepto que el servidor NO DEBE devolver un mensaje de cuerpo en la respuesta. La metainformacin contenida en las cabeceras HTTP en respuesta a una solicitud de cabeza debe ser idntica a la informacin enviada en respuesta a una solicitud GET. Este mtodo puede ser usado para obtener metainformacin acerca de la entidad que implica la peticin, sin la transferencia de la entidad-cuerpo mismo. Este mtodo se utiliza a menudo para probar los enlaces de hipertexto para la validez, la accesibilidad, y la reciente modificacin. La respuesta a una solicitud de cabeza puede ser cacheable en el sentido de que la informacin contenida en la respuesta puede ser utilizado para actualizar una entidad previamente almacenados en cach de ese recurso. Si los valores de campo indican que la nueva entidad en cach difiere de la entidad actual (como se indica con un cambio en Content-Length, Content-MD5, o ETag LastModified), entonces el cache debe tratar a la entrada de cach como rancio. POST El mtodo POST se utiliza para solicitar que el servidor de origen de aceptar la entidad incluido en la solicitud como un subordinado de nuevo el recurso identificado por la URI de la peticin en la solicitud-Line. POST est diseado para permitir un mtodo uniforme para cubrir las siguientes funciones: - Anotacin de los recursos existentes;

- Publicar un mensaje a un tabln de anuncios, grupos de noticias, listas de correo, o de un grupo similar de artculos; - Creacin de un bloque de datos, como el resultado de la presentacin de una forma, a un proceso de manipulacin de datos; - Ampliacin de una base de datos a travs de una operacin de anexin. La funcin real realizada por el mtodo POST es determinada por el servidor y por lo general dependen de la URI de la peticin. La entidad envi est subordinado a la URI de la misma manera que un archivo est subordinado a un directorio que lo contiene, un artculo de noticias est subordinado a un grupo de noticias al que se publique, o un registro est subordinado a una base de datos. La accin realizada por el mtodo POST no puede dar lugar a un recurso que puede ser identificado por un URI. En este caso, o bien 200 (correcto) o 204 (Sin contenido) es el estado de respuesta adecuada, dependiendo de si la respuesta incluye una entidad que se describe el resultado. Si un recurso se ha creado en el servidor de origen, la respuesta debera ser 201 (Creado) y contienen una entidad que se describe el estado de la solicitud y se refiere al nuevo recurso, y una cabecera de ubicacin Las respuestas a este mtodo no son almacenables, a menos que la respuesta incluye Cache-control apropiado o campos de encabezado Expires. Sin embargo, la 303 la respuesta puede ser utilizado para dirigir el agente de usuario para recuperar un recurso cach. PUT Las solicitudes mtodo PUT que la entidad adjuntos se almacenan en la Solicitud de suministro de URI. Si la URI de la peticin se refiere a un recurso ya existente, la entidad cerrada debe ser considerado como una versin modificada de la que residen en el servidor de origen. Si la URI de la peticin no apunta a un recurso existente, y que la URI es capaz de ser definido como un nuevo recurso por el agente de usuario que lo solicita, el servidor de origen puede crear el recurso con el URI. Si se crea un nuevo recurso, el servidor de origen deber informar al agente de usuario a travs de la 201 (Creado) de respuesta. Si se modifica un recurso existente, ya sea el 200 (correcto) o 204 (Sin contenido) los cdigos de respuesta debe enviarse para indicar la finalizacin con xito de la peticin. Si el recurso no puede ser creado o modificado con el URI de la peticin, una respuesta de error debe darse, que refleja la naturaleza del problema. El beneficiario de la entidad NO DEBE ignorar cualquier Contenido-* (Content-Range, por ejemplo) los encabezados que no comprenda o no de aplicar y debe devolver un 501 (no ejecutados) de respuesta en tales casos. Si la solicitud pasa a travs de una memoria cach y la URI de la peticin identifica a una o ms entidades en la actualidad en cach, las entradas deben ser tratados como rancio. Las respuestas a este mtodo no son almacenables. La diferencia fundamental entre el puesto y las solicitudes se refleja en el diferente significado de la URI de la peticin. El URI de una peticin POST identifica el recurso que se encargar de la entidad cerrada. Ese recurso puede ser un proceso de aceptacin de datos, una puerta de entrada a otro protocolo, o una entidad independiente que acepta anotaciones. En cambio, la URI de una solicitud PUT identifica la entidad junto a la solicitud - el agente de usuario sabe lo que es URI previsto y el intento de servidor NO DEBE aplicar la solicitud de algn otro recurso. Si los deseos del servidor que la peticin se aplica a una URI diferente, debe enviar un (301 Movido permanentemente) la respuesta, el agente de usuario puede entonces hacer

su propia decisin sobre si procede o no para redirigir la peticin. Un solo recurso puede ser identificado por muchos URI diferentes. Por ejemplo, un artculo puede tener un URI para la identificacin de "la versin actual", que es independiente de la URI de la identificacin de cada versin particular. En este caso, una solicitud PUT en un URI general podra dar lugar a otros varios URIs se define por el servidor de origen. HTTP/1.1 no define cmo un mtodo PUT afecta el estado de un servidor de origen. Solicitudes PUT debe obedecer a los requisitos de transmisin de mensajes que figuran en la seccin 8.2. Salvo disposicin en contrario de una entidad particular la cabecera, la entidad en los encabezados de la peticin que se debe aplicar a los recursos creados o modificados por el PUT. DELETE Las solicitudes mtodo Delete que el servidor de origen eliminar el recurso identificado por el URI de la peticin. Este mtodo puede ser anulado por la intervencin humana (o de otros medios) en el servidor de origen. El cliente no se puede garantizar que la operacin se ha realizado, incluso si el cdigo de estado devuelto por el servidor de origen indica que la accin se ha completado con xito. Sin embargo, el servidor no debe indicar el xito a menos que, en el momento de la respuesta se da, se tiene la intencin de eliminar el recurso o moverlo a un lugar inaccesible. Una respuesta exitosa debe ser de 200 (OK) si la respuesta incluye una entidad que describe el estado, 202 (Aceptado) si la accin an no ha sido promulgado, o 204 (Sin contenido) si la accin ha sido promulgada, pero la respuesta no incluye una entidad. Si la solicitud pasa a travs de una memoria cach y la URI de la peticin identifica a una o ms entidades en la actualidad en cach, las entradas deben ser tratados como rancio. Las respuestas a este mtodo no son almacenables. TRACE El mtodo TRACE se utiliza para invocar un control remoto, circuito de capa de aplicacin de devolucin del mensaje de solicitud. El destinatario final de la solicitud debe reflejar el mensaje recibido de vuelta al cliente como la entidad-cuerpo de un 200. El destinatario final sea el . servidor de origen o el proxy de primera o puerta de enlace para recibir un Max-Forwards valor de cero (0) en la solicitud. Una peticin TRACE NO DEBE incluir una entidad. TRACE permite al cliente ver lo que est siendo recibido en el otro extremo de la cadena de solicitar y utilizar esos datos para pruebas o informacin de diagnstico. El valor del campo de cabecera Via es de particular inters, ya que acta como una huella de la cadena de peticin. Uso de la Max-Forwards encabezado de campo permite al cliente para limitar la longitud de la cadena de peticin, que es til para la prueba de una cadena de proxies el reenvo de mensajes en un bucle infinito. Si la peticin es vlida, la respuesta debe contener el mensaje de solicitud en su totalidad en el cuerpo de la entidad, con un tipo de contenido de mensaje "http". Las respuestas a este mtodo NO DEBEN ser almacenados en cach. CONEXIN

Esta especificacin se reserva el nombre de mtodo Connect para el uso con un proxy que puede cambiar de forma dinmica a ser un tnel (tnel SSL por ejemplo.

1.3. Introduccin al HTML 1.3.1 HTML como un tipo SGML.SGML fue diseado para permitir el intercambio de informacin entre distintas plataformas, soportes fsicos, lgicos y diferentes sistemas de almacenamiento y presentacin (bases de datos, edicin electrnica, etc.), con independencia de su grado de complejidad. Un nuevo concepto de informacin Cuando se concibe un documento electrnico en SGML se debe tener en cuenta que:

El material que constituye un documento se puede distribuir en diferentes archivos, tantos como sean necesarios. Estos archivos adems pueden estar almacenados en distintos ordenadores. Un archivo puede contener la portada, otro la introduccin, otro una parte de una hoja de clculo, otro un grfico, otro un organigrama, otro la bibliografa, etc. En SGML, cada uno de estos objetos recibe el nombre de entidad. Las entidades se conciben como objetos independientes. Las entidades pueden tener cualquier tamao, haber sido creadas por cualquier programa de software o estar guardadas en cualquier ordenador. Las entidades pueden estar compartidas por distintos documentos. Un documento estar definido en funcin de la estructura de las entidades que lo conforman. En el ndice de materias de un documento no se encontrar ninguna referencia a los archivos que contienen las entidades. Las entidades se organizan en una estructura lgicade manera jerarquizada, en la que se definen conceptos como captulos, tablas y prrafos y que configuran lo que se denomina estructura de los elementos del documento. Elementos y entidades pueden coincidir: un elemento lgico como tabla puede ser tambin una entidad en un archivo hoja de clculo

Dos tipos de contenido En toda comunicacin se pueden distinguir dos niveles de informacin: 1. Por un lado, el conjunto de datos que componen lo que tradicionalmente entendemos por contenido, 2. y por otro, una informacin ms sutil, que se superpone a ese contenido. Esta otra informacin es la negrita en un libro, el subrayado en un manuscrito, un tono alto de voz en una conversacin y se denomina etiquetado (markup). La funcin del etiquetado es aportar informacin que por lo general refleja la estructura jerrquica de un documento, de forma que ayude al lector humano o al ordenador a procesar su contenido. El lenguaje de etiquetado SGML permite distinguir entre el contenido o datos (compuestos por

caracteres de datos, las letras del alfabeto, los nmeros, la puntuacin, etc.) y el etiquetado (compuesto por caracteres de etiquetado, los cuales, en este caso concreto, son tambin letras, nmeros y signos de puntuacin. El etiquetado procedimental La idea de etiquetar un texto no es nueva. Hasta fechas muy recientes, los maquetadores de las imprentas marcaban los textos con instrucciones para que el cajista supiera cmo reflejar el diseo, esto es, si los ttulos deban aparecer ms grandes, en negrita o centrados, los renglones sangrados con una cierta anchura, etc. Estas instrucciones eran una secuencia de signos ininteligibles para el profano y, muchas veces, solo tenan sentido para la mquina concreta con la que se iba a imprimir. Las instrucciones podan contener cdigos de control especficos que trasladados a otro entorno podan bloquear la composicin tipogrfica. Por lo dems de las veces, estas instrucciones, que estaban adems intercaladas en el texto, imposibilitaban la reutilizacin posterior de la informacin. Si el texto era revisado con intencin de reeditarlo, haba que utilizar el mismo sistema de composicin, para entonces probablemente obsoleto. Si se deseaba cambiar el diseo, haba que manipular los archivos para modificar todos losa cdigos, muchos encriptados u ocultos, como por ejemplo, el efecto de centrar un ttulo escrito en negrita con letra Times Roman de 36 puntos. La utilizacin de tcnicas informticas de bsqueda y recuperacin globales podan resolver parcialmente el problema, pero a veces ocasionando efectos no deseados. Las mismas instrucciones pueden aparecer en una amplia diversidad de lugares no relacionados de manera lgica. Por ejemplo, si se cambiasen a negrita todos los extranjerismos que se hallaban en cursiva en un texto, tambin se convertiran de manera accidental, aunque automtica, todas las referencias de obras en cursiva en la bibliografa, as como cualquier otra parte del texto resaltado con cursiva. El etiquetado procedimental es esta tcnica que estamos describiendo, por medio de la cual un operario utiliza instrucciones crpticas y dependientes del funcionamiento de un sistema determinado para que ejecute una accin, como por ejemplo activar la tipografa, poner en negrita, centrar, etc. El etiquetado descriptivo por el contrario, identifica los elementos estructurales de un documento, determinando su estructura lgica, de manera que se solucionan muchos de los problemas mencionados. Ventajas del etiquetado descriptivo 1. En primer lugar, el estndar SGML utiliza un conjunto de caracteres basado en el estndar ASCII (American Standard Coding for the Interchange of Information), reconocido de manera prcticamente universal por cualquier tipo de plataforma y de sistema informtico. Los caracteres especiales, que no estn contemplados en el conjunto de caracteres ASCII (propios de sistemas de escritura distintos del ingls, smbolos matemticos, etc.) se transforman en representaciones ASCII y se denominan referencias de entidad. As se evitan otros caracteres especiales o de control. 2. La segunda mejora tiene que ver con la subordinacin del etiquetado a los aspectos lgicos de la estructura de los documentos. SGML parte del criterio de que existe una relacin directa entre cuestiones como el cambio de tipografa y una cabecera, la utilizacin de la cursiva para resaltar un trmino, el dibujo de un recuadro con un grfico, etc.

En SGML todo el etiquetado es lgico, es decir, en lugar de utilizar cdigos crpticos, se utilizan nombres de elementos, delimiatados por marcas que indican el comienzo y final de los objetos lgicos. Cmo son las etiquetas SGML En SGML, las etiquetas se distinguen del resto del texto mediante caracteres de delimitacin. Estos delimitadores permiten que el software reconozca qu caracteres deben ser ledos en modo de ETIQUETA, y deben por ello traducirse al lenguaje concreto de composicin o tratarse de manera especfica, y qu otros caracteres de CONTENIDO debern ser transferidos posteriormente a la aplicacin para su procesamiento. Delimitadores Los caracteres utilizados como delimitadores deben elegirse cuidadosamente, ya que no han de aparecer con demasiada frecuencia como parte del contenido de un documento. El ISO 8879 describe un conjunto de caracteres bsicos entre los que se incluyen el parntesis angular de apertura y de cierre para destacar las etiquetas de inicio (los caracteres < > con el nombre de un elemento en su interior) y el signo & seguido por un nombre, y ste a su vez seguido de un punto y coma para representar entidades tales como imgenes grficas o caracteres especiales (por ejemplo, &bullet; para un redondelito negro). Cmo funciona SGML? Cualquier base de datos cuenta con una representacin interna que indica, por ejemplo, dnde termina el campo de "nombres" y donde comienza el campo de "direcciones". Todos los procesadores de texto utilizan algn sistema de codificacin interno para marcar cuestiones como la negrita, la cursiva, el sangrado, el centrado, etc. Pero el problema con estos cdigos es que cada programa usa un sistema propio, sistemas que incluso cambian de una versin a otra en un mismo programa. Aunque existen programas para convertir, los problemas que esta disparidad ocasiona son considerables. Etiquetado genrico En las primeras reuniones del Comit que abord la creacin de SGML, una de las principales cuestiones que se debatieron fue la codificacin genrica, esto es, un sistema de cdigos universal e independiente de la aplicacin, por medio del cual, por ejemplo significara siempre prrafo y indicara siempre un encabezado de primer nivel. La intencin inicial era lograr especificar un conjunto de etiquetas que fueran vlidas para un elevado nmero de documentos. Sin embargo, a pesar de que el principio de la codificacin genrica est bien fundado, la variedad de documentos, as como la diversidad de elementos que contienen, lo hacen prcticamente inabordable. Se vislumbr adems un segundo problema: Qu se hace con los errores? Existe algn sistema por el que el ordenador pueda ayudar a asegurar que se codifican correctamente los nombres de los elementos? Puede ser de utilidad el ordenador en la an ms difcil tarea de comprobar que los usuarios introducen los cdigos en los lugares correctos? Cabecera Curiosamente, exista una respuesta a ambos problemas, y sta lleg desde el entorno de la programacin informtica. Habitualmente, los lenguajes informticos proporcionan al programador un conjunto de operaciones bsicas "primitivas" que suelen agruparse en un cabecera (heading) que sirve para definir un conjunto

especfico de instrucciones que utilizar el programa. Definicin de tipo de documento (DTD) Los miembros del Comit adoptaron exactamente este enfoque. De esta forma SGML no se qued como un mero conjunto de cdigos normalizados, sino que se convirti en un lenguaje con el que se poda crear una definicin del tipo de documento (DTD), mediante la que se definen con precisin aquellos elementos que son necesarios en la elaboracin de un documento o un grupo de documentos estructurados de manera similar. Declaracin de elementos Las definiciones de los elementos -formalmente denominadas declaraciones de elementos- tienen dos funciones: 1. aportan el nombre "oficial" de las etiquetas (los nombres que aparecern dentro de los delimitadores, por ejemplo ); 2. y describen lo que cada elemento puede contener, el modelo de contenido Un captulo se puede definir como algo que comienza con un ttulo, seguido de una serie de prrafos, con subsecciones: El lenguaje SGML proporciona la sintaxis necesaria para realizar esta declaracin. Cualquier sistema SGML la reconocera, gracias a la presencia de la marca finaliza la declaracin de este elemento. El sistema reconoce la palabra reservada de SGML, PCDATA, dando a entender que "chptitle", "para" y "heading" no tienen ningn subelemento propio. Ms bien contienen lo que se denomina datos de caracteres analizados sintcticamente: las letras, los nmeros, la puntuacin y los caracteres especiales concretos que constituyen el contenido. Al llegar a este punto el usuario creara el documento utilizando el etiquetado declarado en la DTD, acompaado por los delimitadores apropiados procedentes de los datos de los caracteres: Advirtase que en algunas ocasiones puede utilizarse la minimizacin del etiquetado para ahorrar pulsaciones de teclas. (En el ejemplo previo se ha omitido la etiqueta de fin del primer prrafo, ya que la etiqueta de inicio del siguiente prrafo implica el final del elemento del primer prrafo. Adems, se ha omitido el nombre del elemento "para" en la secuencia ). Existen varias tcnicas de minimizacin vlidas para las etiquetas de fin, as como para las etiquetas de inicio y para las especificaciones de atributos. La declaracin de un documento SGML Cuando se le comunica a alguien que se le est enviando un documento SGML, esa persona sabe de antemano:

que dicho documento puede comenzar con una declaracin SGML. Ese diagrama formal y normalizado le indica al sistema receptor exactamente -entre otra mucha informacin- el conjunto de caracteres, los delimitadores y las caractersticas opcionales de SGML que se estn utilizando. (Por ejemplo, la minimizacin es algo que unos sistemas soportan y otros no). A menudo se omitir la declaracin SGML presuponiendo que tanto el sistema emisor como el receptor utilizan la sintaxis por defecto o la sintaxis de referencia concreta. que por consiguiente, el documento contendr un subconjunto de la declaracin del tipo de documento, un conjunto formal de declaraciones de elementos, atributos y entidades que le indican a un sistema exactamente el tipo de etiquetado que se utiliza en dicho documento. A menudo se sustituir la DTD completa por una lnea que indique que la DTD se edita como un texto pblico o se encuentra ya disponible en el sistema receptor (DTD es el acrnimo de Definicin del Tipo de Documento, incluyndose asimismo en dicha definicin las directrices o convenciones que conforman una aplicacin SGML). que en consecuencia, el documento contendr una muestra de documento. Dicha muestra es lo que se entenda por el documento en s: el contenido junto con el etiquetado.

Gracias a SGML se ha conseguido simplificar todos los pasos. En este sistema cada componente establece los valores y parmetros para el siguiente componente. El nico etiquetado que aparece ha sido declarado en la DTD y la sintaxis de la DTD se ha indicado mediante la declaracin SGML definida por el estndar. La autntica ventaja de esta secuenciacin de indicaciones es que los ordenadores pueden seguirla para comprobar si los documentos se adaptan a las reglas establecidas para ellos mismos. SGML, a pesar de ser un lenguaje incomprensible para los seres humanos, es un lenguaje informtico muy preciso. Esto significa que un programa informtico -un parser- puede leer la declaracin SGML y aprender sus reglas, a continuacin leer la DTD y aprender las reglas del etiquetado y finalmente determinar si la muestra de documento cumple dichas reglas. Cmo se procesa un documento SGML? Se trata de una validacin automtica realizada por una mquina. Y en la medida en que asegura que el contenido que se est enviando a una base de datos o a una mquina de composicin no sufrir problemas excesivamente graves, no tendr rivales en el mercado.

La funcin del parser es leer el documento SGML y separar los datos del etiquetado. El parser detecta cundo el etiquetado ha sido minimizado y en tal caso lo expande. Si el contenido incluye referencias a una hoja de clculo electrnica de un captulo concreto (captulo 2), y el grfico del organigrama de otro captulo (captulo 6), dar las instrucciones pertinentes al sistema sobre cmo encontrar dichas entidades. Si el grfico se halla en alguna notacin de contenido de datos especial, generada por un programa de diseo de grficos, el parser lo dispondr todo para introducir la imagen (en este caso para ser editada). Si su contenido incluye instrucciones especiales para el sistema de edicin en su propio lenguaje interno -SGML las denomina instrucciones de procesamiento- stas pasarn directamente a la aplicacin. Si se ha utilizado el componente de seccin marcada en SGML y ha indicado que algunas partes de su documento no han de aparecer en la versin editada, el parser sabr que no tiene que enviarlas. Si se est utilizando el componente de declaracin de comentarios SGML para enviar y recibir notas y mensajes entre los escritores y los editores, el parser tambin sabr que no ha de enviarlos a la aplicacin receptora. Todo esto y ms. Todo esto y ms, y lo que es ms importante, sin que resulte visible al ojo humano. Esta lista -y se trata tan slo de parte de lo que un parser y un sistema SGML pueden hacer- describe procesos que pueden llevarse a cabo sin necesidad de que intervenga el usuario, excepto para corregir errores humanos. En la actualidad est surgiendo una nueva generacin de software que vive y respira SGML; que saca partido de la DTD para guiar a los usuarios a la hora de crear documentos que estn bien estructurados; que se sirve de la estructura para dar a los usuarios una funcionalidad que nunca antes haban tenido. En un futuro no muy lejano, los usuarios encontrarn de gran utilidad toda la informacin que aparece en este artculo. Las complicaciones ocultas detrs de los interfaces intuitivos no representarn ya un problema al disponer al alcance de su mano de los poderosos y flexibles componentes de SGML. La posibilidad de exportar archivos SGML facilitar la integracin de su software de hojas de clculo, hipertextos y procesamiento de textos. Esta nueva generacin de software trabajar directamente con las DTD y ofrecer un enfoque lgico con respecto al tratamiento de la informacin -basado en la estructura, en los objetos y en los atributos- mucho ms til que los interfaces para ndices, plantillas y hojas de estilo de hoy en da. "El intercambio de informacin independientemente del grado de complejidad" es uno de los principales objetivos de cualquier estndar. Es por ello que un estndar diseado como un lenguaje para construir aplicaciones tendr muchas posibilidades de triunfar en el mercado actual. Por lo tanto, la funcin de este artculo es presentar los componentes del lenguaje que se utilizan a la hora de disear aplicaciones, con el fin de que se conozcan todas las posibilidades que ofrece el estndar SGM La maquetacin o marcacin Las marcas o etiquetas en el proceso tradicional de edicin En todas las editorial existe uno o varios especialistas cuya funcin es marcar el texto manuscrito para indicar el aspecto que debe tener en su forma impresa. Este proceso recibe el nombre de maquetacin (markup, en ingls). Definiciones de maquetacin o markup El manual de etilo The Chicago Manual of Style define markup de la siguiente manera: "Es el proceso de marcar un documento manuscrito con instrucciones acerca de cmo se deben utilizar los tipos de letra, los tamaos, los espacios, el sangrado etc."

Instrucciones para el cajista En una editorial tradicional, existe la figura del "maquetador" en la que recae la labor de decidir los formatos y diseos de los libros que se van a imprimir. De acuerdo con estos criterios otra persona, denominada "corrector de manuscritos", marca detalladamente el libro manuscrito con instrucciones precisas para el "cajista", quien se ocupa de preparar las pruebas de imprenta. Estos son algunos ejemplos clsicos de instrucciones para el cajista: "Times Roman 10/12 x 24", al comienzo de un captulo indica que el captulo debe ir en tipografa Times Roman de 10 puntos con un interlineado de 12 puntos, y una medida de 24 cceros (lnea con longitud de 6 pulgadas); "10/10 Times Roman sangrar dos cuadratines desde la izquierda" al comienzo de una cita de bloque indica que se debe componer con una sangra desde el margen izquierdo. Una lnea vertical coloreada a la izquierda indicar la extensin exacta de este ajuste. La maquetacin electrnica Estas tres figuras del proceso de edicin tradicional suelen reducirse en la actualidad a una sola, el maquetador. Los nuevos medios de edicin electrnica agilizan enormemente un proceso que con frecuencia se subcontrata a empresas especializadas en maquetacin y autoedicin. El procesamiento de textos Prcticamente la totalidad de los programas informticos de procesamiento de textos y sistemas de autoedicin modernos disponen de cdigos de maquetacin. En estos programas, se utiliza el trmino "maquetar" para describir cualquier cdigo o instruccin acerca del formato o diseo de un documento. La maquetacin debe sealar como mnimo los cambios en el tipo de letra (negrita, cursiva etc.), los saltos de lnea, los mrgenes, etc. WYSIWYG Hoy en da, casi todos los procesadores de texto son del tipo WYSIWYG (What you see is what you get, 'Obtienes lo que ves'). En ellos el diseo se realiza sobre la pantalla por medio de teclas de funcin o mediante opciones de men. De esta manera se insertan cdigos en el documento que se encargan de recrear el efecto deseado, tanto cuando se visualiza el documento por pantalla, como cuando se imprime. En WordPerfect, por ejemplo, la negrita se inserta mediante un cdigo de control (un carcter ASCII extendido de 8 bits), que al mismo tiempo cambia el color de la visualizacin en la pantalla. Este sistema se corresponde muy estrechamente con el subrayado ondulado y la nota al margen en "negrita" propia de la correccin tradicional de manuscritos. En los primeros sistemas WYSIWYG (como en las primeras versiones de WordStar), los cdigos eran visibles en la pantalla. En los sistemas modernos normalmente queda oculto para el usuario. En muchos casos, existe una opcin para visualizar el etiquetado. Por ejemplo, si el usuario de WordPerfect activa la opcin de "mostrar cdigos", los cdigos que se visualizan en pantalla son trminos significativos encerrados entre corchetes, como [Negr]para marcar la negrita[negr], (aunque el cdigo es en realidad un solo carcter ASCII extendido).

1.3.2 Elementos del lenguaje HTML.ELEMENTOS BSICOS Tipo de Documento Titulo Encabezado Cuerpo

DEFINICIN ESTRUCTURAL Ttulos Alineamiento de Ttulo Divisin Alineamiento de Divisiones Bloque de Cita Enfasis Enfasis Fuerte Cita Cdigo Ejemplo de Salida Entrada del Teclado Variable Definicin Direccin del Autor Tamao de letra grande Tipo de letra pequeo

FORMATO DE PRESENTACIN Negritas Itlicas N3.0b Subrayado Tachado

N3.0b

Tachado Subndice Exponente Maquina de escribir Preformateado Ancho Centrado

N1.0

Parpadeando Tamao del tipo de letra Cambiar el tamao del tipo de letra

N1.0 N3.0b N3.0b N3.0b N3.0b N3.0b N3.0b N3.0b N3.0b N3.0b

Tamao de letra Base Color del Tipo de Letra Seleccionar Tipo de Letra Texto de multicolumnas Espacio entre columnas Ancho de la columna Espaciador Tipo de Espaciador Tamao del espaciador Dimensiones del Espaciador Alineamiento del Espaciador

LIGAS Y GRFICAS Ligar algo Ligar a un Ancla N2.0 Ventana "blanco"

Define un Ancla en un documento Relacin Relacin inversa Mostrar Imagen Alineamiento

N1.0

Alineamiento Nombre Alternativo Mapa Sensitivo

Mapa sensitivo del lado del Cliente Descripcin del mapa Seciones del mapa Dimensiones Reborde Espacio Marginal N1.0 N1.1 N2.0 N2.0 Portal de baja resolucin Cliente jala Objeto embebido

Tamao del objeto

DIVISORES Prrafo Alinear Texto Salto de Linea Eliminar Textwrap Barra Horizontal Alineacin Grosor Ancho N1.0 N1.0 N1.0 Porcentaje de Anchura Lnea Slida No Salto de Lnea Salto de Palabra

LISTAS

Lista No Ordenada

( antes de cada elemento de la lista)

Lista Compacta Tipo de Marca

(para todas la lista)

(esta y subsecuentes) (

antes de cada elemento de la lista) (Para toda la lista) (esta y subsecuentes) (para toda la lista) (Esta y subsecuentes) (=termino, =definicin) (

antes de cada elemento de la lista) (

antes de cada elemento de la lista)

Lista Ordenada

Lista Compacta

Tipo de Numeracin

Nmero Inicial

Lista de definiciones Lista Compacta Lista de Mens

Lista compacta Lista de Directorios

Lista compacta

FONDOS Y COLORES Tile de Fondo Color de Fondo Color del texto Color de la liga Liga visitada Liga Activa

CARACTERES

ESPECIALES (estos deben estar todos en minsculas) Caracter Especial < > & " Marca Registrada TM Copyright Espacio no rompe lnea ?; < > & "

FORMAS Definir Formas N2.0 Campo de entrada Nombre del Campo Valor del Campo Checado? Tamao del campo Max Length Lista de Seleccin Nombre de la lista # de opciones Opcin Mltiple Opcin Opcion por default Tamao de la

Subir Archivo

caja de entrada Mombre de la caja N2.0 Activar Text Wrap

TABLAS Definir Tabla Reborde de la tabla Espaciado de Celdas Ancho Deseado Porcentaje del ancho Rengln de celda Alineamiento

Celda de Tabla Alineamiento

No saltos de lnea Columnas por abarcar Renglones por Abarcar N1.1 N1.1 N3.0b Ancho deseado Ancho en Porcentaje Color de la Celda Encabezado de la tabla Alineamiento

Evitar Salto de Lnea Columnas por abarcar Renglones por abarcar N1.1 N1.1 N3.0b Ancho deseado Ancho como Porcentaje Color de la Celda

Subttulo de la Celda Alineamiento FRAMES N2.0 N2.0 N2.0 N2.0 N2.0 N3.0b N3.0b N3.0b N2.0 N2.0 N2.0 N2.0 N2.0 N2.0 N2.0 N3.0b N3.0b N2.0 Documento Frame Frames Horizontales Frames Horizontales Frames Verticales Frames Verticales Ancho del Reborde Rebordes Color del Reborde Definir Frame Mostrar un Documento en el frame Nombre del Frame Ancho del margen Altura del Margen Barra de avance? Impedir cambio de tamao Rebordes Color del Reborde Conenido fuera de Frames JAVA Applet Nombre del Applet Parmetros Localizacin del Applet Identificador del Applet Texto Alternativo Alineamiento Tamao Espaciado

MISCELLANEAS Comentarios Prlogo de HTML 3.2 Buscable Prompt Iniciar Bsqueda URL de este archivo N2.0 Nombre base de la ventana Relacin Meta Information Hojas de estilo Scripts

1.3.3 Tablas en HTML.Tablas simples Una tabla HTML puede ser considerada de manera simple como un grupo de filas donde cada una de ellas contiene un grupo de celdas. Las tablas, as como toda estructura en documentos HTML, son definidas usando tags. Una tabla simple puede ser insertada en un documento HTML usando tres tags: el tag HTML table (principal contenedor), el tag HTML tr (fila contenedora) y el tag HTML td (celda simple). Veamos un ejemplo: Cdigo Visualizacin

Celda 1 Celda 2 Celda 3

Celda 4 Celda 5 Celda 6 Celda 1 Celda 2 Celda 3 Celda 4 Celda 5 Celda 6 Nota: Los bordes en este ejemplo son creados utilizando el atributo "border" para el tag HTML table, el cual es slo utilizado para mejorar la visualizacin. Como los atributos de presentacin van siendo

desaprobados con cada versin del estndar HTML, y dado que los mismos efectos pueden lograrse usando hojas de estilo, recomendamos evitar el uso de atributos de presentacin como "border". Ten en cuenta que las celdas vacas igual deben ser declaradas utilizando sus respectivos tags para lograr correctitud en el cdigo. Cuando el contenido de una celda debe ser vaco, deberas usar siempre un espacio en blanco () en su lugar. Esto har que tu pgina sea ms comatible, dado que ciertos navegadores tienen problemas al mostrar celdas vacas. Tipos de celdas Dos tipos de celda pueden ser definidos en una tabla HTML. Una de ellas es la celda simple (tag HTML td) anteriormente utilizada en el ejemplo de "tabla simple", y la otra es un tipo de celda especial (tag HTML th) que contiene informacin de encabezado para todas las celdas en la columna (pertenecientes al mismo grupo horizontal). Los navegadores pueden graficar el contenido de las celdas de encabezado en una manera especial (usualmente, texto centrado y en negrita). Este tipo de celda es comnmente encontrado en el encabezado de una tabla. En el ejemplo siguiente la misma "tabla simple" es definida pero esta vez con celdas de encabezado: Cdigo Visualizacin

Columna 1 Columna 2 Columna 3

Celda 1 Celda 2 Celda 3

Celda 4 Celda 5 Celda 6 Columna 1 Columna 2 Columna 3 Celda 1 Celda 2 Celda 3 Celda 4 Celda 5 Celda 6 Las caractersticas de estas celdas pueden ser logradas visualmente usando una celda simple con atributos de presentacin (texto centrado y en negrita), pero las celdas de encabezado proporcionan ms informacin oculta que puede ser til para navegadores no visuales (los navegadores hablados pueden decir a los usuarios el contenido de una celda asocindolo inmediatamente con el encabezado correspondiente) y araas (como las de los motores de bsqueda lo que ayudara en la promocin del sitio). Otra forma de asociar celdas de encabezados con celdas simples es usando los atributos: "headers" para definir una lista de celdas que proveen informacin de encabezado para la celda actual (ver el tag HTML td) y "scope" para definir una lista de celdas para las cuales la celda actual provee informacin de encabezado (ver el tag HTML th).

Unificando celdas Para algunas tablas puedes necesitar unificar dos o ms celdas en una sola que tomar el lugar de aquellas afectadas. Estas unificaciones pueden lograrse mediante los atributos "rowspan" (para unificar verticalmente) y "colspan" (para unificar horizontalmente), ambos disponibles para celdas (tag HTML td y tag HTML th). Cdigo Visualizacin

Campo 1 Campo 2 Campo 3

Campos 4 y 5 Campo 6

Campo 7 Campo 8 Campo 9 Campo 1 Campo 2 Campo 3 Campos 4 y 5 Campo 6 Campo 7 Campo 8 Campo 9 Observa en el ejemplo anterior como una definicin de celda unificando dos celdas, es el equivalente unificado de dos definiciones de celda simple. Esto tambin funciona para unificar verticalmente con una pequea diferencia debida a la naturaleza de las tablas HTML. Al unificar celdas verticalmente, las definiciones de celda en la columna afectada debern ser omitidas. Observa el siguiente ejemplo, donde el campo 1, 4 y 7 son unificadas: Cdigo Visualizacin

Campo unificado Campo 2 Campo 3

Campo 5 Campo 6

Campo 8 Campo 9

Campo unificado Campo 2 Campo 5 Campo 8 Campo 3 Campo 6 Campo 9

Debes ser cuidadoso al unificar filas y columnas de modo de que no se encimen las celdas unificadas. Esto puede provocar un resultado indeseado.

1.3.4 FormulariosFormularios Los formularios interactivos permiten a los autores de pginas Web poner elementos interactivos en sus pginas, por ejemplo, para recibir mensajes de sus lectores, de forma similar a las cartas de respuestas que se encuentra en algunas revistas. El lector escribe la informacin rellenando campos o haciendo clic sobre botones, y luego presiona un botn de envo para enviarla a una direccin URL que se suele dirigir a una direccin de correo electrnico o a un script dinmico Web como PHP, ASP o CGI. La etiqueta FORM Los formularios estn delimitados con la etiqueta ... , que permite reunir varios elementos de formulario, como botones y casillas de texto y que debe poseer los siguientes atributos: METHOD indica cmo se enviarn las respuestas "POST" es el valor que enva los datos al agente de procesamiento almacenndolos en el cuerpo del formulario, en tanto que "GET" enva los datos agregndolos a la direccin URL y separndolos de la direccin con un signo de interrogacin (para aprender ms sobre los mtodos POST y GET, consulte el artculo sobre protocolo HTTP) ACTION indica la direccin a la que se enviar la informacin (un script CGI o direccin de correo electrnico (mailto:direccin_de_correo_e@equipo)) Un atributo opcional de la etiqueta FORM es ENCTYPE, que especifica cmo se codifican los datos del formulario. De cualquier forma, esto no necesita especificarse, ya que el valor predeterminado (application/x-www-form-urlencoded) es el nico valor vlido. El atributo opcional ACCEPT se usa para establecer tipos MIME para los datos que el formulario puede enviar. Esta es la sintaxis para la etiqueta FORM: ...

Dentro de la etiqueta FORM La etiqueta FORM acta como una especie de contenedor para almacenar elementos que permiten al usuario seleccionar o introducir datos. Todos los datos se enviarn a la direccin URL indicada en el atri buto ACTION de la etiqueta FORM, por el mtodo indicado en el atributo METHOD. Se puede insertar cualquier elemento HTML en una etiqueta FORM (como texto, botones, tablas y enlaces), pero los elementos interactivos son los ms interesantes. Estos elementos interactivos son:

La etiqueta INPUT: Todos los botones y casillas de texto La etiqueta TEXTAREA: una casilla de texto La etiqueta SELECT: una lista de opciones mltiples

Envo de datos Cuando se enva un formulario (haciendo clic en el botn de envo), los datos del formulario se envan a un script CGI bajo la forma de pares nombre/valor, es decir conjuntos de datos representados por el nombre del elemento formulario, un signo igual ("=") y luego el valor asociado. Estos pares nombre/valor se separan unos de otros mediante el smbolo de unin ("&"). Por lo tanto, los datos que se envan al script se vern as: campo1=valor1&field2;=valor2&field3;=valor3 Con el mtodo GET (enviar los datos mediante una direccin URL), la URL ser una cadena como la siguiente: http://es.kioskea.net/cgi-bin/script.cgi?campo1=valor1&field2;=valor2

La etiqueta INPUT La etiqueta INPUT es una etiqueta esencial para los formularios, ya que se usa para crear muchos elementos interactivos. La sintaxis de esta etiqueta es la siguiente: El atributo name es esencial, ya que permite al script CGI reconocer qu campo est asociado con un par nombre/valor, lo que significa que el nombre del campo estar seguido de un signo igual ("=") seguido de un valor que el usuario introdujo, o si el usuario no introdujo ningn valor, por el valor predeterminado de la etiqueta value. El atributo type se usa para especificar qu tipo de elemento se representa con la etiqueta INPUT. Estos son los valores posibles: checkbox: Las casillas de eleccin pueden adoptar uno de dos estados: checked (seleccionado) o unchecked (no seleccionado). Cuando la cas