Instituto Tecnológico de Pinotepa

Trabajo de Investigación

Por: Rogelio Mata Flores

7 “B” de Ingeniería en Sistemas Computacionales

Santiago Pinotepa Nacional A 26 de Agosto de 2009.

Unidad I Introducción a las tecnologías Web. 1.1 Perspectiva histórica del Internet Historia de Internet Internet surgió de un proyecto desarrollado en Estados Unidos para apoyar a sus fuerzas militares. Luego de su creación fue utilizado por el gobierno, universidades y otros centros académicos. Internet ha supuesto una revolución sin precedentes en el mundo de la informática y de las comunicaciones. Los inventos del telégrafo, teléfono, radio y ordenador sentaron las bases para esta integración de capacidades nunca antes vivida. Internet es a la vez una oportunidad de difusión mundial, un mecanismo de propagación de la información y un medio de colaboración e interacción entre los individuos y sus ordenadores independientemente de su localización geográfica. Orígenes de Internet La primera descripción documentada acerca de las interacciones sociales que podrían ser propiciadas a través del networking (trabajo en red) está contenida en una serie de memorándums 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 Galáctica). El concibió una red interconectada globalmente a través 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 investigación 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 teoría de conmutación de paquetes. Kleinrock convenció a Roberts de la factibilidad teórica de las comunicaciones vía paquetes en lugar de circuitos, lo cual resultó ser un gran avance en el camino hacia el trabajo informático 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 través de una línea telefónica conmutada de baja velocidad, creando así la primera (aunque reducida) red de ordenadores de área amplia jamás construida. El resultado del experimento fue la constatación de que los ordenadores de tiempo compartido podían trabajar juntos correctamente, ejecutando programas y recuperando datos a discreción en la máquina remota, pero que el sistema telefónico de conmutación de circuitos era totalmente inadecuado para esta labor. La convicción de Kleinrock acerca de la necesidad de la conmutación de paquetes quedó pues confirmada. A finales de 1966 Roberts se trasladó a la DARPA a desarrollar el concepto de red de ordenadores y rápidamente confeccionó su plan para ARPANET, publicándolo en 1967. En la conferencia en la que presentó el documento se exponía también 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 había escrito un documento sobre redes de conmutación de paquetes para comunicación vocal segura en el ámbito militar, en 1964. Ocurrió que los trabajos del MIT (1961-67), RAND (1962-65) y NPL (1964-67) habían discurrido en paralelo sin que los investigadores hubieran conocido el trabajo de los demás. La palabra packet (paquete) fue adoptada a partir del trabajo del NPL y la velocidad de la línea propuesta para ser usada

en el diseño de ARPANET fue aumentada desde 2,4 Kbps hasta 50 Kbps (5). En Agosto de 1968, después 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 diseño de la arquitectura de la ARPANET global, la topología de red y el aspecto económico fueron diseñados 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 teoría de conmutación de paquetes de Kleinrock y su énfasis en el análisis, diseño y medición, 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 incluía NLS, un primitivo sistema hipertexto en el Instituto de Investigación 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 traducción de direcciones así como un directorio de RFCs ( Request For Comments ). Un mes más 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 añadieron dos nodos en la Universidad de California, Santa Bárbara, y en la Universidad de Utah. Estos dos últimos nodos incorporaron proyectos de visualización de aplicaciones, con Glen Culler y Burton Fried en la UCSB investigando métodos para mostrar funciones matemáticas mediante el uso de "storage displays" ( N. del T. : mecanismos que incorporan buffers de monitorización distribuidos en red para facilitar el refresco de la visualización) para tratar con el problema de refrescar sobre la red, y Robert Taylor y Ivan Sutherland en Utah investigando métodos de representación en 3-D a través 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 reseñar que la investigación incorporó tanto el trabajo mediante la red ya existente como la mejora de la utilización de dicha red. Esta tradición continúa hasta el día de hoy. Se siguieron conectando ordenadores rápidamente a la ARPANET durante los años 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 implementación 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 demostración de ARPANET en la International Computer Communication Conference . Esta fue la primera demostración pública de la nueva tecnología de red. Fue también en 1972 cuando se introdujo la primera aplicación "estrella": el correo electrónico. En Marzo, Ray Tomlinson, de BBN, escribió el software básico de envío-recepción de mensajes de correo electrónico, impulsado por la necesidad que tenían los desarrolladores de ARPANET de un

mecanismo sencillo de coordinación. En Julio, Roberts expandió su valor añadido escribiendo el primer programa de utilidad de correo electrónico para relacionar, leer selectivamente, almacenar, reenviar y responder a mensajes. Desde entonces, la aplicación de correo electrónico se convirtió en la mayor de la red durante más de una década. Fue precursora del tipo de actividad que observamos hoy día en la World Wide Web , es decir, del enorme crecimiento de todas las formas de tráfico persona a persona. Conceptos iniciales sobre Internetting La ARPANET original evolucionó hacia Internet. Internet se basó en la idea de que habría múltiples redes independientes, de diseño casi arbitrario, empezando por ARPANET como la red pionera de conmutación de paquetes, pero que pronto incluiría redes de paquetes por satélite, redes de paquetes por radio y otros tipos de red. Internet como ahora la conocemos encierra una idea técnica clave, la de arquitectura abierta de trabajo en red. Bajo este enfoque, la elección de cualquier tecnología de red individual no respondería a una arquitectura específica de red sino que podría ser seleccionada libremente por un proveedor e interactuar con las otras redes a través del metanivel de la arquitectura de Internetworking (trabajo entre redes). Hasta ese momento, había un sólo método para "federar" redes. Era el tradicional método de conmutación de circuitos, por el cual las redes se interconectaban a nivel de circuito pasándose bits individuales síncronamente a lo largo de una porción de circuito que unía un par de sedes finales. Cabe recordar que Kleinrock había mostrado en 1961 que la conmutación de paquetes era el método de conmutación más eficiente. Juntamente con la conmutación de paquetes, las interconexiones de propósito especial entre redes constituían otra posibilidad. Y aunque había otros métodos limitados de interconexión de redes distintas, éstos requerían que una de ellas fuera usada como componente de la otra en lugar de actuar simplemente como un extremo de la comunicación para ofrecer servicio end-to-end (extremo a extremo). En una red de arquitectura abierta, las redes individuales pueden ser diseñadas 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 diseñada de acuerdo con su entorno específico 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 geográfico, aunque ciertas consideraciones pragmáticas 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 paquetería por radio, pero más 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 paquetería por radio fue un protocolo extremo a extremo seguro que pudiera mantener la comunicación efectiva frente a los cortes e interferencias de radio y que pudiera manejar las pérdidas intermitentes como las causadas por el paso a través de un túnel o el bloqueo a nivel local. Kahn pensó primero en desarrollar un protocolo local sólo para la red de paquetería por radio porque ello le hubiera evitado tratar con la multitud de sistemas operativos distintos y continuar usando NCP. Sin embargo, NCP no tenía capacidad para direccionar redes y máquinas más allá de un destino IMP en ARPANET y de esta manera se requerían ciertos cambios en el NCP. La premisa era que ARPANET no podía ser cambiado en este aspecto. El NCP se basaba en ARPANET para proporcionar seguridad

extremo a extremo. Si alguno de los paquetes se perdía, el protocolo y presumiblemente cualquier aplicación soportada sufriría una grave interrupción. En este modelo, el NCP no tenía control de errores en el host porque ARPANET había de ser la única red existente y era tan fiable que no requería ningún control de errores en la parte de los host s. Así, Kahn decidió desarrollar una nueva versión del protocolo que pudiera satisfacer las necesidades de un entorno de red de arquitectura abierta. El protocolo podría eventualmente ser denominado "Transmisson-Control Protocol/Internet Protocol" (TCP/IP, protocolo de control de transmisión /protocolo de Internet). Así como el NCP tendía a actuar como un driver (manejador) de dispositivo, el nuevo protocolo sería más 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 contenía ambos componentes). El equipo de Stanford, dirigido por Cerf, produjo las especificaciones detalladas y al cabo de un año hubo tres implementaciones independientes de TCP que podían interoperar. Este fue el principio de un largo periodo de experimentación y desarrollo para evolucionar y madurar el concepto y tecnología de Internet. Partiendo de las tres primeras redes ARPANET, radio y satélite y de sus comunidades de investigación iniciales, el entorno experimental creció hasta incorporar esencialmente cualquier forma de red y una amplia comunidad de investigación y desarrollo [REK78]. Cada expansión afrontó nuevos desafíos. 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 investigación del MIT empezaron a buscar la implementación de TCP más sencilla y compacta posible. La desarrollaron, primero para el Alto de Xerox (la primera estación de trabajo personal desarrollada en el PARC de Xerox), y luego para el PC de IBM. Esta implementación 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, podían ser parte de Internet. En los años 80, el desarrollo de LAN, PC y estaciones de trabajo permitió que la naciente Internet floreciera. La tecnología 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 número de hosts (el modelo original de ARPANET) a tener muchas redes dio lugar a nuevos conceptos y a cambios en la tecnología. 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 gestión. Para facilitar el uso de Internet por sus usuarios se asignaron nombres a los host s de forma que resultara innecesario recordar sus direcciones numéricas. Originalmente había un número muy limitado de máquinas, por lo que bastaba con una simple tabla con todos los ordenadores y sus direcciones asociadas. El cambio hacia un gran número de redes gestionadas independientemente (por ejemplo, las LAN)

significó que no resultara ya fiable tener una pequeña tabla con todos los host s. Esto llevó a la invención del DNS ( Domain Name System , sistema de nombres de dominio) por Paul Mockapetris de USC/ISI. El DNS permitía un mecanismo escalable y distribuido para resolver jerárquicamente los nombres de los host s (por ejemplo, www.acm.org o www.ati.es ) en direcciones de Internet. El incremento del tamaño de Internet resultó también un desafío para los routers . Originalmente había un sencillo algoritmo de enrutamiento que estaba implementado uniformemente en todos los routers de Internet. A medida que el número de redes en Internet se multiplicaba, el diseño inicial no era ya capaz de expandirse, por lo que fue sustituido por un modelo jerárquico de enrutamiento con un protocolo IGP ( Interior Gateway Protocol , protocolo interno de pasarela) usado dentro de cada región de Internet y un protocolo EGP ( Exterior Gateway Protocol , protocolo externo de pasarela) usado para mantener unidas las regiones. El diseño permitía que distintas regiones utilizaran IGP distintos, por lo que los requisitos de coste, velocidad de configuración, robustez y escalabilidad, podían ajustarse a cada situación. Los algoritmos de enrutamiento no eran los únicos en poner en dificultades la capacidad de los routers , también lo hacía el tamaño de la tablas de direccionamiento. Se presentaron nuevas aproximaciones a la agregación de direcciones (en particular CIDR, Classless Interdomain Routing , enrutamiento entre dominios sin clase) para controlar el tamaño de las tablas de enrutamiento. A medida que evolucionaba Internet, la propagación de los cambios en el software, especialmente el de los host s, se fue convirtiendo en uno de sus mayores desafíos. DARPA financió a la Universidad de California en Berkeley en una investigación sobre modificaciones en el sistema operativo Unix, incorporando el TCP/IP desarrollado en BBN. Aunque posteriormente Berkeley modificó esta implementación del BBN para que operara de forma más eficiente con el sistema y el kernel de Unix, la incorporación de TCP/IP en el sistema Unix BSD demostró ser un elemento crítico en la difusión 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 informática. 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 aceptación de Internet. Uno de los desafíos más interesantes fue la transición del protocolo para host s de ARPANET desde NCP a TCP/IP el 1 de enero de 1983. Se trataba de una ocasión muy importante que exigía que todos los host s se convirtieran simultáneamente o que permanecieran comunicados mediante mecanismos desarrollados para la ocasión. La transición fue cuidadosamente planificada dentro de la comunidad con varios años de antelación a la fecha, pero fue sorprendentemente sobre ruedas (a pesar de dar la lugar a la distribución de insignias con la inscripción "Yo sobreviví a la transición a TCP/IP"). TCP/IP había sido adoptado como un estándar por el ejército norteamericano tres años antes, en 1980. Esto permitió al ejército empezar a compartir la tecnología DARPA basada en Internet y llevó a la separación final entre las comunidades militares y no militares. En 1983 ARPANET estaba siendo usada por un número significativo de organizaciones operativas y de investigación y desarrollo en el área de la defensa. La transición desde NCP a TCP/IP en ARPANET permitió la división en una MILNET para dar soporte a requisitos operativos y una ARPANET para las necesidades de investigación. Así, en 1985, Internet estaba firmemente establecida como una tecnología 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 electrónico se empleaba ampliamente entre varias

comunidades, a menudo entre distintos sistemas. La interconexión entre los diversos sistemas de correo demostraba la utilidad de las comunicaciones electrónicas entre personas. La transici1ón hacia una infraestructura global Al mismo tiempo que la tecnología Internet estaba siendo validada experimentalmente y usada ampliamente entre un grupo de investigadores de informática se estaban desarrollando otras redes y tecnologías. La utilidad de las redes de ordenadores (especialmente el correo electrónico 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 años 70 las redes de ordenadores comenzaron a difundirse allá donde se podía encontrar financiación para las mismas. El Departamento norteamericano de Energía (DoE, Deparment of Energy ) estableció MFENet para sus investigadores que trabajaban sobre energía de fusión, mientras que los físicos de altas energías fueron los encargados de construir HEPNet. Los físicos de la NASA continuaron con SPAN y Rick Adrion, David Farber y Larry Landweber fundaron CSNET para la comunidad informática académica y de la industria con la financiación inicial de la NFS ( National Science Foundation , Fundación Nacional de la Ciencia) de Estados Unidos. La libre diseminación del sistema operativo Unix de ATT dio lugar a USENET, basada en los protocolos de comunicación UUCP de Unix, y en 1981 Greydon Freeman e Ira Fuchs diseñaron BITNET, que unía los ordenadores centrales del mundo académico siguiendo el paradigma de correo electrónico como "postales". Con la excepción de BITNET y USENET, todas las primeras redes (como ARPANET) se construyeron para un propósito 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. Además, estaban empezando a proponerse tecnologías alternativas en el sector comercial, como XNS de Xerox, DECNet, y la SNA de IBM (8). Sólo restaba que los programas ingleses JANET (1984) y norteamericano NSFNET (1985) anunciaran explícitamente que su propósito era servir a toda la comunidad de la enseñanza superior sin importar su disciplina. De hecho, una de las condiciones para que una universidad norteamericana recibiera financiación de la NSF para conectarse a Internet era que "la conexión estuviera disponible para todos los usuarios cualificados del campus". En 1985 Dennins Jenning acudió desde Irlanda para pasar un año en NFS dirigiendo el programa NSFNET. Trabajó con el resto de la comunidad para ayudar a la NSF a tomar una decisión crítica: si TCP/IP debería 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 académica en general, junto a la necesidad de desarrollar una estrategia para establecer esta infraestructura sobre bases independientes de la financiación pública directa. Se adoptaron varias políticas y estrategias para alcanzar estos fines. La NSF optó también por mantener la infraestructura organizativa de Internet existente (DARPA) dispuesta jerárquicamente bajo el IAB ( Internet Activities Board , Comité de Actividades de Internet). La declaración pública de esta decisión firmada por todos sus autores (por los grupos de Arquitectura e Ingeniería 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 había hecho la transición desde una red construida con routers de la comunidad investigadora (los routers Fuzzball de David Mills) a equipos comerciales. En su vida de ocho años y

medio, el backbone había crecido desde seis nodos con enlaces de 56Kb a 21 nodos con enlaces múltiples de 45Mb.Había visto crecer Internet hasta alcanzar más 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 financiación (200 millones de dólares entre 1986 y 1995) y de la calidad de los protocolos fue tal que en 1990, cuando la propia ARPANET se disolvió, TCP/IP había 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 Información. El papel de la documentación Un aspecto clave del rápido crecimiento de Internet ha sido el acceso libre y abierto a los documentos básicos, especialmente a las especificaciones de los protocolos. Los comienzos de Arpanet y de Internet en la comunidad de investigación universitaria estimularon la tradición académica de la publicación abierta de ideas y resultados. Sin embargo, el ciclo normal de la publicación académica tradicional era demasiado formal y lento para el intercambio dinámico 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 , petición de comentarios). Estos memorándums pretendieron ser una vía informal y de distribución rápida para compartir ideas con otros investigadores en redes. Al principio, las RFC fueron impresas en papel y distribuidas vía 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 accedía vía FTP. Hoy en día, desde luego, están disponibles en el World Wide Web en decenas de emplazamientos en todo el mundo. SRI, en su papel como Centro de Información en la Red, mantenía los directorios online . Jon Postel actuaba como editor de RFC y como gestor de la administración centralizada de la asignación de los números de protocolo requeridos, tareas en las que continúa hoy en día. El efecto de las RFC era crear un bucle positivo de realimentación, 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 prepararía un documento de especificación. Tal especificación seria entonces usada como la base para las implementaciones por parte de los equipos de investigación. Con el paso del tiempo, las RFC se han enfocado a estándares de protocolo –las especificaciones oficiales- aunque hay todavía RFC informativas que describen enfoques alternativos o proporcionan información de soporte en temas de protocolos e ingeniería. Las RFC son vistas ahora como los documentos de registro dentro de la comunidad de estándares y de ingeniería en Internet. El acceso abierto a las RFC –libre si se dispone de cualquier clase de conexión 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 electrónico ha supuesto un factor determinante en todas las áreas de Internet, lo que es particularmente cierto en el desarrollo de las especificaciones de protocolos, estándares técnicos e ingeniería en Internet. Las primitivas RFC a menudo presentaban al resto de la comunidad un conjunto de ideas desarrolladas por investigadores de un solo lugar. Después de empezar a usarse el correo electrónico, el modelo de autoría cambió: las RFC pasaron a ser presentadas por coautores con visiones en común, independientemente de su localización. Las listas de correo especializadas ha sido usadas ampliamente en el desarrollo de la especificación de

protocolos, y continúan siendo una herramienta importante. El IETF tiene ahora más de 75 grupos de trabajo, cada uno dedicado a un aspecto distinto de la ingeniería en Internet. Cada uno de estos grupos de trabajo dispone de una lista de correo para discutir uno o más borradores bajo desarrollo. Cuando se alcanza el consenso en el documento, éste puede ser distribuido como una RFC. Debido a que la rápida expansión actual de Internet se alimenta por el aprovechamiento de su capacidad de promover la compartición de información, deberíamos entender que el primer papel en esta tarea consistió en compartir la información acerca de su propio diseño y operación a través de los documentos RFC. Este método único de producir nuevas capacidades en la red continuará siendo crítico para la futura evolución 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 están desarrollando nuevas técnicas de conexión que acelerarán la capacidad de transferencia entre servidores. Sus objetivos están enfocados a la educación y la investigación académica. Además buscan aprovechar aplicaciones de audio y video que demandan más capacidad de transferencia de ancho de banda.

1.2

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

Estándares:

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 transacción de la Web (WWW). HTTP fue desarrollado por el consorcio W3C y la IETF, colaboración que culminó en 1999 con la publicación de una serie de RFC, siendo el más importante de ellos el RFC 2616, que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador o un spider) se lo conoce como "user agent" (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un URL. Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. Transacciones HTTP Una transacción HTTP consiste de un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el código de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos

permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario. Un encabezado es un bloque de datos que precede a la información propiamente dicha, por lo que muchas veces se hace referencia a él como metadato —porque tiene datos sobre los datos—. Si se reciben líneas 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 carácter guión ( - ) 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 algún límite 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 quizás necesiten obtener esta información de otro lugar. Los elementos de esta lista deben estar separados por una coma, como lo dice la especificación HTTP: tipo, tipo.

 HTTP_USER_AGENT. El navegador que utiliza el cliente para realizar la petición. El formato general para esta variable es: software/versión librería/versión. El servidor envía al cliente:

 Un código de estado que indica si la petición fue correcta o no. Los códigos de error típicos indican que el archivo  

solicitado no se encontró, que la petición no se realizó de forma correcta o que se requiere autenticación para acceder al archivo. La información propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como gráficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP. Información 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 sólo tienen sentido en una dirección. Versiones HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el servidor usa la misma o una anterior en su respuesta. 0.9 Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el cliente no puede enviarle mucha información al servidor. HTTP/1.0 (mayo 1996) Esta es la primera revisión del protocolo que especifica su versión en las comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy. HTTP/1.1 (junio 1999) Versión actual; las conexiones persistentes están activadas por defecto y funcionan bien con los proxies. También soporta peticiones en paralelo (pipelining), permitiendo enviar múltiples peticiones a la vez, lo cual hace que el servidor pueda prepararse para una sobrecarga de trabajo y servir las solicitudes más rápidamente al cliente. HTTP/1.2 Los primeros borradores de 1995 del documento PEP — an Extension Mechanism for HTTP (el cuál propone el Protocolo de Extensión 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 diseño del World-Wide Web sigue el modelo cliente-servidor: un paradigma de división del trabajo informático en el que las tareas se reparten entre un número de clientes que efectúan peticiones de servicios de acuerdo con un protocolo, y un número 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) Diseñar 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 animación, fragmento de vídeo, etc. Es decir, cualquier tipo de información en formato electrónico. 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 información sobre la estructura y el formato de representación 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 recuperación de la información, en uso en la Internet, esta información es vital para que los clientes (ver el siguiente punto) puedan acceder a dicha información. d) Desarrollar aplicaciones cliente para todo tipo de plataforma y resolver el problema de cómo acceder a información que está almacenada y es accesible a través de protocolos diversos (FTP, NNTP, Gopher, HTTP, X.500, WAIS, etc.) y representar información multiformato (texto, gráficos, sonidos, fragmentos de vídeo, 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 URL’s. Los URL (Uniform Resource Locator) son una notación estándar para la especificación 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 localización y el método de acceso de cualquier recurso de la red (Berners-Lee, Masinter y McCahill, 1994). No sólo hay más de dos millones de ordenadores conectados a los varios miles de redes que forman la Internet, sino que existen múltiples protocolos o formas diferentes de acceder a la información (ftp, gopher, http, etc.). Los URL aportan esos dos datos esenciales: dónde se encuentra un recurso y cómo se puede acceder a él. La sintaxis de los URL es la siguiente: URL:<esquema>:<parte-específica-del-esquema> El esquema es un término convenido que representa el método de acceso a un recurso. La parte específica del esquema informa sobre su localización en la red, de un modo que depende de cada método de acceso. Un ejemplo nos ayudará a entender esto. Cuando utilizamos ftp anónimo 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 sería éste: Al recuperar un fichero mediante ftp anónimo usamos "anonymous" como nombre de usuario, y nuestra dirección de correo electrónico como password. En los URL esta información se omite dado que es conocida. Sin embargo, es posible incluirla si, por ejemplo, no se trata de ftp anónimo, sino que se necesita especificar un usuario real y su password. La sintaxis genérica 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 estándar 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 información 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 transmisión de una lista de nombres de ficheros (un directorio). "a" solicita una transmisión de líneas de texto. "i" solicita una transmisión binaria. La utilidad, y la necesidad, de una notación 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 designación y caracterización de objetos persistentes de la red, inspirados en los URL pero que irían más allá: debería ser posible, por ejemplo, asignar un URN (Uniform Resource Name) invariable para un objeto, aunque cambiara su path e incluso su método de acceso. Un sistema distribuido (similar al DNS o Domain Name System) resolveria un URN en uno o varios URL aplicando criterios de optimización de recursos (como proximidad al solicitante). Persistencia en http –Cookies. Uno de los mecanismos más usados para mantener persistencia es el mecanismo de cookies, inventado por Netscape y hoy en día aceptado por casi todos los browsers, en especial los más populares. El concepto es que mediante un header del protocolo HTTP el server pueda almacenar información en el cliente. A esta información 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 prácticamente no puede utilizar la mayoría de los servicios del site. Cuando el server envía un header con un cookie el browser, si acepta cookies, guarda la información enviada en un archivo de texto con un formato especial. Cada vez que el browser solicita una página del dominio que envió la cookie re-envia la cookie al site, de esta forma es posible mantener persistencia. La información que puede guardarse en una cookie esta limitada por lo que habitualmente se utiliza la misma para mantener el identificador de sesión del usuario almacenándose 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 función setcookie cuya sintaxis es la siguiente: int=setcookie(nombre, valor, expiración, 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 más 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 función 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 página se verifica si el usuario tiene seteada la cookie con nombre “session” si la tiene se recupera el valor de la sesión, si no la tiene se crea un identificador de sesión nuevo y único y se setea la cookie correspondiente con el vencimiento que corresponde según la duración que uno considere necesaria. Luego el identificador de sesión es accesible en cada página para almacenar valores por ejemplo en la base de datos como el nombre del usuario, preferencias de la sesión y otros valores. La recuperación de la cookie y su creación en caso de no existir se puede colocar en un modulo php que luego se incluye en cada página por ejemplo mod_session.php solo hay que recordar en cada página 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 sesión actual.

1.2.3 Métodos http. El conjunto de métodos comunes para HTTP/1.1 se define a continuación. Aunque esta serie se puede ampliar, los métodos adicionales que no se puede suponer que comparten la misma semántica para los clientes por separado extendido y servidores. La solicitud de acogida-campo de cabecera deberá acompañar todas las peticiones HTTP/1.1. Métodos de seguridad y idempotente métodos seguros Implementadores deben ser conscientes de que el software representa al usuario en sus interacciones a través de Internet, y debe tener cuidado para que el usuario sea consciente de las acciones que podría adoptar medidas que puedan tener un significado inesperado a sí mismos. En particular, la Convención ha establecido que los métodos GET y cabeza no debe tener la importancia de tomar una acción que no sea de recuperación. Estos métodos deben ser considerados "seguros". Esto permite a los agentes de usuario para representar a otros métodos, como POST, PUT y DELETE, de una manera especial, para que el usuario sea consciente del hecho de que una acción 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 dinámicos consideran que una característica. La distinción importante aquí es que el usuario no ha solicitado los efectos secundarios, por lo tanto, no pueden ser considerados responsables de ellos.

Métodos idempotente Los métodos también pueden tener la característica de "idempotencia" en el que (aparte de los errores o problemas de caducidad), los efectos secundarios de N> 0 solicitudes idénticas es el mismo que para una sola solicitud. Los métodos GET, HEAD, PUT y DELETE comparten esta propiedad. Además, las opciones de métodos 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 métodos de ejecución en esa secuencia se idempotente. (Una secuencia es idempotente si una ejecución ú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ó más tarde en la misma secuencia. Una secuencia que no tiene efectos secundarios es idempotente, por definición (siempre que no operaciones simultáneas se ejecutan en el mismo conjunto de recursos). OPTIONS El método de opciones representa una solicitud de información sobre las opciones de comunicación disponibles en la petición / respuesta de la cadena identificados por el URI de la petición. Este método 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 acción de recursos o el inicio de una recuperación de los recursos. Las respuestas a este método 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 comunicación debe ser indicado por el campo Content-Type. Aunque esta especificación no define ningún uso para ese órgano, las futuras extensiones de HTTP puede utilizar el conjunto de opciones para hacer las consultas más detalladas sobre el servidor. Un servidor que no es compatible con dicha extensión podrá descartar el cuerpo de la petición. Si la URI de la petición es un asterisco ("*"), la petición OPCIONES está destinado a aplicarse en el servidor, en general, más que a un recurso específico. Desde las opciones de comunicación de un servidor normalmente dependen de los recursos, el "*" solicitud sólo es útil como ping "o" no ", op tipo de método, no hace nada más 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 petición no es un asterisco, la solicitud de OPCIONES se aplica sólo a las opciones que están disponibles cuando se comunique con ese recurso. A 200 respuesta debería incluir todos los campos de encabezado que indica las características opcionales implementadas por el servidor y aplicable a ese recurso (por ejemplo, permitir), posiblemente con extensiones incluidas, no se define en esta especificación. El cuerpo de la respuesta, en su caso, también debe incluir información sobre las opciones de comunicación. El formato para tal cuerpo no está definido por esta especificación, pero podría ser definido por las próximas ampliaciones de HTTP. La negociación de contenidos pueden ser utilizados para seleccionar el formato de respuesta adecuados. Si no se incluye ningún 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 representación específica en la cadena de petición. Cuando un servidor proxy recibe una solicitud de opciones en un absoluteURI para el que se permite el reenvío 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 representación debe responder con sus propias opciones de comunicación. Si el Max-Forwards campo valor es un entero mayor que cero , el proxy debe disminuir el campo de valor cuando se envía la petición. Si no Max-Forwards campo está presente en la solicitud, la solicitud debe remitido no incluye un Max-Forwards campo. GET El método GET significa recuperar toda la información (en forma de una entidad) es identificado por el URI de la petición. Si la URI de la petición se refiere a un proceso de producción de datos, es que los datos obtenidos deberán 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 semántica de la GET cambiar el método 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 método que la entidad transferirá sólo bajo las circunstancias descritas por el campo de cabecera condicional (s). El método 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 múltiples o la transferencia de datos ya en poder del cliente. La semántica de la GET cambiar el método 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 sección El método 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 método HEAD es idéntico a GET, excepto que el servidor NO DEBE devolver un mensaje de cuerpo en la respuesta. La metainformación contenida en las cabeceras HTTP en respuesta a una solicitud de cabeza debe ser idéntica a la información enviada en respuesta a una solicitud GET. Este método puede ser usado para obtener metainformación acerca de la entidad que implica la petición, sin la transferencia de la entidad-cuerpo mismo. Este método se utiliza a menudo para probar los enlaces de hipertexto para la validez, la accesibilidad, y la reciente modificación. La respuesta a una solicitud de cabeza puede ser cacheable en el sentido de que la información 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 método 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 petición en la solicitud-Line. POST está diseñado para permitir un método uniforme para cubrir las siguientes funciones: - Anotación de los recursos existentes;

- Publicar un mensaje a un tablón de anuncios, grupos de noticias, listas de correo, o de un grupo similar de artículos; - Creación de un bloque de datos, como el resultado de la presentación de una forma, a un proceso de manipulación de datos; - Ampliación de una base de datos a través de una operación de anexión. La función real realizada por el método POST es determinada por el servidor y por lo general dependen de la URI de la petición. La entidad envió está subordinado a la URI de la misma manera que un archivo está subordinado a un directorio que lo contiene, un artículo de noticias está subordinado a un grupo de noticias al que se publique, o un registro está subordinado a una base de datos. La acción realizada por el método 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 debería 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 ubicación Las respuestas a este método 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 método PUT que la entidad adjuntos se almacenan en la Solicitud de suministro de URI. Si la URI de la petición se refiere a un recurso ya existente, la entidad cerrada debe ser considerado como una versión modificada de la que residen en el servidor de origen. Si la URI de la petición 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 través de la 201 (Creado) de respuesta. Si se modifica un recurso existente, ya sea el 200 (correcto) o 204 (Sin contenido) los códigos de respuesta debe enviarse para indicar la finalización con éxito de la petición. Si el recurso no puede ser creado o modificado con el URI de la petición, 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 través de una memoria caché y la URI de la petición identifica a una o más entidades en la actualidad en caché, las entradas deben ser tratados como rancio. Las respuestas a este método no son almacenables. La diferencia fundamental entre el puesto y las solicitudes se refleja en el diferente significado de la URI de la petición. El URI de una petición POST identifica el recurso que se encargará de la entidad cerrada. Ese recurso puede ser un proceso de aceptación 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 algún otro recurso. Si los deseos del servidor que la petición se aplica a una URI diferente, debe enviar un (301 Movido permanentemente) la respuesta, el agente de usuario puede entonces hacer

su propia decisión sobre si procede o no para redirigir la petición. Un solo recurso puede ser identificado por muchos URI diferentes. Por ejemplo, un artículo puede tener un URI para la identificación de "la versión actual", que es independiente de la URI de la identificación de cada versión particular. En este caso, una solicitud PUT en un URI general podría dar lugar a otros varios URIs se define por el servidor de origen. HTTP/1.1 no define cómo un método PUT afecta el estado de un servidor de origen. Solicitudes PUT debe obedecer a los requisitos de transmisión de mensajes que figuran en la sección 8.2. Salvo disposición en contrario de una entidad particular la cabecera, la entidad en los encabezados de la petición que se debe aplicar a los recursos creados o modificados por el PUT. DELETE Las solicitudes método Delete que el servidor de origen eliminar el recurso identificado por el URI de la petición. Este método puede ser anulado por la intervención humana (o de otros medios) en el servidor de origen. El cliente no se puede garantizar que la operación se ha realizado, incluso si el código de estado devuelto por el servidor de origen indica que la acción 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 intención 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 acción aún no ha sido promulgado, o 204 (Sin contenido) si la acción ha sido promulgada, pero la respuesta no incluye una entidad. Si la solicitud pasa a través de una memoria caché y la URI de la petición identifica a una o más entidades en la actualidad en caché, las entradas deben ser tratados como rancio. Las respuestas a este método no son almacenables. TRACE El método TRACE se utiliza para invocar un control remoto, circuito de capa de aplicación de devolución 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 petición 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 información de diagnóstico. El valor del campo de cabecera Via es de particular interés, ya que actúa como una huella de la cadena de petición. Uso de la Max-Forwards encabezado de campo permite al cliente para limitar la longitud de la cadena de petición, que es útil para la prueba de una cadena de proxies el reenvío de mensajes en un bucle infinito. Si la petición es válida, 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 método NO DEBEN ser almacenados en caché. CONEXIÓN

Esta especificación se reserva el nombre de método Connect para el uso con un proxy que puede cambiar de forma dinámica a ser un túnel (túnel SSL por ejemplo.

1.3. Introducción al HTML 1.3.1 HTML como un tipo SGML. SGML fue diseñado para permitir el intercambio de información entre distintas plataformas, soportes físicos, lógicos y diferentes sistemas de almacenamiento y presentación (bases de datos, edición electrónica, etc.), con independencia de su grado de complejidad. Un nuevo concepto de información Cuando se concibe un documento electrónico 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 además pueden estar almacenados en distintos ordenadores.

•

Un archivo puede contener la portada, otro la introducción, otro una parte de una hoja de cálculo, otro un gráfico, otro un organigrama, otro la bibliografía, 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 tamaño, 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 función 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 lógicade manera jerarquizada, en la que se definen conceptos como capítulos, tablas y párrafos y que configuran lo que se denomina estructura de los elementos del documento.

•

Elementos y entidades pueden coincidir: un elemento lógico como tabla puede ser también una entidad en un archivo hoja de cálculo

Dos tipos de contenido En toda comunicación se pueden distinguir dos niveles de información: 1. Por un lado, el conjunto de datos que componen lo que tradicionalmente entendemos por contenido, 2. y por otro, una información más sutil, que se superpone a ese contenido. Esta otra información es la negrita en un libro, el subrayado en un manuscrito, un tono alto de voz en una conversación y se denomina etiquetado (markup). La función del etiquetado es aportar información que por lo general refleja la estructura jerárquica 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 números, la puntuación, etc.) y el etiquetado (compuesto por caracteres de etiquetado, los cuales, en este caso concreto, son también letras, números y signos de puntuación. 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 cómo reflejar el diseño, esto es, si los títulos debían aparecer más 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 tenían sentido para la máquina concreta con la que se iba a imprimir. Las instrucciones podían contener códigos de control específicos que trasladados a otro entorno podían bloquear la composición tipográfica. Por lo demás de las veces, estas instrucciones, que estaban además intercaladas en el texto, imposibilitaban la reutilización posterior de la información. Si el texto era revisado con intención de reeditarlo, había que utilizar el mismo sistema de composición, para entonces probablemente obsoleto. Si se deseaba cambiar el diseño, había que manipular los archivos para modificar todos losa códigos, muchos encriptados u ocultos, como por ejemplo, el efecto de centrar un título escrito en negrita con letra Times Roman de 36 puntos. La utilización de técnicas informáticas de búsqueda y recuperación globales podían 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 lógica. Por ejemplo, si se cambiasen a negrita todos los extranjerismos que se hallaban en cursiva en un texto, también se convertirían de manera accidental, aunque automática, todas las referencias de obras en cursiva en la bibliografía, así como cualquier otra parte del texto resaltado con cursiva. El etiquetado procedimental es esta técnica que estamos describiendo, por medio de la cual un operario utiliza instrucciones crípticas y dependientes del funcionamiento de un sistema determinado para que ejecute una acción, como por ejemplo activar la tipografía, poner en negrita, centrar, etc. El etiquetado descriptivo por el contrario, identifica los elementos estructurales de un documento, determinando su estructura lógica, de manera que se solucionan muchos de los problemas mencionados. Ventajas del etiquetado descriptivo 1. En primer lugar, el estándar SGML utiliza un conjunto de caracteres basado en el estándar ASCII (American Standard Coding for the Interchange of Information), reconocido de manera prácticamente universal por cualquier tipo de plataforma y de sistema informático. Los caracteres especiales, que no están contemplados en el conjunto de caracteres ASCII (propios de sistemas de escritura distintos del inglés, símbolos matemáticos, 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 subordinación del etiquetado a los aspectos lógicos de la estructura de los documentos. SGML parte del criterio de que existe una relación directa entre cuestiones como el cambio de tipografía y una cabecera, la utilización de la cursiva para resaltar un término, el dibujo de un recuadro con un gráfico, etc.

En SGML todo el etiquetado es lógico, es decir, en lugar de utilizar códigos crípticos, se utilizan nombres de elementos, delimiatados por marcas que indican el comienzo y final de los objetos lógicos. Cómo son las etiquetas SGML En SGML, las etiquetas se distinguen del resto del texto mediante caracteres de delimitación. Estos delimitadores permiten que el software reconozca qué caracteres deben ser leídos en modo de ETIQUETA, y deben por ello traducirse al lenguaje concreto de composición o tratarse de manera específica, y qué otros caracteres de CONTENIDO deberán ser transferidos posteriormente a la aplicación 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 básicos entre los que se incluyen el paréntesis 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 imágenes gráficas o caracteres especiales (por ejemplo, • para un redondelito negro). ¿Cómo funciona SGML? Cualquier base de datos cuenta con una representación interna que indica, por ejemplo, dónde termina el campo de "nombres" y donde comienza el campo de "direcciones". Todos los procesadores de texto utilizan algún sistema de codificación interno para marcar cuestiones como la negrita, la cursiva, el sangrado, el centrado, etc. Pero el problema con estos códigos es que cada programa usa un sistema propio, sistemas que incluso cambian de una versión a otra en un mismo programa. Aunque existen programas para convertir, los problemas que esta disparidad ocasiona son considerables. Etiquetado genérico En las primeras reuniones del Comité que abordó la creación de SGML, una de las principales cuestiones que se debatieron fue la codificación genérica, esto es, un sistema de códigos universal e independiente de la aplicación, por medio del cual, por ejemplo

significara siempre párrafo y

indicara siempre un encabezado de primer nivel. La intención inicial era lograr especificar un conjunto de etiquetas que fueran válidas para un elevado número de documentos. Sin embargo, a pesar de que el principio de la codificación genérica está bien fundado, la variedad de documentos, así como la diversidad de elementos que contienen, lo hacen prácticamente inabordable. Se vislumbró además un segundo problema: ¿Qué se hace con los errores? ¿Existe algún 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 aún más difícil tarea de comprobar que los usuarios introducen los códigos en los lugares correctos? Cabecera Curiosamente, existía una respuesta a ambos problemas, y ésta llegó desde el entorno de la programación informática. Habitualmente, los lenguajes informáticos proporcionan al programador un conjunto de operaciones básicas "primitivas" que suelen agruparse en un cabecera (heading) que sirve para definir un conjunto

específico de instrucciones que utilizará el programa. Definición 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 códigos normalizados, sino que se convirtió en un lenguaje con el que se podía crear una definición del tipo de documento (DTD), mediante la que se definen con precisión aquellos elementos que son necesarios en la elaboración de un documento o un grupo de documentos estructurados de manera similar. Declaración 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 aparecerán dentro de los delimitadores, por ejemplo ); 2. y describen lo que cada elemento puede contener, el modelo de contenido Un capítulo se puede definir como algo que comienza con un título, seguido de una serie de párrafos, con subsecciones: El lenguaje SGML proporciona la sintaxis necesaria para realizar esta declaración. Cualquier sistema SGML la reconocería, gracias a la presencia de la marca finaliza la declaración de este elemento. El sistema reconoce la palabra reservada de SGML, PCDATA, dando a entender que "chptitle", "para" y "heading" no tienen ningún subelemento propio. Más bien contienen lo que se denomina datos de caracteres analizados sintácticamente: las letras, los números, la puntuación y los caracteres especiales concretos que constituyen el contenido. Al llegar a este punto el usuario crearía el documento utilizando el etiquetado declarado en la DTD, acompañado por los delimitadores apropiados procedentes de los datos de los caracteres: <para>It was a dark night, not stormy at all, no hint of a storm, really ... <para>A pirate ship appeared on the horizon ... ... Tal y como se puede suponer, las etiquetas que comienzan con el delimitador
para un párrafo podría definirse de la manera expuesta a continuación: El "public" entre comillas representa el valor por defecto. Todos los párrafos en los que el usuario no especifique topsec o public, tendrán el valor "public". <para secrecy=topsec>It was a dark night, not stormy at all, no hint of a storm, really ... <para>A pirate ship appeared on the horizon ... Adviértase que en algunas ocasiones puede utilizarse la minimización del etiquetado para ahorrar pulsaciones de teclas. (En el ejemplo previo se ha omitido la etiqueta de fin del primer párrafo, ya que la etiqueta de inicio del siguiente párrafo implica el final del elemento del primer párrafo. Además, se ha omitido el nombre del elemento "para" en la secuencia ). Existen varias técnicas de minimización válidas para las etiquetas de fin, así como para las etiquetas de inicio y para las especificaciones de atributos. La declaración 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 declaración SGML. Ese diagrama formal y normalizado le indica al sistema receptor exactamente -entre otra mucha información- el conjunto de caracteres, los delimitadores y las características opcionales de SGML que se están utilizando. (Por ejemplo, la minimización es algo que unos sistemas soportan y otros no). A menudo se omitirá la declaración 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 declaración 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 línea que indique que la DTD se edita como un texto público o se encuentra ya disponible en el sistema receptor (DTD es el acrónimo de Definición del Tipo de Documento, incluyéndose asimismo en dicha definición las directrices o convenciones que conforman una aplicación SGML).

•

que en consecuencia, el documento contendrá una muestra de documento. Dicha muestra es lo que se entendía 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 parámetros 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 declaración SGML definida por el estándar. La auténtica ventaja de esta secuenciación 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 informático muy preciso. Esto significa que un programa informático -un parser- puede leer la declaración SGML y aprender sus reglas, a continuación leer la DTD y aprender las reglas del etiquetado y finalmente determinar si la muestra de documento cumple dichas reglas. ¿Cómo se procesa un documento SGML? Se trata de una validación automática realizada por una máquina. Y en la medida en que asegura que el contenido que se está enviando a una base de datos o a una máquina de composición no sufrirá problemas excesivamente graves, no tendrá rivales en el mercado.

La función del parser es leer el documento SGML y separar los datos del etiquetado. El parser detecta cuándo el etiquetado ha sido minimizado y en tal caso lo expande. Si el contenido incluye referencias a una hoja de cálculo electrónica de un capítulo concreto (capítulo 2), y el gráfico del organigrama de otro capítulo (capítulo 6), dará las instrucciones pertinentes al sistema sobre cómo encontrar dichas entidades. Si el gráfico se halla en alguna notación de contenido de datos especial, generada por un programa de diseño de gráficos, 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 edición en su propio lenguaje interno -SGML las denomina instrucciones de procesamiento- éstas pasarán directamente a la aplicación. Si se ha utilizado el componente de sección marcada en SGML y ha indicado que algunas partes de su documento no han de aparecer en la versión editada, el parser sabrá que no tiene que enviarlas. Si se está utilizando el componente de declaración de comentarios SGML para enviar y recibir notas y mensajes entre los escritores y los editores, el parser también sabrá que no ha de enviarlos a la aplicación receptora. Todo esto y más. Todo esto y más, y lo que es más importante, sin que resulte visible al ojo humano. Esta lista -y se trata tan sólo 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 generación 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 estén bien estructurados; que se sirve de la estructura para dar a los usuarios una funcionalidad que nunca antes habían tenido. En un futuro no muy lejano, los usuarios encontrarán de gran utilidad toda la información que aparece en este artículo. Las complicaciones ocultas detrás de los interfaces intuitivos no representarán 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 integración de su software de hojas de cálculo, hipertextos y procesamiento de textos. Esta nueva generación de software trabajará directamente con las DTD y ofrecerá un enfoque lógico con respecto al tratamiento de la información -basado en la estructura, en los objetos y en los atributos- mucho más útil que los interfaces para índices, plantillas y hojas de estilo de hoy en día. "El intercambio de información independientemente del grado de complejidad" es uno de los principales objetivos de cualquier estándar. Es por ello que un estándar diseñado como un lenguaje para construir aplicaciones tendrá muchas posibilidades de triunfar en el mercado actual. Por lo tanto, la función de este artículo es presentar los componentes del lenguaje que se utilizan a la hora de diseñar aplicaciones, con el fin de que se conozcan todas las posibilidades que ofrece el estándar SGM La maquetación o marcación Las marcas o etiquetas en el proceso tradicional de edición En todas las editorial existe uno o varios especialistas cuya función es marcar el texto manuscrito para indicar el aspecto que debe tener en su forma impresa. Este proceso recibe el nombre de maquetación (markup, en inglés). Definiciones de maquetación 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 cómo se deben utilizar los tipos de letra, los tamaños, 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 diseños 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 clásicos de instrucciones para el cajista: "Times Roman 10/12 x 24", al comienzo de un capítulo indica que el capítulo debe ir en tipografía Times Roman de 10 puntos con un interlineado de 12 puntos, y una medida de 24 cíceros (línea 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 sangría desde el margen izquierdo. Una línea vertical coloreada a la izquierda indicará la extensión exacta de este ajuste. La maquetación electrónica Estas tres figuras del proceso de edición tradicional suelen reducirse en la actualidad a una sola, el maquetador. Los nuevos medios de edición electrónica agilizan enormemente un proceso que con frecuencia se subcontrata a empresas especializadas en maquetación y autoedición. El procesamiento de textos Prácticamente la totalidad de los programas informáticos de procesamiento de textos y sistemas de autoedición modernos disponen de códigos de maquetación. En estos programas, se utiliza el término "maquetar" para describir cualquier código o instrucción acerca del formato o diseño de un documento. La maquetación debe señalar como mínimo los cambios en el tipo de letra (negrita, cursiva etc.), los saltos de línea, los márgenes, etc. WYSIWYG Hoy en día, casi todos los procesadores de texto son del tipo WYSIWYG (What you see is what you get, 'Obtienes lo que ves'). En ellos el diseño se realiza sobre la pantalla por medio de teclas de función o mediante opciones de menú. De esta manera se insertan códigos 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 código de control (un carácter ASCII extendido de 8 bits), que al mismo tiempo cambia el color de la visualización en la pantalla. Este sistema se corresponde muy estrechamente con el subrayado ondulado y la nota al margen en "negrita" propia de la corrección tradicional de manuscritos. En los primeros sistemas WYSIWYG (como en las primeras versiones de WordStar), los códigos eran visibles en la pantalla. En los sistemas modernos normalmente queda oculto para el usuario. En muchos casos, existe una opción para visualizar el etiquetado. Por ejemplo, si el usuario de WordPerfect activa la opción de "mostrar códigos", los códigos que se visualizan en pantalla son términos significativos encerrados entre corchetes, como [Negr]para marcar la negrita[negr], (aunque el código es en realidad un solo carácter ASCII extendido).

1.3.2 Elementos del lenguaje HTML. ELEMENTOS BÁSICOS Tipo de Documento



Titulo

<TITLE>

Encabezado



Cuerpo



DEFINICIÓN ESTRUCTURAL Títulos



Alineamiento de Título



División

Alineamiento de Divisiones

Bloque de Cita

Enfasis

<EM>

Enfasis Fuerte

<STRONG>

Cita



Código



Ejemplo de Salida

<SAMP>

Entrada del Teclado



Variable



Definición



Dirección del Autor

Tamaño de letra grande



Tipo de letra pequeño

<SMALL>

FORMATO DE PRESENTACIÓN

N3.0b

Negritas



Itálicas



Subrayado



Tachado

<STRIKE>

N3.0b

Tachado

<S>

Subíndice

<SUB>

Exponente

<SUP>

Maquina de escribir



Preformateado

Ancho

Centrado



Parpadeando



Tamaño del tipo de letra



Cambiar el tamaño del tipo de letra



Tamaño de letra Base



Color del Tipo de Letra



N3.0b

Seleccionar Tipo de Letra



N3.0b

Texto de multicolumnas

<MULTICOL COLS=?>

N3.0b

Espacio entre columnas

<MULTICOL GUTTER=?>

N3.0b

Ancho de la columna

<MULTICOL WIDTH=?>

N3.0b

Espaciador

<SPACER>

N3.0b

Tipo de Espaciador

<SPACER TYPE=horizontal| vertical|block>

N3.0b

Tamaño del espaciador

<SPACER SIZE=?>

N3.0b

Dimensiones del Espaciador

<SPACER WIDTH=? HEIGHT=?>

N3.0b

Alineamiento del Espaciador

<SPACER ALIGN=left|right|center>

N1.0

N1.0

LIGAS Y GRÁFICAS Ligar algo



Ligar a un Ancla



N2.0

Ventana "blanco"



Define un Ancla en un documento Relación



Relación inversa



Mostrar Imagen



Alineamiento



N1.0

Alineamiento



Nombre Alternativo



Mapa Sensitivo



Mapa sensitivo del lado del Cliente Descripción del mapa

<MAP NAME="***">

Seciones del mapa



Dimensiones



Reborde



Espacio Marginal



N1.0

Portal de baja resolución



N1.1

Cliente jala

<META HTTP-EQUIV="Refresh" CONTENT="?; URL=URL">

N2.0

Objeto embebido

<EMBED SRC="URL">

N2.0

Tamaño del objeto <EMBED SRC="URL" WIDTH=? HEIGHT=?>

DIVISORES Párrafo

Alinear Texto

Salto de Liínea




Eliminar Textwrap




Barra Horizontal

---

Alineación

---

Grosor

---

Ancho

---

Porcentaje de Anchura

---

Línea Sólida

---

N1.0

No Salto de Línea



N1.0

Salto de Palabra

<WBR>

N1.0

LISTAS

Lista No Ordenada

(

antes de cada elemento de la lista)

Lista Compacta

Tipo de Marca

(para todas la lista)
• 
  
  (esta y subsecuentes)
  
  Lista Ordenada
  
  
  
  
  (
• antes de cada elemento de la lista)
  
  Lista Compacta
  
  
  
  
  Tipo de Numeración
  
  
  Número Inicial
  
  (Para toda la lista)
  
  
  1. 
     
     (esta y subsecuentes)
     
     
     
     
     (para toda la lista)
     
     
     1. 
        
        (Esta y subsecuentes)
        
        Lista de definiciones
        Lista Compacta
        
        
        
        
        Lista de Menús
        
        <MENU>
     2. 
        
        Lista compacta
        
        <MENU COMPACT>
        
        Lista de Directorios
        
        
        
        
        Lista compacta
        
        
        
        (
        =termino,
        =definición) (

        antes de cada elemento de la lista) (

        antes de cada elemento de la lista)
        
        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 minúsculas) Caracter Especial
        
        &#?;
        
        <
        
        <
        
        >
        
        >
        
        &
        
        &
        
        "
        
        "
        
        Marca Registrada TM
        
        ®
        
        Copyright
        
        ©
        
        Espacio no rompe línea
        
         
        
        FORMAS Definir Formas N2.0
        
        

        
        
        Subir Archivo

        Campo de entrada
        
        
        
        Nombre del Campo
        
        
        
        Valor del Campo
        
        
        
        Checado?
        
        
        
        Tamaño del campo
        
        
        
        Max Length
        
        
        
        Lista de Selección
        
        <SELECT>
        
        Nombre de la lista
        
        <SELECT NAME="***">
        
        # de opciones
        
        <SELECT SIZE=?>
        
        Opción Múltiple
        
        <SELECT MULTIPLE>
        
        Opción
        
        
        
        Opcioón por default
        
        
        
        Tamaño de la
        
        
        
        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
        
        
        
        Renglón de celda
        
        
        
        Alineamiento
        
        
        
        Celda de Tabla
        
        
        
        Alineamiento
        
        
        
        Alineamiento
        
        
        
        Alineamiento
        
        

        FRAMES N2.0

        Documento Frame



        N2.0

        Frames Horizontales



        N2.0

        Frames Horizontales



        N2.0

        Frames Verticales



        N2.0

        Frames Verticales



        N3.0b

        Ancho del Reborde



        N3.0b

        Rebordes



        N3.0b

        Color del Reborde



        N2.0

        Definir Frame



        N2.0

        Mostrar un Documento en el frame



        N2.0

        Nombre del Frame



        N2.0

        Ancho del margen



        N2.0

        Altura del Margen



        N2.0

        Barra de avance?



        N2.0

        Impedir cambio de tamaño



        N3.0b

        Rebordes



        N3.0b

        Color del Reborde



        N2.0

        Conenido fuera de Frames



        JAVA Applet

        <APPLET>

        Nombre del Applet

        <APPLET CODE="***">

        Parámetros

        <APPLET PARAM NAME="***">

        Localización del Applet

        <APPLET CODEBASE="URL">

        Identificador del Applet

        <APPLET NAME="***">

        Texto Alternativo

        <APPLET ALT="***">

        Alineamiento

        <APPLET ALIGN="LEFT|RIGHT|CENTER">

        Tamaño

        <APPLET WIDTH=? HEIGHT=?>

        Espaciado

        <APPLET HSPACE=? VSPACE=?>

        MISCELLANEAS

        N2.0

        Comentarios



        Prólogo de HTML 3.2



        Buscable



        Prompt



        Iniciar Búsqueda



        URL de este archivo



        Nombre base de la ventana



        Relación



        Meta Information

        <META>

        Hojas de estilo

        <STYLE>

        Scripts

        <SCRIPT>

        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: Código Visualización

        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 sólo utilizado para mejorar la visualización. Como los atributos de presentación van siendo

        desaprobados con cada versión del estándar HTML, y dado que los mismos efectos pueden lograrse usando hojas de estilo, recomendamos evitar el uso de atributos de presentación como "border". Ten en cuenta que las celdas vacías igual deben ser declaradas utilizando sus respectivos tags para lograr correctitud en el código. Cuando el contenido de una celda debe ser vacío, deberías usar siempre un espacio en blanco ( ) en su lugar. Esto hará que tu página sea más comatible, dado que ciertos navegadores tienen problemas al mostrar celdas vacías. 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 información 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 comúnmente encontrado en el encabezado de una tabla. En el ejemplo siguiente la misma "tabla simple" es definida pero esta vez con celdas de encabezado: Código Visualización

        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 características de estas celdas pueden ser logradas visualmente usando una celda simple con atributos de presentación (texto centrado y en negrita), pero las celdas de encabezado proporcionan más información oculta que puede ser útil para navegadores no visuales (los navegadores hablados pueden decir a los usuarios el contenido de una celda asociándolo inmediatamente con el encabezado correspondiente) y arañas (como las de los motores de búsqueda lo que ayudaría en la promoción 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 información 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 información de encabezado (ver el tag HTML th).

        Unificando celdas Para algunas tablas puedes necesitar unificar dos o más 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). Código Visualización

        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 definición de celda unificando dos celdas, es el equivalente unificado de dos definiciones de celda simple. Esto también funciona para unificar verticalmente con una pequeña diferencia debida a la naturaleza de las tablas HTML. Al unificar celdas verticalmente, las definiciones de celda en la columna afectada deberán ser omitidas. Observa el siguiente ejemplo, donde el campo 1, 4 y 7 son unificadas: Código Visualización

        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 Formularios Formularios Los formularios interactivos permiten a los autores de páginas Web poner elementos interactivos en sus páginas, 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 información rellenando campos o haciendo clic sobre botones, y luego presiona un botón de envío para enviarla a una dirección URL que se suele dirigir a una dirección de correo electrónico o a un script dinámico Web como PHP, ASP o CGI. La etiqueta FORM Los formularios están 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 cómo se enviarán las respuestas "POST" es el valor que envía los datos al agente de procesamiento almacenándolos en el cuerpo del formulario, en tanto que "GET" envía los datos agregándolos a la dirección URL y separándolos de la dirección con un signo de interrogación (para aprender más sobre los métodos POST y GET, consulte el artículo sobre protocolo HTTP) ACTION indica la dirección a la que se enviará la información (un script CGI o dirección de correo electrónico (mailto:dirección_de_correo_e@equipo)) Un atributo opcional de la etiqueta FORM es ENCTYPE, que especifica cómo 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 válido. 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 actúa como una especie de contenedor para almacenar elementos que permiten al usuario seleccionar o introducir datos. Todos los datos se enviarán a la dirección URL indicada en el atri buto ACTION de la etiqueta FORM, por el método 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 más 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 múltiples

        Envío de datos Cuando se envía un formulario (haciendo clic en el botón de envío), los datos del formulario se envían 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 símbolo de unión ("&"). Por lo tanto, los datos que se envían al script se verán así: campo1=valor1&field2;=valor2&field3;=valor3 Con el método GET (enviar los datos mediante una dirección 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 ningún 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 elección pueden adoptar uno de dos estados: checked (seleccionado) o unchecked (no seleccionado). Cuando la casilla es seleccionada, el par nombre/valor se envía al CGI.

        hidden: Este campo, que el navegador no muestra, es para definir una configuración única que se enviará al CGI como par nombre/valor. file: Un campo que permite al usuario especificar una ruta de archivo que lleva al archivo que se enviará con el formulario. Los tipos de archivo que pueden ser enviados deben especificarse utilizando el atributo ACCEPT de la etiqueta FORM. image: Un botón de envío personalizado que aparece cuando se ubica una imagen en la ubicación definida por el atributo SRC. password: Una casilla de texto donde los caracteres escritos aparecen como asteriscos para camuflar el texto de entrada. radio: Un botón que permite al usuario elegir entre varias opciones. Cada uno de estos botones debe tener el mismo atributo name. El par nombre/valor del botón radio seleccionado se enviará al CGI. Al aplicar el atributo checked para uno de estos botones se definirá como seleccionado de forma predeterminada. reset: Un botón de restauración para quitar todos los elementos en el formulario y restablecer sus valores predeterminados. submit: Un botón de envío para enviar el formulario. El texto en el botón puede definirse usando el atributo value. text: Una casilla de texto para escribir una línea de texto. El tamaño de la casilla puede definirse usando el atributo size y la extensión máxima del texto con el atributo maxlength. La etiqueta TEXTAREA La etiqueta TEXTAREA se usa para definir un cuadro de texto más grande que la línea simple propuesta por la etiqueta INPUT. Esta etiqueta tiene los siguientes atributos: cols: representa el número de caracteres que puede contener un línea rows: representa el número de líneas name: representa el nombre asociado con el cuadro de texto, que permite su identificación en el par nombre/valor. readonly: impide que el usuario modifique el texto predeterminado en el campo value: representa el valor predeterminado que se enviará al script si el usuario no ha escrito nada en el cuadro de texto La etiqueta SELECT La etiqueta SELECT sirve para crear una lista desplegable de elementos (especificados por las etiquetas OPTION dentro de ella). Los atributos de esta etiqueta son:

        name: name: representa el nombre asociado con la casilla de texto, que permite su identificación en el par nombre/valor. disabled: crea un lista desactivada, que aparece atenuada size: representa el número de líneas de la lista (este valor puede ser más grande que el número de elementos reales de la lista). multiple: Permite al usuario seleccionar varios campos de la lista

        ---

        Related Documents

        Programacion Web Unidad 1 By Roger

        June 2020 0

        Unidad 1 Programacion Por Metas.pdf

        May 2020 1

        Programacion De Iv Unidad

        November 2019 13

        Programacion Y Unidad 5to.docx

        April 2020 0

        Programacion Web Isc

        October 2019 9

        Roger

        June 2020 20

        Copyright © 2024 PDFCOKE.

        	No saltos de línea	Columnas por abarcar	Renglones por Abarcar	N1.1 Ancho deseado	N1.1 Ancho en Porcentaje	N3.0b Color de la Celda	Encabezado de la tabla		Evitar Salto de Línea	Columnas por abarcar	Renglones por abarcar	N1.1 Ancho deseado	N1.1 Ancho como Porcentaje	N3.0b Color de la Celda	Subtítulo de la Celda