Instituto Tecnologico Superior de Coatzacoalcos

guitarchanceSoftware and s/w Development

Aug 15, 2012 (5 years and 5 days ago)

1,165 views

Instituto Tecnológico Superior de Coatzacoalcos


Ing
eniería

e
n Sistemas Computacionales





























Apellido Paterno


Apellido Materno


Nombre(s)








Coatzacoalcos, Ver. 20
1
0

ANTOLOGÍA


Programación Web





Elaborado por:

Ing. José
Roberto Ramírez Guerrero










II




Unidad:

Instituto Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:

Programación Web



Introducción

Con la creación de Internet, se ha creado un medio para el desarrollo de aplic
a-
ciones en ese medio, h
oy en día la
buena parte de la
población,

hace uso de las
páginas Web y
de sus aplicaciones, de ahí nace
también la necesidad de poder
tener una página
, y brindar servicios a través de la Web.

La tecnología con el pasar del tiempo ha sufrido transformaciones que muchas
veces son de gra
n ayuda para el mundo cibernético; un ejemplo claro son los le
n-
guajes de programación, los cuales han ido
evolucionando, y en el desarrollo Web
no es la excepción.

En esta antología veremos los elementos necesarios para que el alumno pueda
desarrollar apli
caciones Web de una manera fácil y rápida.

















III




Unidad:

Instituto Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:

Programación Web



INTRODUCCIÓN









II

INDICE










III

JUSTIFICACIÓN









V

OBJETIVO GENERAL








V
I



UNIDAD I.
Introducción a las tecnologías Web.
.

1.1

Perspectiva histórica del Internet .

…..………………………………….. 1

1.2. Protocolo http (protocolo de transferencia de hipertexto)
………..………. 13

1.2.1

Arquitectura del WWW
…………………………………………….. 22

1.2.2 URL’s
…………………………………………………………..…….. 23

1.2.3 Métodos http.

…..…………………………………………………… 25

Persistencia en

http

Cookies.

1.3

Introducción al HTML.

……..……………………………………………… 29

Lenguaje de despliegue del web

1.3.1

HTML como un tipo SGML
……………………………………..…. 33

1.3.2

Elementos del lenguaje HTML
…………………………………......35

1.3.3

Tablas en HTML
………………………………………...…………... 58

1.3.4 Formularios
……………………………………………………………62

1.4

Evolución del desarrollo de aplicaciones Web
……………………………69

1.5

Hojas de estilo en cascada e introducción al XML
……………………….76



UNIDAD II. Desarrollo de aplicaciones Web.


2.1

Arquitectura de las aplicaciones
Web
……………………………………80

2.2

Lenguajes de programación del lado del cliente
………………………. 82

2.3

Lenguajes de programación del lado del servidor
…………………….. 85

2.4

Ambientes para el desarrollo de aplicaciones Web
…………………… 87

2.5

Metodologías para el

desarrollo de apli
caciones Web……………….. .88

2.6

Aspectos de seguridad
…………………………………………………….90


UNIDAD III. Programación del lado del servidor.


3.1
P
rocesamiento del lado del servidor
………………………………………….94








IV




Unidad:

Instituto Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:

Programación Web



3.2

Conceptos básicos de la herramienta de desarrollo
……………………….94

3.3 Oper
adores
……………………………………………………………………..97

3.4 Sentencias
……………………………………………………………………...98

3.5 Arreglos
…………………………………………………………………………100

3.6

Funciones y librerías
………………………………………………………… 104

3.7

Ejemplos prácticos
…………………………………………………………….109

3.8

Procesado de formulari
os
…………………………………………………….112

3.
9
Sesiones
………………………………………………………………………..116

3.10 Conectividad entre el servidor Web y el servidor de base de datos
……117

3.11 Manejo de archivos
………………………………………………………….119

3.12 Seguridad
……………………………………………………………….…….121


UNIDAD IV.
Procesamiento del lado del cliente


4.1

Lenguaje Script del cliente
……………………………………………….123

4.2

Modelo de objetos con lenguaje Script
…………………………………124

4.3

Objetos lenguaje Script ínter construidos
………………………………125

4.4

Eventos con lenguaje Script
……………………………………………..133

4.5

Validación de entrada de datos del lado del cliente
………………….. 136

4.6

Consideraciones del soporte del navegador
…………………………...138


UNIDAD V. Servicios Web XML


5.1

Visión general de servicios Web XML
…………………………………. 140

5.2
Tecnologías subyacentes
………………………………………………….141

5.2.1 SOAP
………………………………………………………………………142

5.2.2 WSDL
………………………………………………………………………143

5.2.3 UDDI
………………………………………………………………………..144

5.3

Publicación de un servicio WEB
…………………………………………145

5.4

Consumo de un servic
io WEB
……………………………………………146


Conclusión

……………………………………………………………………… .149

Fuentes Consultadas ……………………………………………………………151












V




Unidad:

Instituto Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:

Programación Web












J
ustificación


La presente antología pretende ser una herramienta para facilitar al estu
diante
,
el acceso al conocimiento y
estudio del manejo de l
os lenguajes de programación
web
, pretende ser de
apoyo en la formación e investigación

de

las unidades tem
á-
ticas, beneficia
ndo al alumno que la utilice
, porque ya no se atendrán a las expl
i-
caciones en clase, sino que con esta herram
ienta podrán repasar y adelantar los
temas de acuerdo a sus aptitudes y capacidades.


Esta antología ha sido desarrollada basándonos en información actual, además
de que ha sido construida de manera accesible, de tal forma que nuestros, puedan
utilizarla d
e manera fluida.
Será también esta antología, un instrumento de ref
e-
rencia para el alumno, al abordar los temas de cada unidad.










VI




Unidad:

Instituto Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:

Programación Web



Objetivo general


El estudiante conocerá los conceptos de comunicación de Internet, y desarrollará
aplicaciones de base de dat
os basadas en Web desde el lado del servidor y del
cliente








1




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



UNIDAD I.
Introducción a las tecnologías Web.

Objetivo: El estudiante comprenderá las características de una aplicación Web y
conocer los elementos que interactúan con ella.


1.1

Perspectiva
histórica del 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 s
in 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. I
n-
ternet es a la vez una oportunidad de difusión mundi
al, un mecanismo de prop
a-
gación de la información y un medio de colaboración e interacción entre los indiv
i-
duos 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 p
o-
drí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 Inst
i-
tute of Technology, en Agosto de 1962, en los cuales Licklider disc
ute sobre su
concepto de Galactic Network (Red Galáctica).


El concibió una red interconectada globalmente a través de la que cada uno pudi
e-
ra 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 pr
o-
grama de investigación en ordenadores de la DARPA desde Octubre de 1962.
Mientras trabajó en DARPA convenció a sus sucesores Ivan Sutherland, Bob Ta
y-
lor, y el investigador del MIT Lawrence G. Roberts de la imp
ortancia del concepto
de trabajo en red.


En Julio de 1961 Leonard Kleinrock publicó desde el MIT el primer documento s
o-
bre la teoría de conmutación de paquetes. Kleinrock convenció a Roberts de la
factibilidad teórica de las comunicaciones vía paquetes e
n 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í.









2




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Para explorar este terreno, en 1965, Roberts conectó un ordenador TX2 en Ma
s-
sachusetts 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 orde
nadores de tiempo compartido podían trabajar juntos correctame
n-
te, 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 inad
e-
cuado 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 1
967. 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 R
o-
ger Scantlebury del NPL. Scantlebury le habló a Roberts sobre su trabajo en el
NPL así como sobre el de P
aul Baran y otros en RAND. El grupo RAND había e
s-
crito 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) h
a-
bían disc
urrido 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 ARP
A-
NET 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 hubi
e-
ran refinado la estructura global y las especificaciones de ARPANET, DARPA la
n-
zó un RFQ para el desarrollo de uno de sus componentes clave: los conmutado
res
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 c
on 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 Ne
t-
work 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).









3




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



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 medic
ión, su Network Measurement
Center (Centro de Medidas de Red) en la UCLA fue seleccionado para ser el pr
i-
mer 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 (A
u-
mento 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 Ne
twork Information Center , liderado por Elizabeth (Jake) Feinler, que
desarrolló funciones tales como mantener tablas de nombres de host para la tr
a-
ducció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 pro
yectos de visualización de aplic
a-
ciones, 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 f
a-
c
i
litar 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 repr
e-
sentación en 3
-
D a través de la red.


Así, a finales de 1969, cuatro ordena
dores host fueron conectados
conjuntamente

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 c
ontinú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 fu
n-
cionalmente 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 impleme
n-
tación del NCP du
rante el periodo 1971
-
72, los usuarios de la red pudieron fina
l-
mente comenzar a desarrollar aplicaciones.









4




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



En Octubre de 1972, Kahn organizó una gran y muy exitosa demostración de A
R-
PANET en la International Computer Communication Conference .

Esta fue la pr
i-
mera 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 me
nsajes 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, r
e-
enviar y responder a mensajes. Desde entonces, la aplicación de correo electrón
i-
co 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 independi
entes, de diseño casi arbitrario, empezando por
ARPANET como la red pionera de conmutación de paquetes, pero que pronto i
n-
cluiría redes de paquetes por satélite, redes de paquetes por radio y otros tipos de
red. Internet como ahora la conocemos encierra un
a idea técnica clave, la de a
r-
quitectura abierta de trabajo en red.


Bajo este enfoque, la elección de cualquier tecnología de red individual no respo
n-
dería a una arquitectura específica de red sino que podría ser seleccionada libr
e-
mente por un proveedor e

interactuar con las otras redes a través del
meta nivel

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 rede
s se i
n-
terconectaban 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 co
nmutació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).








5




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web




En una red de arquitectura abierta, las redes individuales pueden ser diseñadas y
desarro
lladas separadamente y cada una puede tener su propia y única interfaz,
que puede ofrecer a los usuarios y/u otros proveedores, incluyendo otros prove
e-
dores de Internet. Cada red puede ser diseñada de acuerdo con su entorno esp
e-
cífico y los requerimientos
de los usuarios de aquella red.


No existen generalmente restricciones en los tipos de red que pueden ser incorp
o-
radas ni tampoco en su ámbito geográfico, aunque ciertas consideraciones pra
g-
máticas determinan qué posibilidades tienen sentido. La idea de ar
quitectura 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 p
a-
qu
e
tería por radio, pero más tarde se convirtió por derecho propio en un programa
separ
ado.


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 rad
io 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 cont
i-
nuar 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 premis
a 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 interr
upció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 satisf
a-
cer las necesidades de un entorno de red de arquitectura abierta. El protocolo p
o-
dría eventualmente ser denominado "Transmisson
-
Control Protocol/Internet Prot
o-
col" (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 prot
o-
colo sería más bien un protocolo de comunicaciones.








6




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



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 implemen
taciones independientes de TCP que podían
interoperar.


Este fue el principio de un largo periodo de experimentación y desarrollo para ev
o-
lucionar y madurar el concepto y tecnología de Internet. Partiendo de las tres pr
i-
meras redes ARPANET, radio y satéli
te 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 fu
n-
cionar 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 p
o-
sible.


La desarrollaron, primero para el Alto de Xerox (la primera estación de trabajo pe
r-
sonal desarrollada en el PARC de Xerox), y l
uego para el PC de IBM. Esta impl
e-
mentación operaba con otras de TCP, pero estaba adaptada al conjunto de aplic
a-
ciones y a las prestaciones de un ordenador personal, y demostraba que las est
a-
ciones 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 l
as est
a-
ciones 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 p
rimer 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;







7




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



por último, la clas
e C representa redes de área local (muchas redes con relativ
a-
mente pocos ordenadores).


Como resultado del crecimiento de Internet, se produjo un cambio de gran impo
r-
tancia para la red y su gestión. Para facilitar el uso de Internet por sus usuarios se
as
ignaron 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 direcci
o-
nes 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 , si
s-
tema de nombres de dom
inio) 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 impleme
n-
tado uniformemente en todos los routers de Internet. A medida que el número de
redes en Internet se multiplicaba, el diseño inicial n
o era ya capaz de expandirse,
por lo que fue sustituido por un modelo jerárquico de enrutamiento con un protoc
o-
lo 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
ajusta
rse 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 agreg
a-
ción de direcciones
(en particular CIDR, Classless Interdomain Routing , enrut
a-
miento entre dominios sin clase) para controlar el tamaño de las tablas de enrut
a-
miento.


A medida que evolucionaba Internet, la propagación de los cambios en el softw
a-
re, 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 inve
s-
tigación sobre modificaciones en el sistema operativo Unix, incorporando el
TCP/IP desarrollado en BBN. Aunque posteriormente
Berkeley modificó esta i
m-







8




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



plementació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

investig
a-
dora.


BSD empezó a ser utilizado en sus operaciones diarias por buena parte de la c
o-
munidad investigadora en temas relacionados con informática. Visto en perspect
i-
va, 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 ex
i-
tosa 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
al

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 mil
i-
tares y no militares. En 1983 ARPANET estaba siendo usada por un núm
ero sign
i-
ficativo 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
necesida
des 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 empez
a-
ba a ser empleada por otros grupos en sus comunicaciones diarias entre orden
a-
do
res. 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









9




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Al mismo tiempo que la tecnología Internet estaba siendo validada experimenta
l-
mente y usada ampliamente entre un grupo de investigadores de informática se
estaban desarrollando otras redes y tecnologías. La utilidad de la
s redes de ord
e-
nadores (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 r
e-
des de ord
enadores comenzaron a difundirse allá donde se podía encontrar fina
n-
ciación para las mismas.


El Departamento norteamericano de Energía (DoE, Deparment of Energy ) est
a-
bleció MFENet para sus investigadores que trabajaban sobre energía de fusión,
mientras q
ue 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 Fa
r-
ber 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, b
a-
sada en los protocolos de comunicación UUCP de Unix, y en 1981 Greydon
Fre
e-
man e Ira Fuchs diseñaron BITNET, que unía los ordenadores centrales del mu
n-
do 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 estudi
o-
sos; de ahí las escasas presiones por hacer estas redes compatibles y, en cons
e-
cuencia, 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 ser
vir 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 dir
i-
giendo 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 s
er obligatorio en el pr
o-







10




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



grama NSFNET. Cuando Steve Wolff llegó al programa NFSNET en 1986 recon
o-
ció 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 ind
e-
pendientes de la financiación pública directa. Se adoptaron varias políticas y estr
a-
tegias para alcanzar estos fines.


La NSF optó también por mantener la infraestructura org
anizativa de Internet exi
s-
tente (DARPA) dispuesta jerárquicamente bajo el IAB ( Internet Activities Board ,
Comité de Actividades de Internet). La declaración pública de esta decisión firm
a-
da 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
interoperabilidad

entre las partes de I
n-
ternet dependientes de DARPA y de NSF.


El backbone había hecho la transición de
sde una red construida con routers de la
comunidad investigadora (los routers Fuzzball de David Mills) a equipos comerci
a-
les. En su vida de ocho años y medio, el backbone había crecido desde seis n
o-
dos con enlaces de 56Kb a 21 nodos con enlaces múltiples d
e 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 margin
a-
do a la mayor parte de los restantes protocolos de grandes redes de ordenadores
e IP estaba en camin
o de convertirse en el servicio portador de la llamada Infrae
s-
tructura 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 abie
r-
to a los documentos básicos, especialmente a las

especificaciones de los protoc
o-
los.


Los comienzos de Arpanet y de Internet en la comunidad de investigación univers
i-
taria estimularon la tradición académica de la publicación abierta de ideas y resu
l-
tados. Sin embargo, el ciclo normal de la publicación a
cadémica tradicional era
demasiado formal y lento para el intercambio dinámico de ideas, esencial para
crear redes.









11




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



En 1969 S.Crocker, entonces en UCLA, dio un paso clave al establecer la serie de
notas RFC ( Request For Comments , petición de comentario
s). Estos memorá
n-
dums 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 Pr
otocol
, 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 m
undo. 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 inve
s-
tigación.


Con el paso del tiempo, las RFC se han enfocado a estándares de protocolo

las
especifica
ciones oficiales
-

aunque hay todavía RFC informativas que describen
enfoques alternativos o proporcionan información de soporte en temas de protoc
o-
los e ingeniería. Las RFC son vistas ahora como los documentos de registro de
n-
tro de la comunidad de estándar
es 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 especific
a-
ciones sean usadas a modo de ejemplo en las aulas universitar
ias o por empre
n-
dedores 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 especif
i-
caciones de protocolos, estándares
técnicos e ingeniería en Internet. Las primit
i-
vas 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 prese
n-
tadas por coautores con visiones en común, independientemente de su localiz
a-
ción.








12




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web




Las listas de correo especializadas ha sido usadas ampliamente en el desarrollo
de la especificación de protocolos, y continúan siendo una herramien
ta 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. Cua
ndo
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 aprov
e-
chamiento de su capacidad de promover la compartición de información, deberí
a-
mos entender qu
e el primer papel en esta tarea consistió en compartir la inform
a-
ción acerca de su propio diseño y operación a través de los documentos RFC. E
s-
te método único de producir nuevas capacidades en la red continuará siendo crít
i-
co para la futura evolución de In
ternet.


El futuro: Internet 2


Internet2 es el futuro de la red de redes y está formado actualmente por un co
n-
sorcio dirigido por 206 universidades que junto a la industria de comunicaciones y
el gobierno están desarrollando nuevas técnicas de conexión q
ue acelerarán la
capacidad de transferencia entre servidores.


Sus objetivos están enfocados a la educación y la investigación académica. Ad
e-
más buscan aprovechar aplicaciones de audio y video que demandan más cap
a-
cidad de transferencia de ancho de banda.


Es una red de cómputo sustentada en tecnologías de vanguardia que permiten
una alta velocidad en la transmisión de contenidos y que funciona independient
e-
mente de la Internet comercial actual.


Su origen se basa en el espíritu de colaboración entre las un
iversidades del mu
n-
do y su objetivo principal es desarrollar la próxima generación de aplicaciones t
e-
lemáticas para facilitar las misiones de investigación y educación de las univers
i-
dades, además de ayudar en la formación de personal capacitado en el uso
y m
a-
nejo de redes avanzadas de cómputo.


¿A qué se refiere con aplicaciones telemáticas?









13




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Son aplicaciones que utilizan las facilidades de telecomunicaciones e informática.
Internet es una red Telemática.


¿Qué son las redes de avanzadas? ¿Es sinónimo de r
edes de banda ancha o de
alto rendimiento?


Son redes que junto con la posibilidad de manejar mayores velocidades de tran
s-
misión, cuentan con otros atributos, como son:


• Multicast

• Calidad de Servicio (QoS)

• Protocolos especializados (Vgr. H.323)


IPv6

• Topologías dedicadas, seguras y flexibles


¿Por qué otra Internet?


La Internet de hoy en día ya no es una red académica, como en sus comienzos,
sino que se ha convertido en una red que involucra, en gran parte, intereses c
o-
merciales y particulares.

Esto la hace inapropiada para la experimentación y el
estudio de nuevas herramientas en gran escala.


Adicionalmente, los proveedores de servicios sobre Internet "sobrevenden" el a
n-
cho de banda que disponen, haciendo imposible garantizar un servicio mínim
o en
horas pico de uso de la red. Esto es crítico cuando se piensa en aplicaciones pr
o-
pias de Internet 2, que requieren calidad de servicio garantizada.


Por otro lado, los enlaces de alta velocidad son aún demasiado costosos para p
o-
der realizar su comerci
alización masiva.


Todo esto, nos lleva a la conclusión que Internet no es un medio apto para dar el
salto tecnológico que se necesita para compartir grandes volúmenes de inform
a-
ción, videos, transmisión de conferencias en tiempo real o garantizar comunic
a-
ción sincrónica permanente.


1.2. Protocolo http (protocolo de transferencia de hipertexto).


El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un
sencillo protocolo cliente
-
servidor que articula los intercambios de información e
n-
tre los clientes Web y los servidores HTTP. La especificación completa del prot
o-







14




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



colo HTTP 1/0 está recogida en el RFC 1945. Fue propuesto por Tim Berners
-
Lee,
atendiendo a las necesidades de un sistema global de distribución de información
como el World W
ide Web.


Desde el punto de vista de las comunicaciones, está soportado sobre los servicios
de conexión TCP/IP, y funciona de la misma forma que el resto de los servicios
comunes de los entornos UNIX: un proceso servidor escucha en un puerto de c
o-
municacio
nes TCP (por defecto, el 80), y espera las solicitudes de conexión de los
clientes Web.


Una vez que se establece la conexión, el protocolo TCP se encarga de mantener
la comunicación y garantizar un intercambio de datos libre de errores.


HTTP se basa en
sencillas operaciones de solicitud/respuesta. Un cliente establ
e-
ce una conexión con un servidor y envía un mensaje con los datos de la solicitud.
El servidor responde con un mensaje similar, que contiene el estado de la oper
a-
ción y su posible resultado.


Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan;
cada objeto Web (documento HTML, fichero multimedia o aplicación CGI) es c
o-
nocido por su URL.


Etapas de una transacción HTTP.


Para profundizar más en el funcionamiento de HTTP
, veremos primero un caso
particular de una transacción HTTP; en los siguientes apartados se analizarán las
diferentes partes de este proceso.


Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguie
n-
tes pasos:




Un usuario accede

a una URL, seleccionando un enlace de un documento
HTML o introduciéndola directamente en el campo Location del cliente
Web.



El cliente Web descodifica la URL, separando sus diferentes partes. Así
identifica el protocolo de acceso, la dirección DNS o IP d
el servidor, el pos
i-
ble puerto opcional (el valor por defecto es 80) y el objeto requerido del se
r-
vidor.



Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP c
o-
rrespondiente.








15




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web





Se realiza la petición. Para ello, se envía el comando necesario (
GET,
POST, HEAD,…), la dirección del objeto requerido (el contenido de la URL
que sigue a la dirección del servidor), la versión del protocolo HTTP e
m-
pleada (casi siempre HTTP/1.0) y un conjunto variable de información, que
incluye datos sobre las capacida
des del browser, datos opcionales para el
servidor,…



El servidor devuelve la respuesta al cliente. Consiste en un código de est
a-
do y el tipo de dato MIME de la información de retorno, seguido de la propia
información.



Se cierra la conexión TCP.


Este proce
so se repite en cada acceso al servidor HTTP. Por ejemplo, si se rec
o-
ge un documento HTML en cuyo interior están insertadas cuatro imágenes, el pr
o-
ceso anterior se repite cinco veces, una para el documento HTML y cuatro para
las imágenes.


Desde 1990, el p
rotocolo HTTP (Protocolo de transferencia de hipertexto) es el
protocolo más utilizado en Internet. La versión 0.9 sólo tenía la finalidad de tran
s-
ferir los datos a través de Internet (en particular páginas Web escritas en HTML).
La versión 1.0 del protoc
olo (la más utilizada) permite la transferencia de mensajes
con encabezados que describen el contenido de los mensajes mediante la codif
i-
cación MIME.


El propósito del protocolo HTTP es permitir la transferencia de archivos (principa
l-
mente, en formato HTML
). entre un navegador (el cliente) y un servidor web (d
e-
nominado, entre otros, httpd en equipos UNIX) localizado mediante una cadena de
caracteres denominada dirección URL.


Comunicación entre el navegador y el servidor


La comunicación entre el navegador
y el servidor se lleva a cabo en dos etapas:









16




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web






El navegador realiza una solicitud HTTP



El servidor procesa la solicitud y después envía una respuesta HTTP


En realidad, la comunicación se realiza en más etapas si se considera el proc
e-
samiento de la solicitud en el servidor. Dado que sólo nos ocupamos del protocolo
HTTP, no se explicará la parte del procesamiento en el servidor en esta sección
del artículo. Si este tema les interesa, puede consultar el
artículo

sobre el trat
a-
miento de C
GI.


Comandos


Comando

Descripción

GET

Solicita el recurso ubicado en la URL especificada

HEAD

Solicita el encabezado del recurso ubicado en la URL especificada

POST

Envía datos al programa ubicado en la URL especificada

PUT

Envía datos a la URL
especificada

DELETE

Borra el recurso ubicado en la URL especificada








17




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web




Encabezados


Nombre del encabezado

Descripción

Accept

Tipo de contenido aceptado por el navegador (por ejemplo,
texto/html
). Consulte
Tipos de MIME

Accept
-
Charset

Juego de caracteres que el navegador espera

Accept
-
Encoding

Codificación de datos que el navegador acepta

Accept
-
Language

Idioma que el navegador espera (de
forma predeterminada,
inglés)

Authorization

Identificación del navegador en el servidor

Content
-
Encoding

Tipo de codificación para el cuerpo de la solicitud

Content
-
Language

Tipo de idioma en el cuerpo de la solicitud

Content
-
Length

Extensión del
cuerpo de la solicitud

Content
-
Type

Tipo de contenido del cuerpo de la solicitud (por ejemplo,
te
x-
to/html
). Consulte
Tipos de MIME

Date

Fecha en que comienza la transferencia de datos

Forwarded

Utilizado por equipos intermediarios entre el navegador y el
servidor

From

Permite especificar la dirección de correo electrónico del cliente

From

Permite especificar que debe enviarse el documento si ha sido
modificado desde una fecha en parti
cular








18




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Link

Vínculo entre dos direcciones URL

Orig
-
URL

Dirección URL donde se originó la solicitud

Referer

Dirección URL desde la cual se realizó la solicitud

User
-
Agent

Cadena con información sobre el cliente, por ejemplo, el no
m-
bre y la versión del
navegador y el sistema operativo


Respuesta HTTP


Una respuesta HTTP es un conjunto de líneas que el servidor envía al navegador.
Está constituida por: Incluye:




Una línea de estado: es una línea que especifica la versión del protocolo
ut
i
lizada y el esta
do de la solicitud en proceso mediante un texto explicativo
y un código. La línea está compuesta por tres elementos que deben estar
separados por un espacio: La línea está formada por tres elementos que
deben estar separados por un espacio:

o

la versión del
protocolo utilizada

o

el código de estado

o

el significado del código



Los campos del encabezado de respuesta: es un conjunto de líneas opci
o-
nales que permiten aportar información adicional sobre la respuesta y/o el
servidor. Cada una de estas líneas está
compuesta por un nombre que cal
i-
fica el tipo de encabezado, seguido por dos puntos (:) y por el valor del e
n-
cabezado Cada una de estas líneas está formada por un nombre que de
s-
cribe el tipo de encabezado, seguido de dos puntos (:) y el valor del enc
a-
bezado
.



El cuerpo de la respuesta: contiene el documento solicitado.


Por lo tanto, una respuesta HTTP posee la siguiente sintaxis (<crlf> significa r
e-
torno de carro y avance de línea):



VERSIÓN
-
HTTP CÓDIGO EXPLICACIÓN
<crlf>

ENCABEZADO: Valor
<crlf>

. . .
ENCABEZADO: Valor
<crlf>

Línea en blanco <crlf>








19




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



CUERPO DE LA RESPUESTA

A continuación se encuentra un ejemplo de una respuesta HTTP:

HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft
-
IIS/2.0 Content
-
Type : text/HTML Content
-
Length : 12
45 Last
-
Modified :
Fri, 14 Jan 2000 08:25:13 GMT



Encabezados de respuesta


Nombre del encabezado

Descripción

Content
-
Encoding

Tipo de codificación para el cuerpo de la respuesta

Content
-
Language

Tipo de idioma en el cuerpo de la respuesta

Content
-
Length

Extensión del cuerpo de la respuesta

Content
-
Type

Tipo de contenido del cuerpo de la respuesta (por ejemplo,
texto/html
). Consulte
Tipos de MIME

Date

Fecha en que comienza
la transferencia de datos

Expires

Fecha límite de uso de los datos

Forwarded

Utilizado por equipos intermediarios entre el navegador y el
servidor

Location

Redireccionamiento a una nueva dirección URL asociada con
el documento

Server

Características d
el servidor que envió la respuesta








20




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Los códigos de respuesta

Son los códigos que se ven cuando el navegador no puede mostrar la página sol
i-
citada. El código de respuesta está formado por tres dígitos: el primero indica el
estado y los dos siguientes explican la naturaleza exacta del error.


Código

Mensaje

Descripción

10x

Mensaje de i
n-
formación

Estos códigos no se utilizan en la versión 1.0

del protocolo

20x

Éxito

Estos códigos indican la correcta ejecución de la transacción

200

OK

La solicitud se llevó a cabo de manera correcta

201

CREATED

Sigue a un comando
POST

e indica el éxito, la parte restante del
cuerpo indica la dirección
URL

donde se ubicará el documento
creado recientemente.

202

ACCEPTED

La solicitud ha sido aceptada, pero el procedimiento

que sigue
no se ha llevado a cabo

203

PARTIAL INFO
R-
MATION

Cuando se recibe este código en respuesta a un comando de
GET

indica que la respuesta no está completa.

204

NO RESPONSE

El servid
or ha recibido la solicitud, pero no hay información de
respuesta

205

RESET CONTENT

El servidor le indica al navegador que borre el contenido en los
campos de un formulario

206

PARTIAL CO
N-
TENT

Es una respuesta a una solicitud que consiste en el encabezado
range
. El servidor debe indicar el encabezado
content
-
Range

30x

Redirección

Estos códigos indican que el recurso ya no se encuentra en la
ubicación especificada








21




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



301

MOVED

Los datos solicitado
s han sido transferidos a una nueva dire
c-
ción

302

FOUND

Los datos solicitados se encuentran en una nueva dirección URL,
pero, no obstante, pueden haber sido trasladados

303

METHOD

Significa que el cliente debe intentarlo con una nueva dirección;
es preferible que intente con otro método en vez de
GET

304

NOT MODIFIED

Si el cliente llevó a cabo un comando
GET

condicional (con la
solicitud relativa a si el documento ha sido modificado desde la
última vez) y el documento no ha sido modificado, este código
se envía como respuesta.

40x

Error debido al
cliente

Estos códigos indican que la solicitud es incorrecta

400

BAD REQUEST

La sintaxis de la solicitud se encuentra formulada de manera
errónea o es imposible de responder

401

UNAUTHORIZED

Los parámetros del mensaje aportan las especificaciones de
formularios de autorización que se admiten. El cliente debe
reformular la solicitud con los datos de autorización correctos

402

PAYMENT REQU
I-
RED

El cliente debe reformular la solicitud con los datos de pago
correctos

403

FORBIDDEN

El acceso al recurso si
mplemente se deniega

404

NOT FOUND

Un clásico. El servidor no halló nada en la dirección especificada.
Se ha abandonado sin dejar una dirección para redireccionar... :)

50x

Error debido al
servidor

Estos códigos indican que existe un error interno en el
servidor

500

INTERNAL ERROR

El servidor encontró una condición inesperada que le impide
seguir con la solicitud (una de esas cosas que les suceden a los







22




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



servidores...)

501

NOT IMPLEME
N-
TED

El servidor no admite el servicio solicitado (no puede saberlo
to
do...)

502

BAD GATEWAY

El servidor que actúa como una puerta de enlace o proxy ha
recibido una respuesta no válida del servidor al que intenta
acceder

503

SERVICE UNAVA
I-
LABLE

El servidor no puede responder en ese momento debido a que
se encuentra con
gestionado (todas las líneas de comunicación
se encuentran congestionadas, inténtelo de nuevo más adela
n-
te)

504

GATEWAY T
I-
MEOUT

La respuesta del servidor ha llevado demasiado tiempo en rel
a-
ción al tiempo de espera que la puerta de enlace podía admitir
(excedió el tiempo asignado...)



1.2.1

Arquitectura del WWW.


L
a world wide web es la telaraña mundial, es un servicio de internet
más

utilizado
funciona de la siguiente manera: el

computadora cliente utiliza un browser o pr
o-
grama navegador para interactuar con el servidor de
páginas

web


El Web mundial del Internet (WWW) proporciona un modelo lógico muy flexible y
de gran alcance. Todo el uso presenta el contenido a un cliente en u
n grupo de
formatos de datos normales que son hojeados por el conocimiento de

las aplic
a-
ciones del lado
del usuario conocido

como buscadores de la Web. Típicamente, un
cliente envía los pedidos de uno o más objetos de datos nombrados (o el conten
i-
do) a un
servidor de origen. El servidor de origen responde con los datos solicit
a-
dos expresados en uno de los formatos normales conocidos por el cliente (eje
m-
plo: HTML).


Los estándares de WWW incluyen todos los mecanismos necesarios para con
s-
truir un ambiente de
uso general:









23




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web





Modelo de nombramiento estándar
-

Todos los recursos en el WWW se
nombran con un Recurso Uniforme de Internet
-
estándar (URL).



Formatos de contenido estándar
-

Todos los buscadores de la web apoyan
un grupo de formatos de contenido estándar.
Éstos incluyen el lenguaje del
margen de beneficio del Hypertext Markup Languaje (HTML), el lenguaje
escrito en la lengua Java Script?, y una gran cantidad de otros formatos.



Protocolos estándares
-

los protocolos estándares de la conexión de redes
permite

a cualquier buscador se comunique con cualquier servidor de or
i-
gen. El protocolo más comúnmente usado en el WWW es el Hypertext
Transport Protocol (HTTP).


Esta infraestructura permite que los usuarios alcancen fácilmente una gran cant
i-
dad de aplicacione
s tripartitas y servicios de contenido. También permite que los
desarrolladores de aplicaciones creen fácilmente usos y los servicios de contenido
para una comunidad grande de clientes.


1.2.2 URL’s.


Un localizador uniforme de recursos, más comúnmente de
nominado URL (sigla en
inglés de uniform resource locator), es una secuencia de caracteres, de acuerdo a
un formato modélico y estándar, que se usa para nombrar recursos en Internet
para su localización o identificación, como por ejemplo documentos textual
es,
imágenes, videos, presentaciones digitales, etc.


Los localizadores uniformes de recursos fueron una innovación fundamental en la
historia de la Internet. Fueron usadas por primera vez por Tim Berners
-
Lee en
1991, para permitir a los autores de documen
tos establecer hiperenlaces en la
World Wide Web. Desde 1994, en los estándares de la Internet, el concepto de
URL ha sido incorporado dentro del más general de URI (uniform resource ident
i-
fier, en español identificador uniforme de recurso), pero el términ
o URL aún se
utiliza ampliamente.


Aunque nunca fueron mencionadas como tal en ningún estándar, mucha gente
cree que las iniciales URL significan universal resource locator (localizador unive
r-
sal de recursos). Esta interpretación puede ser debida al hecho
de que, aunque la
U en URL siempre ha significado "uniforme", la U de URI significó en un principio
"universal", antes de la publicación del RFC 2396.


El URL es la cadena de caracteres con la cual se asigna una dirección única a
cada uno de los recursos d
e información disponibles en la Internet. Existe un URL







24




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



único para cada página de cada uno de los documentos de la World Wide Web,
para todos los elementos de Gopher y todos los grupos de debate USENET, y así
sucesivamente.


El URL de un recurso de informa
ción es su dirección en Internet, la cual permite
que el navegador la encuentre y la muestre de forma adecuada. Por ello el URL
combina el nombre del ordenador que proporciona la información, el directorio
donde se encuentra, el nombre del archivo, y el pr
otocolo a usar para recuperar
los datos.


Esquema URL


Un URL se clasifica por su esquema, que generalmente indica el protocolo de red
que se usa para recuperar, a través de la red, la información del recurso identific
a-
do. Un URL comienza con el nombre de
su esquema, seguida por dos puntos, s
e-
guido por una parte específica del esquema'.


Algunos ejemplos de esquemas URL:



* http
-

recursos HTTP


* https
-

HTTP sobre SSL


* ftp
-

File Transfer Protocol


* mailto

-

direcciones de correo electrónico


* ldap
-

búsquedas LDAP Lightweight Directory Access Protocol


* file
-

recursos

disponibles en el sistema local, o en una red local


* news
-

grupos de noticias Usenet (newsgroup)


* gopher

-

el protocolo Gopher (ya en desuso)


* telnet
-

el protocolo telnet


* data
-

el esquema para insertar pequeños trozos de contenido en los doc
u-
mentos Data: URL


Algunos de los esquemas URL, como los populares "mailto", "http", "ftp", y "file",
junt
o a los de sintaxis general URL, se detallaron por primera vez en 1994, en el
Request for Comments RFC 1630, sustituido un año después por los más espec
í-
ficos RFC 1738 y RFC 1808.


Algunos de los esquemas definidos en el primer RFC aún son válidos, mientra
s
que otros son debatidos o han sido refinados por estándares posteriores. Mientras
tanto, la definición de la sintaxis general de los URL se ha escindido en dos líneas
separadas de especificación de URI: RFC 2396 (1998) y RFC 2732 (1999), ambos







25




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



ya obsolet
os pero todavía ampliamente referidos en las definiciones de esquemas
URL.


1.2.3 Métodos http.


Estos
Métodos

HTTP son como tipos de solicitudes que hacen en el
comunicación

del
protocolo

HTTP, estas peticiones son acciones a realizar, cada
petición

tien
e

ya definido su
acción

a hacer.
Como

sabemos la
comunicación

del HTTP se da en

Request/Response se
podría

decir que en estos dos pasos, estos pasos son el de

petición

y respuesta en la
comunicación
.


Métodos



[
-
] GET "Devuelve el recurso identificado en
la URL pedida."
Sería

una
petición

de lectura hacia un recurso del host definido.


Apolo:/# nc
-
vv 127.0.0.1 80

localhost [127.0.0.1] 80 (www) open


GET /


<html><body><h1>It works!</h1>

<p>This is the default web page for this server.</p>

<p>The web
server software is running but no content has been
added, yet.</p>

</body></html>

sent 6, rcvd 177


Hacemos una
petición

GET al localhost, entonces como
definimos

en el path / se
re direccionará

al index.html que en este caso
sería

el
índex

que trae por de
fecto
Apache2,

HEAD "Funciona como el GET, pero sin que el servidor devuelva el cuerpo del

mensaje. Es decir, sólo se devuelve la información de cabecera."
Aquí

en esta

parte ya es mas a nivel de cliente(navegador no como netcat aunque
también

se

utilizar) entonces este
método

lo que hace es mostrar o
prácticamente

aplicar un

filtro y que solo muestre la
información

de los Headers no del cuerpo del recurso

como tal
.


Apolo:/# nc
-
vv 127.0.0.1 80

localhost [127.0.0.1] 80 (www) open








26




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



HEAD / HTTP/1.1



Host:127.0.0.1

HTTP/1.1 200 OK

Date: Fri, 28 May 2010 07:19:28 GMT

Server: Apache/2.2.15 (Debian)


Last
-
Modified: Wed, 26 May 2010 06:02:11 GMT

ETag: "4400ff
-
b1
-
4877903c6dec0"

Accept
-
Ranges: bytes

Content
-
Length: 177

Vary: Accept
-
Encoding

Content
-
Type:
text/html

X
-
Pad: avoid browser bug


POST "Indica al servidor que se prepare para recibir información del cliente

s
uele
usarse para enviar información desde formularios." este tipo de
método

lo que h
a-
ce es hacer remitir
información

del cliente al servidor, aparte de hacer

trabajar esta
función

en formularios
también

se
podría

adecuar a un
log
i
n

o a otra

información

a
enviar al servidor, bueno esta
información

cuando llega al servidor

termina

ha
cie
n-
do muchas veces valor de variables
para procesar
información
.


PUT "Envía el recurso identificado en la URL desde el cliente hacia el

servidor."Este
método

sirve para crear o registrar cierta
información

que
envié

al servidor.


PUT /index.html HTTP/1.1

Host:127.0.0.1

Content
-
Lengt:19

<h1>
Progresive</h1>


OPTIONS este
método

permite ver que
métodos

están

habilitados y
cuáles

no.


Apolo:/# nc
-
vv 127.0.0.1 80

localhost [127.0.0.1] 80 (www) open

OPTIONS / HTTP/1.1

Host:127.0.0.1

HTTP/1.1 200 OK

Date: Fri, 28 May 2010 07:18:04 GMT








27




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Server:
Apache/2.2.15 (Debian)

Allow: GET,HEAD,POST,OPTIONS

Vary: Accept
-
Encoding

Content
-
Length: 0


Content
-
Type: text/html


TRACE "Inicia un ciclo de mensajes de petición. Se usa para depuración

y

permite al cliente ver lo que el servidor recibe en el otro lado."


Apolo:/# nc
-
vv 127.0.0.1 80

localhost [127.0.0.1] 80 (www) open

TRACE /busqueda_resultado.php HTTP/1.1

Host:127.0.0.1

XSS:<script>alert('UxMal Was Here')</script>


HTTP/1.1 200 OK

Date:
Fri, 28 May 2010 07:37:22 GMT

Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8e
-
fips
-
rhel5 mod_auth_pas

sthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

Transfer
-
Encoding: chunked

Content
-
Type: message/http


7c

TRACE /busqueda_resultado.php HTT
P/1.1

Host:www.desarrollocristiano.com

XSS:<script>alert('UxMal Was Here')</script>


DELETE "Solicita al servidor que borre el recurso identificado con el URL."
,
este
método

como el mismo nombre lo dice hace la ejecuci
ó
n de borrar un recurso

en
el host.


DELETE /borrar.htm HTTP/1.1

Host:127.0.0.1


CONNECT "Este método se reserva para uso con proxys. Permitirá que un proxy
pueda dinámicamente convertirse en un túnel. Por ejemplo para comunicaciones
con SSL."









28




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



CONNECT 192.168.1.1 HTTP/1.1


Host:victic.com

GET / HTTP/1.0


Persistencia en http

Cookies.


Las conexiones persistentes del HTTP, también llamadas HTTP guardar
-
vivo, o
reutilización de la conexión del HTTP, son la idea de usar la misma conexión del
TCP para enviar y para recibir múltiplo Peticiones
del HTTP/responses, en comp
a-
ración con abrir una nueva conexión para cada solo par de la petición/de la re
s-
puesta.


Ventajas




menos CPU y uso de la memoria (porque pocas conexiones están abiertas
simultáneamente)



permite Can#ería del HTTP de peticiones y d
e respuestas



reducido congestión de red (menos Conexiones del TCP)



reducido estado latente en las peticiones subsecuentes (no apretón de m
a-
nos)



los errores se pueden divulgar sin la pena de cerrar la conexión del TCP


Según RFC 2616 (página 47), un cliente

single
-
user no debe mantener más de 2
conexiones con ningún servidor o poder. A poder debe utilizar hasta las conexi
o-
nes 2*N a otro servidor o poder, donde está el número N de usuarios simultáne
a-
mente activos. Estas pautas se piensan para mejorar tiempos
de reacción del
HTTP y para evitar la congestión.


Persistencia.


Uno de los problemas clásicos en el desarrollo de web sites y aplicaciones web es
la perdida de persistencia cuando el usuario pasa de una página a otra. Debido a
las características de diseño del protocolo HTTP que fuerza una nueva conexión y
desconexión
por cada request no es posible saber quien está accediendo a que
página o en
qué

lugar esta cada usuario del site. Mantener persistencia a lo largo
de la navegación del sitio ha sido uno de los temas más complejos e importantes
en el desarrollo de aplicaci
ones web, en este capítulo ilustraremos distintos mét
o-
dos que pueden usarse en PHP para mantener persistencia.









29




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Sesiones:


Se suele definir como una sesión al tiempo en el que un usuario determinado se
encuentra navegando en el site, dependiendo de la defi
nición podemos decir que
si el usuario no navega por el site durante una cierta cantidad de minutos ha te
r-
minado su sesión en el sitio y a partir de allí cuando vuelve a ingresar lo hace en
una nueva sesión. El concepto de sesión es útil porque es posible
asociar a cada
sesión un identificador único de forma tal de registrar la actividad del usuario en el
site y mantener persistencia utilizando únicamente este identificador, el problema
pasa a ser como mantener la persistencia del identificador de sesión (S
ID) de ah
o-
ra en adelante, y las posibilidades son las que detallamos a continuación:


1. 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
browse
rs, 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 c
o-
okies 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. Cua
n-
do 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 en
vió la cookie re
-
envía

la c
o-
okie al site, de esta forma es posible mantener persistencia. La información que
puede guardarse en una cookie
está

limitada por lo que habitualmente se utiliza la
misma para mantener el identificador de sesión del usuario almac
enándose el re
s-
to de los datos necesarios en el servidor usando el session
-
id de la cookie como
clave.


1.3

Introducción al HTML.


HTML (HyperText Mark
-
Up Language) es lo que se conoce como "lenguaje de
marcado", cuya función es preparar documentos escrito
s aplicando etiquetas de
formato. Las etiquetas indican cómo se presenta el documento y cómo se vincula
a otros documentos.









30




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



HTML se usa también para la lectura de documentos en Internet desde diferentes
equipos gracias al protocolo HTTP, que permite a los

usuarios acceder, de forma
remota, a documentos almacenados en una dirección específica de la red, den
o-
minada dirección URL.


La World Wide Web (WWW), o simplemente la Web, es la red mundial formada
por todos los documentos (llamados "páginas Web") conect
ados entre sí por h
i-
pervínculos.


A menudo, las páginas web se organizan alrededor de una página principal que
actúa como eje central para buscar otras páginas con hipervínculos. Este grupo de
páginas Web unidas por hipervínculos y centradas alrededor de u
na página princ
i-
pal se llama sitio Web.


La Web es un amplio archivo dinámico compuesto de una gran variedad de sitios
Web y que permite el acceso a páginas Web que contienen texto formateado,
imágenes, sonidos, videos, etc.

El concepto de la Web


La Web e
stá compuesta por páginas Web almacenadas en servidores Web, equ
i-
pos que están constantemente conectados a Internet y que proveen las páginas
que los usuarios solicitan. Cada página Web y, en general, cualquier fuente en
línea (como imágenes, videos, músic
a y animaciones) se asocia con una dirección
única llamada URL.


El elemento clave para navegar a través de páginas Web es el navegador, un pr
o-
grama que envía solicitudes a los servidores Web, procesa los datos resultantes y
muestra la información como se
requiere, en base a las instrucciones de la página
HTML.


Los navegadores más usados en Internet son:



* Mozilla Firefox,


* Microsoft Internet Explorer,


* Netscape Navigator,


* Safari.


HTML es un estándar









31




Unidad:

Instituto
Tecnológico superior de
Coatzacoalcos.

Edición
No
. 1

Fecha de Edición: 2010



Departamento:

Ingeniería Sistemas Computacionales.

Materia:


Programación Web



Es importante comprender que el
lenguaje HTML es un estándar, compuesto por
recomendaciones publicadas por un consorcio internacional: el World Wide Web
Consortium (W3C).


Las especificaciones oficiales de HTML describen las "instrucciones" del lenguaje,
pero no cómo seguirlas, es decir,

cómo las interpretan los programas informáticos.
Esto permite visualizar páginas Web independientemente del sistema operativo o
la arquitectura del equipo del usuario.


Sin embargo, aunque las especificaciones son muy detalladas, hay cierto margen
para la

interpretación por parte del navegador y esta es la razón por la cual la
misma página puede aparecer de modo diferente en un navegador u otro.


Es más, algunos editores de software agregan instrucciones HTML exclusivas que