[Link]
com
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
URL del artculo: [Link]
Leer completo: 10 Ejemplos de URL
[Link]
Ftpl
TRANSACIONES HTTP . URL Y FTP
Transacciones HTTP
Una transaccin HTTP est formada por un encabezado seguido, opcionalmente, por una lnea en
blanco y algn dato. El encabezado especificar cosas como la accin requerida del servidor, o el
tipo de dato retornado, o el cdigo de estado.
El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al
protocolo. Estos campos permiten que se enve informacin descriptiva en la transaccin,
permitiendo as la autenticacin, cifrado e identificacin de usuario.
Un encabezado es un bloque de datos que precede a la informacin propiamente dicha, por lo
que muchas veces se hace referencia a l como metadato porque tiene datos sobre los datos.
Si se reciben lneas de encabezado del cliente, el servidor las coloca en las variables de ambiente
de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier carcter guin ( - )
del nombre del encabezado se convierte a caracteres "_".
El servidor puede excluir cualquier encabezado que ya est procesado, como Authorization,
Content-type y Content-length. El servidor puede elegir excluir alguno o todos los encabezados si
incluirlos excede algn lmite del ambiente de sistema. Ejemplos de esto son las variables
HTTP_ACCEPT y HTTP_USER_AGENT.
HTTP_ACCEPT. Los tipos MIME que el cliente aceptar, dado los encabezados HTTP. Otros
protocolos quizs necesiten obtener esta informacin de otro lugar. Los elementos de esta lista
deben estar separados por una coma, como lo dice la especificacin HTTP: tipo, tipo.
HTTP_USER_AGENT. El navegador que utiliza el cliente para realizar la peticin. El formato
general para esta variable es: software/versin biblioteca/versin.
El servidor enva al cliente:
Un cdigo de estado que indica si la peticin fue correcta o no. Los cdigos de error tpicos
indican que el archivo solicitado no se encontr, que la peticin no se realiz de forma correcta o
que se requiere autenticacin para acceder al archivo.
La informacin propiamente dicha. Como HTTP permite enviar documentos de todo tipo y
formato, es ideal para transmitir multimedia, como grficos, audio y video. Esta libertad es una
de las mayores ventajas de HTTP.
Informacin sobre el objeto que se retorna.
Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos
de ellos slo tienen sentido en una direccin.
URL son las siglas de Localizador de Recurso Uniforme (en ingls Uniform Resource Locator), la
direccin global de documentos y de otros recursos en la World Wide Web.
La primera parte de la direccin indica qu protocolo utilizar, la segunda parte especifica la
direccin IP o nombre de dominio donde se localiza el recurso.
Por ejemplo, las dos URLs de abajo apuntan a dos archivos diferentes en el dominio
[Link]. La primera especifica un fichero ejecutable que se debe encontrar usando el
protocolo FTP; la segunda especifica una pgina web que se debe abrir usando el protocolo
HTTP:
[Link]
[Link]
[Link]
Un hyperlink es similar a una cita en una literatura. Es una referencia a otro documento o recurso
en un documento del hypertext. Cuando est combinado con una red de datos y un protocolo
conveniente del acceso se utiliza para traer el recurso referido. Esto despus se ve, se ahorra, o
se exhibe como parte del documento que se refiere.
Los hyperlinks son parte de la fundacin del Web mundial creado por Tim Berners-Berners-Lee.
Los hyperlinks se presentan y se ajustan a formato en el nmero de maneras en un Web page. El
formato ms comn es el acoplamiento encajado que ocurre dentro de una oracin.
FTP (sigla en ingls de File Transfer Protocol - Protocolo de Transferencia de Archivos) en
informtica, es un protocolo de red para la transferencia de archivos entre sistemas conectados a
una red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor. Desde un
equipo cliente se puede conectar a un servidor para descargar archivos desde l o para enviarle
archivos, independientemente del sistema operativo utilizado en cada equipo.
El Servicio FTP es ofrecido por la capa de Aplicacin del modelo de capas de red TCP/IP al
usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema bsico de FTP es que
est pensado para ofrecer la mxima velocidad en la conexin, pero no la mxima seguridad, ya
que todo el intercambio de informacin, desde el login y password del usuario en el servidor
hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningn tipo de cifrado,
con lo que un posible atacante puede capturar este trfico, acceder al servidor, o apropiarse de
los archivos transferidos.
Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el
paquete SSH, que permiten transferir archivos pero cifrando todo el trfico.
Cmo no usar mailto
Existen dos errores comunes en el diseo web relacionados con el
esquema de URLs mailto. Adems de ser errores muy comunes, sus
consecuencias pueden ser bastante graves (incluso pueden perderse
mensajes sin que nadie se entere), por lo que es importante saber cules
son estos errores y cmo evitarlos.
Error nmero 1: Poner parmetros en los URLs mailto
Es muy normal encontrar pginas con cosas de este estilo:
<a href="[Link]
casa'&body=Telefono">Contacte con nosotros!</a>
Esto es incorrecto por el siguiente motivo:
El elemento A, segn las especificaciones de HTML, tiene un atributo
opcional HREF, cuya funcin es la siguiente:
Este atributo especifica la localizacin de un recurso de la Web,
definiendo as un vnculo entre el elemento actual (el origen del vnculo) y
el destino del vnculo definido por este atributo.
([Link]
El valor de este atributo es un URI (identificador uniforme de recursos,
ver [Link] su definicin formal), el cual
puede ser, por ejemplo, un URL tipo mailto. Naturalmente, ste debe ser
un URL vlido.
Los URLs del tipo mailto estn especificados, como el resto de URLs,
en "Uniform Resource Locators (URL)", seccin 3.5, que traduzco a
continuacin:
3.5. MAILTO
El esquema de URLs mailto se usa para designar una direccin de correo
de Internet de un individuo o servicio. Aparte de una direccin de correo
de Internet, no hay ninguna otra informacin adicional presente o
implcita.
Un URL mailto tiene la siguiente forma
[Link]
donde <rfc822-addr-spec> es (la codificacin de un) addr-spec, segn se
especifica en RFC 822 [declarada obsoleta por RFC2822]. Dentro de
un URL mailto no hay caracteres reservados.
Obsrvese que el signo de tanto por ciento ("%") se usa normalmente
dentro de direcciones RFC 822 y debe ser codificado.
A diferencia de otros muchos URLs, el esquema mailto no representa un
objeto de datos al que pueda accederse directamente; no designa un
objeto en ningn sentido. Tiene una utilizacin diferente a la del
tipo MIME message/external-body.([Link]
En el RFC2822, "Internet Message Format" se define un addr-spec del
siguiente modo (seccin 3.4.1):
3.4.1. Especificacin de addr-spec
Un addr-spec es un identificador especfico de Internet que contiene una
cadena interpretada localmente, seguida del smbolo arroba ("@",
valor ASCII 64), seguida de un dominio de Internet. [...]
addr-spec
local-part "@" domain
([Link]
Es decir, un enlace HTML cuyo atributo HREF sea un URL del
esquema mailto no puede contener ms informacin que la direccin de
correo electrnico vinculada: ni asunto, ni cuerpo, ni nada. Slo la
direccin de correo.
El hecho de que funcione en algunas o en muchas combinaciones
navegador web/cliente de correo, no quiere decir que funcione en todas,
ni que tenga que funcionar, ni que vaya a funcionar en el futuro. Su
comportamiento es esencialmente impredecible, porque es incorrecto. Lo
que s se puede esperar es que habr situaciones en las que no
funcionar.
Adems no tendra ninguna utilidad para usuarios que no utilicen un
cliente de correo (por ejemplo porque usan correo web).
Error nmero 2: Poner una accin mailto en los formularios HTML
Esto no slo est mal sino que existen tantos motivos para no hacerlo
que el propio sentido comn debera bastar para darse cuenta.
Lamentablemente el 99,9% de los tutoriales de HTML siempre usan una
accin mailto para explicar cmo funcionan los formularios.
Formularios como ste son lo ms normal del mundo:
<form action="[Link] enctype="text/plain"
method="post">
Esto est mal por dos motivos:
1. Segn la especificacin de HTML 4, los dos nicos tipos de
contenido que deben soportar los navegadores son
"application/x-www-form-urlencoded" y "multipart/form-data". El
comportamiento para otros tipos de contenido queda sin
especificar. Incluido naturalmente el tipo de contenido "text/plain"
(ver [Link]
2. El valor del atributo ACTION se refiere a un agente procesador del
formulario que reside en el servidor. Segn define la
especificacin El comportamiento del agente de usuario frente a
un valor diferente de un URI HTTP es
indefinido. (ver [Link]
De modo que para empezar es pura y llanamente HTML incorrecto. No
hay ningn motivo para que un navegador que se atenga a las
especificaciones haga con ese formulario lo que nosotros creemos que
tendra que hacer. Es un error, y por tanto sus resultados son
impredecibles. Al igual que antes, lo que s se puede predecir es que
habr situaciones en que no funcionar.
Por si eso no fuera poco, aqu hay una batera ms de buenas razones:
No es muy fiable. Puede que funcione en tu computadora, pero no
sabes si funcionar en la de tus visitantes, porque depende de su
cliente de correo y de la configuracin de su sistema. Y tu
visitante tampoco sabr si funciona hasta que no pulse el botn
de enviar, despus de rellenar todos los campos. Bastante
frustrante. O puede no suceder nada, y el visitante creera que te
ha enviado algo cuando en realidad no lo ha hecho. O puede que
la direccin est mal formada y no llegue a enviarse o rebote y
acabe donde no queremos que acabe (en el buzn de
un postmaster, por ejemplo, o perdido en el ciberespacio).
Has ledo el mensaje que da Internet Explorer?
Este formulario se est enviando por correo electrnico. El envo
de este formulario revelar su direccin de correo electrnico, y
no cifrar la informacin del formulario como medida de
privacidad.
Puede continuar o cancelar el envo.
[Aceptar] [Cancelar]
Despus de leer tal mensaje, ms de uno le dar a "cancelar", por
si las moscas.
Si el visitante usa correo web, el que se le abra un programa de
correo (suponiendo que lo tenga) probablemente no le sirva para
nada.
El visitante podra estar en un cibercaf, usando una computadora
sin programa de correo.
Como inconveniente adicional, la direccin destino est en el
cdigo HTML y es accesible por losspambots, pudiendo caer
presa de los espmers. Con un programa propio, con la direccin
en el cdigo del programa, no existe este peligro.
La solucin
La nica manera segura de generar un mensaje de correo emitido por el
visitante de una pgina web es por medio de un formulario de correo que
se ejecute en el servidor, ya sea en CGI, PHP, ASP, etc., no en el cliente.
Aunque pueda parecer complicado, en realidad es muy sencillo y basta
con ver un ejemplo para saber cmo se hace.
Existen empresas que permiten utilizar gratuitamente o a cambio de
publicidad sus servidores para la ejecucin de estos formularios, por
ejemplo:
[Link]
[Link]
Muchas compaas de alojamiento web (incluso gratuitas) ponen a
disposicin de sus usuarios formularios de correo listos para usar.
Tambin es posible que puedas alojar tus propios scripts junto con tu
pgina. Aqu tienes una lista con scripts para procesamiento de
formularios, muchos de ellos de uso libre y gratuito:
En
Perl: [Link]
m_Processing/
En
PHP: [Link]
ssing/
Ms informacin
Direcciones IP y puertos de escucha
Idiomas disponibles: en | es | fr | ja | ko | tr
Cmo configurar Apache para que escuche en direcciones IP y puertos especficos.
Introduccin
Consideraciones especiales para IPv6
Cmo funciona este mecanismo en hosts virtuales
Consulte tambin
Hosts virtuales
Asuntos relacionados con DNS
Introduccin
Mdulos Relacionados
core
mpm_common
Directivas Relacionadas
<VirtualHost>
Listen
Cuando Apache se inicia, comienza a esperar peticiones entrantes en determinados puertos y
direcciones de la mquina en la que se est ejecutando. Sin embargo, si quiere que Apache
escuche solamente en determinados puertos especficos, o solamente en determinadas
direcciones, o en una combinacin de ambos, debe especificarlo adecuadamente. Esto puede
adems combinarlo con la posibilidad de usar hosts virtuales, funcionalidad con la que un
servidor Apache puede responder a peticiones en diferentes direcciones IP, diferentes
nombres de hosts y diferentes puertos.
La directiva Listen le indica al servidor que acepte peticiones entrantes solamente en los
puertos y en las combinaciones de puertos y direcciones que se especifiquen. Si solo se
especifica un nmero de puerto en la directiva Listen el servidor escuchar en ese puerto,
en todas las interfaces de red de la mquina. Si se especifica una direccin IP y un puerto, el
servidor escuchar solamente en la interfaz de red a la que pertenezca esa direccin IP y
solamente en el puerto indicado. Se pueden usar varias directivas Listen para especificar
varias direcciones IP y puertos de escucha. El servidor responder a las peticiones de todas
las direcciones y puertos que se incluyan.
Por ejemplo, para hacer que el servidor acepte conexiones tanto en el puerto 80 como en el
puerto 8000, puede usar:
Listen 80
Listen 8000
Para hacer que el servidor acepte conexiones en dos interfaces de red y puertos especficos,
use
Listen [Link]:80
Listen [Link]:8000
Las direcciones IPv6 deben escribirse entre corchetes, como en el siguiente ejemplo:
Listen [Link]:80
Consideraciones especiales para IPv6
Cada vez ms plataformas implementan IPv6, y APR soporta IPv6 en la mayor parte de esas
plataformas, permitiendo que Apache use sockets IPv6 y pueda tratar las peticiones que se
envan con IPv6.
Un factor de complejidad para los administradores de Apache es si un socket IPv6 puede
tratar tanto conexiones IPv4 como IPv6. Para tratar conexiones IPv4 con sockets IPv6 se
utiliza un traductor de direcciones IPv4-IPv6, cuyo uso est permitido por defecto en la mayor
parte de las plataformas, pero que est desactivado por defecto en FreeBSD, NetBSD, y
OpenBSD para cumplir con la poltica system-wide en esas palaformas. Pero incluso en los
sistemas en los que no est permitido su uso por defecto, un parmetro especial
de configure puede modificar ese comportamiento.
Si quiere que Apache trate conexiones IPv4 y IPv6 con un mnimo de sockets, lo que requiere
traducir direcciones IPv4 a IPv6, especifique la opcin de configure --enable-v4mapped y use directivas Listen genricas de la siguiente forma:
Listen 80
Con --enable-v4-mapped, las directivas Listen en el fichero de configuracin por defecto
creado por Apache usarn ese formato. --enable-v4-mapped es el valor por defecto en
todas las plataformas excepto en FreeBSD, NetBSD, y OpenBSD, de modo que esa es
probablemente la manera en que su servidor Apache fue construido.
Si quiere que Apache solo procese conexiones IPv4, sin tener en cuenta cul es su plataforma
o qu soporta APR, especifique una direccin IPv4 en todas las directivas Listen, como en
estos ejemplos:
Listen [Link]:80
Listen [Link]:80
Si quiere que Apache procese conexiones IPv4 y IPv6 en sockets diferentes (es decir,
deshabilitar la conversin de direcciones IPv4 a IPv6), especifique la opcin
de configure --disable-v4-mapped y use directivas Listen especficas como en el
siguiente ejemplo:
Listen [::]:80
Listen [Link]:80
Con --disable-v4-mapped, las directivas Listen en el fichero de configuracin que Apache
crea por defecto usarn ese formato. --disable-v4-mapped se usa por defecto en
FreeBSD, NetBSD, y OpenBSD.
Cmo funciona este mecanismo en hosts virtuales
Listen no implementa hosts virtuales. Solo le dice al servidor principal en qu direcciones y
puertos tiene que escuchar. Si no se usan directivas <VirtualHost>, el servidor se
comporta de la misma manera con todas las peticiones que se acepten. Sin
embargo, <VirtualHost> puede usarse para especificar un comportamiento diferente en
una o varias direcciones y puertos. Para implementar un host virtual, hay que indicarle primero
al servidor que escuche en aquellas direcciones y puertos a usar. Entonces se debe crear un
una seccin<VirtualHost> en una direccin y puerto especficos para determinar el
comportamiento de ese host virtual. Tenga en cuenta que si se especifica en una
seccin <VirtualHost> una direccin y puerto en los que el servidor no est escuchando,
ese host virtual no podr ser accedido.
