HTTP2 nuevo protocolo de internet que acelerará la navegación

Internet irá más rápido. Y eso siempre es una buena noticia.

La red tendrá un nuevo protocolo de transferencia de hipertexto, que solemos ver como http:// al comienzo de las direcciones en internet.

Ahora será HTTP/2 y es la primera gran actualización del sistema que utiliza la red informática mundial (World Wide Web) en 15 años.

El nuevo protocolo fue aprobado el miércoles por parte del Grupo de Ingeniería de Internet (IESG), que proporciona la revisión técnica final de los estándares de internet.

Sus desarrolladores aseguran que se trata de un gran avance porque no sólo hará la red más rápida sino que mejorará los sistemas de encriptación.

«Uso más eficiente»

HTTP/2, explican los expertos del IESG, «permite un uso más eficiente de los recursos de la red y una percepción reducida de latencia mediante la introducción de compresión de campos de cabecera y al permitir múltiples intercambios simultáneos en la misma conexión».

Mark Nottingham, director del IESG, aseguró que en lugar de tratar de reinventar el protocolo, el grupo estaba tratando de hacer que el nuevo sea compatible con el anterior.

«Para que HTTP/2 tenga éxito significa que tiene que funcionar con la red existente. Así que este esfuerzo se trata de que el HTTP fluya de una mejor manera», aseguró.

El HTTP es el medio por el cual los navegadores se comunican con los servidores para cargar las páginas de internet.

«Como el HTTP es parte de los propios cimientos de la red, los cambios que vienen con el protocolo son un gran tema», señaló Ian Paul, de la revista PC World.

La nueva versión, aseguró Nottingham, hará más fácil el uso tecnologías de encriptación de la web, animando a más sitios a que lo hagan.

Pero agregó que el HTTP/2 no era un «polvo mágico» para la velocidad de la red y aclaró que los tiempos de carga de las páginas no se reducirán a la mitad.

Para Nottingham es «más preciso» ver el nuevo protocolo como una forma de «eliminar algunos obstáculos clave para el rendimiento».

«Una vez que los navegadores y servidores aprendan cómo y cuándo tomar ventaja de eso, el rendimiento comenzará a mejorar gradualmente», añadió.

Tecnología de Google

El protocolo se basa en una tecnología de Google llamada SPDY (y pronunciada en inglés speedy -rápido-), que se ha estado utilizando en los últimos años.

Aunque se espera que sea pronto, aún no está claro cuándo empezará a funcionar el nuevo protocolo.

Ahora debe pasar por el proceso de edición final antes de su publicación, cuando se convertirá en un estándar web oficial.

Google ya ha anunciado que cambiará a HTTP/2 en su navegador Chrome, y podría ocurrir a comienzos de 2016.

Se espera que el nuevo protocolo funcione en los navegadores Internet Explorer, Opera, Firefox y Amazon Silk.

En la práctica, para el usuario, no habrá cambios visibles más que la velocidad del servicio.

En la barra de direcciones se seguirá viendo http://, en el caso de las direcciones que todavía la muestran.

Es que el navegador será el que, de forma automática, hará el cambio entre HTTP1.1 y HTTP/2.

«El nuevo protocolo también acelerará la navegación móvil», explica el diario británico The Guardian.

Esa navegación se suele enlentecer, añade el periódico, por el tiempo adicional que se necesita para que una «solicitud viaje de un teléfono inteligente o una tableta hasta el servidor del sitio web a través de una conexión de banda ancha móvil».

fuente.bbcmundo

¿ Que es el Error 404 ?

HTTP Error 404 o no encontrado es un código de estado HTTP que indica que el host ha sido capaz de comunicarse con el servidor, pero no existe el fichero que ha sido pedido. Por ejemplo, si se accede a la URL http://wikipedia.org/xyzjk el servidor de Wikipedia devolverá una página de error y el código de error HTTP 404. Este error no debe ser confundido con «servidor web no encontrado» o errores similares en los que se indica que no se ha podido realizar la conexión con el servidor.

Una captura de pantalla de un error 404 en una Wikipedia.

Cuando se establece una comunicación HTTP se pide al servidor que responda a una petición, como un navegador web solicitando un documento HTML (una página web). El servidor responde con un código numérico de error HTTP y un mensaje. En el código 404, el primer «4» indica un error del cliente, como una URL mal escrita.

Junto al código de error 404, el servidor suele enviar un texto en que explica el motivo del error. La especificación HTTP sugiere la frase «Not Found» (No encontrado).1 Muchos servidores por defecto muestran una página web que incluye el código 404 y la frase «Not Found». Los servidores pueden ser configurados para mostrar cualquier página en caso de que la pedida no exista.

Sin embargo, Internet Explorer y Chrome, por defecto no muestran estas páginas de error a no ser que ocupen más de 512 bytes, mostrando una página de error «amigable».

A menudo los servidores devuelven un error 404 cuando las páginas se mueven o se borran. En el primer caso, una respuesta más correcta sería devolver un código de error 301 (Movido permanentemente). En el segundo caso se debería devolver un error 410 (Borrado). Como las dos opciones requieren configurar el servidor específicamente, la mayoría de los sitios no hacen uso de estos códigos.

Los errores 404 no deben ser confundidos con errores de DNS, los cuales aparecen cuando parece que la URL apunta a un servidor web que no existe. Estos no son errores 404, que siempre son devueltos por un servidor.

fuente.wikipedia

Listado de Códigos de estado HTTP

La siguiente es una lista de códigos de respuesta del HTTP y frases estándar asociadas, destinadas a dar una descripción corta del estatus. Estos códigos de estatus están especificados por el RFC 2616, y algunos fragmentos en los estándares RFC 2518, RFC 2817, RFC 2295, RFC 2774 y RFC 4918; otros no están estandarizados, pero son comúnmente utilizados.

El primer dígito del código de respuesta específica una de las cinco clases de respuesta.

1xx: Respuestas informativas

Petición recibida, continuando proceso. Esta respuesta significa que el servidor ha recibido los encabezados de la petición, y que el cliente debería proceder a enviar el cuerpo de la misma (en el caso de peticiones para las cuales el cuerpo necesita ser enviado; por ejemplo, una petición Hypertext Transfer Protocol). Si el cuerpo de la petición es largo, es ineficiente enviarlo a un servidor, cuando la petición ha sido ya rechazada, debido a encabezados inapropiados. Para hacer que un servidor cheque si la petición podría ser aceptada basada únicamente en los encabezados de la petición, el cliente debe enviar Expect: 100-continue como un encabezado en su petición inicial (vea Plantilla:Web-RFC: Expect header) y verificar si un código de estado 100 Continue es recibido en respuesta, antes de continuar (o recibir 417 Expectation Failed y no continuar).

101 Conmutando protocolos
102 Procesando (WebDAV – RFC 2518)

2xx: Peticiones correctas

Esta clase de código de estado indica que la petición fue recibida correctamente, entendida y aceptada.

200 OK
Respuesta estándar para peticiones correctas.
201 Creado
La petición ha sido completada y ha resultado en la creación de un nuevo recurso.
202 Aceptada
La petición ha sido aceptada para procesamiento, pero este no ha sido completado. La petición eventualmente pudiere no ser satisfecha, ya que podría ser no permitida o prohibida cuando el procesamiento tenga lugar.
203 Información no autoritativa (desde HTTP/1.1)
204 Sin contenido
205 Recargar contenido
206 Contenido parcial
La petición servirá parcialmente el contenido solicitado. Esta característica es utilizada por herramientas de descarga como wget para continuar la transferencia de descargas anteriormente interrumpidas, o para dividir una descarga y procesar las partes simultáneamente.
207 Estado múltiple (Multi-Status, WebDAV)
El cuerpo del mensaje que sigue es un mensaje XML y puede contener algún número de códigos de respuesta separados, dependiendo de cuántas sub-peticiones sean hechas.

3xx: Redirecciones

El cliente tiene que tomar una acción adicional para completar la petición.

Esta clase de código de estado indica que una acción subsecuente necesita efectuarse por el agente de usuario para completar la petición. La acción requerida puede ser llevada a cabo por el agente de usuario sin interacción con el usuario si y sólo si el método utilizado en la segunda petición es GET o HEAD. El agente de usuario no debe redirigir automáticamente una petición más de 5 veces, dado que tal funcionamiento indica usualmente un Bucle infinito.

300 Múltiples opciones
Indica opciones múltiples para el URI que el cliente podría seguir. Esto podría ser utilizado, por ejemplo, para presentar distintas opciones de formato para video, listar archivos con distintas extensiones o word sense disambiguation.

301 Movido permanentemente
Esta y todas las peticiones futuras deberían ser dirigidas a la URI dada.
302 Movido temporalmente
Este es el código de redirección más popular, pero también un ejemplo de las prácticas de la industria contradiciendo el estándar. La especificación HTTP/1.0 (RFC 1945) requería que el cliente realizara una redirección temporal (la frase descriptiva original fue «Moved Temporarily»), pero los navegadores populares lo implementaron como 303 See Other. Por tanto, HTTP/1.1 añadió códigos de estado 303 y 307 para eliminar la ambigüedad entre ambos comportamientos. Sin embargo, la mayoría de aplicaciones web y bibliotecas de desarrollo aún utilizan el código de respuesta 302 como si fuera el 303.

303 Vea otra (desde HTTP/1.1)
La respuesta a la petición puede ser encontrada bajo otra URI utilizando el método GET.

304 No modificado
Indica que la petición a la URL no ha sido modificada desde que fue requerida por última vez. Típicamente, el cliente HTTP provee un encabezado como If-Modified-Since para indicar una fecha y hora contra la cual el servidor pueda comparar. El uso de este encabezado ahorra ancho de banda y reprocesamiento tanto del servidor como del cliente.

305 Utilice un proxy (desde HTTP/1.1)
Muchos clientes HTTP (como Mozilla2 e Internet Explorer) no se apegan al estándar al procesar respuestas con este código, principalmente por motivos de seguridad.

306 Cambie de proxy
Esta respuesta está descontinuada.

307 Redirección temporal (desde HTTP/1.1)
Se trata de una redirección que debería haber sido hecha con otra URI, sin embargo aún puede ser procesada con la URI proporcionada. En contraste con el código 303, el método de la petición no debería ser cambiado cuando el cliente repita la solicitud. Por ejemplo, una solicitud POST tiene que ser repetida utilizando otra petición POST.

4xx Errores del cliente

La solicitud contiene sintaxis incorrecta o no puede procesarse.

La intención de la clase de códigos de respuesta 4xx es para casos en los cuales el cliente parece haber errado la petición. Excepto cuando se responde a una petición HEAD, el servidor debe incluir una entidad que contenga una explicación a la situación de error, y si es una condición temporal o permanente. Estos códigos de estado son aplicables a cualquier método de solicitud (como GET o POST). Los agentes de usuario deben desplegar cualquier entidad al usuario. Estos son típicamente los códigos de respuesta de error más comúnmente encontrados.

400 Solicitud incorrecta
La solicitud contiene sintaxis errónea y no debería repetirse.
401 No autorizado
Similar al 403 Forbidden, pero específicamente para su uso cuando la autentificación es posible pero ha fallado o aún no ha sido provista. Vea autentificación HTTP básica y Digest access authentication.
402 Pago requerido
La intención original era que este código pudiese ser usado como parte de alguna forma o esquema de Dinero electrónico o micropagos, pero eso no sucedió, y este código nunca se utilizó.
403 Prohibido
La solicitud fue legal, pero el servidor se rehúsa a responderla. En contraste a una respuesta 401 No autorizado, la autentificación no haría la diferencia.
404 No encontrado
Recurso no encontrado. Se utiliza cuando el servidor web no encuentra la página o recurso solicitado.
405 Método no permitido
Una petición fue hecha a una URI utilizando un método de solicitud no soportado por dicha URI; por ejemplo, cuando se utiliza GET en una forma que requiere que los datos sean presentados vía POST, o utilizando PUT en un recurso de sólo lectura.
406 No aceptable
El servidor no es capaz de devolver los datos en ninguno de los formatos aceptados por el cliente, indicados por éste en la cabecera «Accept» de la petición.
407 Autenticación Proxy requerida
408 Tiempo de espera agotado
El cliente falló al continuar la petición – excepto durante la ejecución de videos Adobe Flash cuando solo significa que el usuario cerró la ventana de video o se movió a otro. ref
409 Conflicto
Indica que la solicitud no pudo ser procesada debido a un conflicto con el estado actual del recurso que esta identifica.
410 Ya no disponible
Indica que el recurso solicitado ya no está disponible y no lo estará de nuevo. Debería ser utilizado cuando un recurso ha sido quitado de forma permanente.
Si un cliente recibe este código no debería volver a solicitar el recurso en el futuro. Por ejemplo un buscador lo eliminará de sus índices y lo hará más rápidamente que utilizando un código 404.
411 Requiere longitud
412 Falló precondición
413 Solicitud demasiado larga
414 URI demasiado larga
415 Tipo de medio no soportado
416 Rango solicitado no disponible
El cliente ha preguntado por una parte de un archivo, pero el servidor no puede proporcionar esa parte, por ejemplo, si el cliente preguntó por una parte de un archivo que está más allá de los límites del fin del archivo.
417 Falló expectativa
421 Hay muchas conexiones desde esta dirección de internet
422 Entidad no procesable (WebDAV – RFC 4918)
La solicitud está bien formada pero fue imposible seguirla debido a errores semánticos.
423 Bloqueado (WebDAV – RFC 4918)
El recurso al que se está teniendo acceso está bloqueado.
424 Falló dependencia (WebDAV) (RFC 4918)
La solicitud falló debido a una falla en la solicitud previa.
425 Colección sin ordenar
Definido en los drafts de WebDav Advanced Collections, pero no está presente en «Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol» (RFC 3648).
426 Actualización requerida (RFC 2817)
El cliente debería cambiarse a TLS/1.0.
449 Reintente con
Una extensión de Microsoft: La petición debería ser reintentada después de hacer la acción apropiada.

5xx Errores de servidor

El servidor falló al completar una solicitud aparentemente válida.

Los códigos de respuesta que comienzan con el dígito «5» indican casos en los cuales el servidor tiene registrado aún antes de servir la solicitud, que está errado o es incapaz de ejecutar la petición. Excepto cuando está respondiendo a un método HEAD, el servidor debe incluir una entidad que contenga una explicación de la situación de error, y si es una condición temporal o permanente. Los agentes de usuario deben desplegar cualquier entidad incluida al usuario. Estos códigos de repuesta son aplicables a cualquier método de petición.

500 Error interno
Es un código comúnmente emitido por aplicaciones empotradas en servidores web, mismas que generan contenido dinámicamente, por ejemplo aplicaciones montadas en IIS o Tomcat, cuando se encuentran con situaciones de error ajenas a la naturaleza del servidor web.
501 No implementado
502 Pasarela incorrecta
503 Servicio no disponible
504 Tiempo de espera de la pasarela agotado
505 Versión de HTTP no soportada
506 Variante también negocia (RFC 2295)
507 Almacenamiento insuficiente (WebDAV – RFC 4918)
509 Límite de ancho de banda excedido
Este código de estatus, a pesar de ser utilizado por muchos servidores, no es oficial.
510 No extendido (RFC 2774)

fuente.wikipedia

Que son las Cabeceras HTTP y como interpretarlas

Las Cabeceras HTTP o Metatags, son los parámetros que se envían en una petición o respuesta HTTP al cliente o al servidor para proporcionar información esencial sobre la transacción en curso. Estas cabeceras proporcionan información mediante la sintaxis ‘Cabecera: Valor’ y son enviadas automáticamente por el navegador o el servidor Web.
Cabeceras estandarizadas en petición

Accept: Determina el tipo de contenido o MIME que se espera de la respuesta. Su valor debe ser una cadena MIME.

Accept: image/jpg -> Se espera una imagen JPG

Accept: text/plain-> Se espera texto plano

Accept-Charset: Determina el set de caracteres aceptable en la respuesta. Su valor debe ser un código de caracteres IANA.

Accept-Charset: utf-8 -> Se espera una codificación de caracteres UTF-8

Accept-Charset: ISO 8859-1 -> Se espera una codificación de caracteres ISO 8859-1 (Oeste de Europa)

Accept-Encoding: Determina la codificación (compresión) que se espera de la respuesta. Valores comunes suelen ser gzip, deflate o sdch.

Accept-Encoding: gzip, delate, sdch -> Se espera cualquiera de las 3 codificaciones de datos especificadas.

Accept-Language: Determina el idioma aceptado para la respuesta. Su valor debe ser cualquier código de lenguaje estandarizado1

Accept-Language: es-es -> Determina el idioma aceptado para la respuesta como español de España

Accept-Language: en-us -> Determina el idioma aceptado para la respuesta como inglés de Estados Unidos

Authorization: Determina la autenticación HTTP para la petición en curso.
fuente.wikipedia

Apache HTTP Server 2.4.2, nuevo y mejorado

El equipo de trabajo de la Fundación Apache ha liberado una nueva versión estable del servidor web más importante que existe en la actualidad

Apache HTTP Server 2.4.2 trae numerosos bugs corregidos algunos de los cuales esta relacionado con cuestiones de seguridad además de incorporar nuevas funcionalidades, tanto en el núcleo de la aplicación como en muchos de los módulos que se incluyen por defecto.

Este lanzamiento supone la llegada de la mejor versión disponible hasta el momento del servidor Apache y coincide con el 17 aniversario de su lanzamiento original (febrero 1995).

Esta segunda actualización llega apenas dos meses después del lanzamiento de Apache HTTP Server 2.4 que con cerca de 400 millones de websites en todo el mundo y el 65% del mercado de servidores, es el líder absoluto del mercado a mucha distancia de otras alternativas como nginx o IIS (Internet Information Services) de Microsoft.

Interesados pueden acceder a la descarga del nuevo Apache HTTP Server 2.4.2 desde httpd.apache.org.

fuente.desarrolloweb

Apache HTTP Server 2.4

Disponible una nueva versión final del popular servidor web open source.

Coincidiendo con el 17 aniversario de su lanzamiento original ha sido presentado el nuevo Apache HTTP Server 2.4 en lo que ya es la mejor versión presentada hasta la fecha.

Con cerca de 400 millones de websites en todo el mundo y el 65% del mercado de servidores, La Fundación Apache acaba de liberar una versión que incluye algunas mejoras interesantes y demandadas desde hace tiempo entre sus usuarios.

Entre los cambios y características que más destacan de este lanzamiento, encontramos un menor consumo de recursos, reducción de la memoria usada, soporte I/O (Entrada/Salida) asíncrona, configuración de proxy dinámico inverso y soporte de ajuste detallado del caché para servidores.

Interesados pueden acceder a un completo listado con las características de la nueva versión Apache HTTP Server 2.4 desde httpd.apache.org.

El servidor Apache que comenzó su camino como un fork de NCSA httpd Web server apenas tardó un año en situarse como la opción numero en el mercado de servidores manteniendo y aumentando dicha posición hasta hoy en día.

Aquellos que deseen más información sobre este nuevo lanzamiento de Apache HTTP Server 2.4 pueden acceder a blogs.apache.org.

fuente.desarrolloweb

Oracle advierte de un fallo en HTTP Server

Oracle está advirtiendo a los administradores que actualicen sus sistemas después de descubrir un fallo de seguridad en el componente HTTP Server de la compañía.

Oracle ha explicado que el componente vulnerable puede encontrarse en sus plataformas Fusion Middleware 11g y Application Server 10g. La vulnerabilidad se encuentra en la herramienta de HTTP Server para Apache 2.0 y 2.2.

La compañía ha advertido a los administradores que, de explotarse, el fallo podría permitir que un atacante genere un ataque de denegación de servicio. Además, Oracle ha dicho que el fallo podría explotarse de forma remota, sin necesidad de un acceso local o credenciales válidas.

Para proteger los sistemas la compañía ha lanzado un parche para el componente vulnerable.

El parche lanzado por Oracle sigue, tan sólo una semana después, a los lanzados por Microsoft en su programa de actualizaciones de seguridad los segundos martes de mes, y que en septiembre contaba con cinco boletines además de una actualización para revocar una serie de certificados emitidos por DigiNoar que habían sido comprometidos por los hackers.

El lanzamiento también se produce poco antes de que Oracle actualice su plataforma Systems. Será el próximo 26 de septiembre, coincidiendo con la conferencia OpenWorld, cuando Oracle realice el anuncio.

fuente.itespresso

Configurar el archivo Robots.txt

Explicamos el porqué del archivo robots.txt y como se construye dicho archivo.

Para comenzar tenemos que comentar lo que son los robots y qué función cumplen dentro de la red de redes.
Un robot es un programa más o menos complicado que se dedica a rastrear nuestras páginas webs y guardar su contenido en una base de datos y seguir los enlaces que tengamos a otras páginas web. Esto nos beneficia pero también nos puede perjudicar, ya que a veces no nos conviene indexar ciertas páginas de nuestras webs.

Actualmente los robots actúan de tal forma que lo primero que hacen es buscar en la raíz de nuestra página si tenemos un archivo llamado robots.txt, si lo encuentra lo lee y sigue las directrices que en él se encuentran, si no lo encuentra empieza a rastrear toda la web.

Por este tema es importante crear bien este archivo y pensar que páginas queremos que sean rastreadas y cuáles no, ya que las que no sean rastreadas no serán indexadas en los navegadores.

Este archivo es muy fácil de construir tan solo tienes que saber ciertas pautas y podrás hacerlo sin problema.

El archivo robots.txt puede construirse para que se aplique solo a los robots de determinados buscadores.

Pasamos a escribir un ejemplo para ir explicando las posibilidades:

User-agent: * # aplicable a todos los robots
Disallow: / # impide la indexacion de todas las paginas

En este ejemplo los robots no podrían indexar ninguna pagina del dominio.
User-agent lo que nos dice es a que robots se les aplica las características que le siguen debajo. Si usamos el * estamos diciendo que esas reglas son aplicables para todos los robots. Pero también podemos hacerlo para determinados robots, como ves en el siguiente ejemplo:

User-agent: lycra
User-agent: BadBot
Disallow: /

En este ejemplo los robots lucra y BadBot tendría prohibida la indexación de cualquier pagina del dominio.

El disallow nos dice los archivos o carpetas que queremos que no sean indexadas. De esta forma podríamos hacer un archivo como este:

User-agent: *
Disallow: /tmp/prueba.html
Disallow: /logs

Este ejemplo lo que haría sería prohibir la indexación de la carpeta logs y el archive prueba.html a todos los robots.

Con esto ya podríamos realizar un archivo robots.txt perfectamente válido, pero también existen términos para determinar en qué horas queremos que esos robots rastreen nuestras páginas. La forma de construirlo es la siguiente:

Visit-time: 0300-0400 #esta opción obligaría a rastrear las paginas solo de 3 am a 4 am

Recuerda que las horas siempre se colocan en Greenwitch

Por otro lado podemos decirle que indexe una página o varias cada equis tiempo, para ello se utiliza la siguiente sintaxis:

Request-rate: 1/30

Siendo el 1 el número de documentos a rastrear y el 30 el tiempo que transcurre entre un rastreo y el siguiente.

Es importante saber que no puedes dejar líneas en blanco ya que no funcionaria, el robots dejaría de leer en el momento que encuentra la línea en blanco.

Otro aspecto que no he comentado antes pero que habréis notado es que los comentarios ser realizan utilizando la #.

Un ejemplo completo seria el siguiente:

User-agent: *
Disallow: /tmp/prueba.html
Disallow: /logs
Visit-time: 0300-0400

Esto permitirá a todos los robots rastrear todas las paginas menos prueba.html y la carpeta logs, además solo podrían indexar de 3 de la mañana a 4.

Estadisticas Webs de Julio 2009

Según el informe presentado por NetCraft, durante el mes de julio se alcanzo la cifra de 239.611.111 sites, lo que supone un incremento en el número de webs cercano al millón y medio.

Parece confirmarse la tendencia que apunta a una reducción en el crecimiento del número de sites mes a mes. En este sentido, abril + 6 millones, mayo + 4.3 millones, Junio + 2.1 millones y julio + 1.2 millones.

Como cifras interesantes destacar el crecimiento de Blogger, la plataforma de blogs de Google, que apunto un crecimiento de 2.2 millones de sites durante el mes de julio.

El servidor web HTTP de código abierto Apache sigue a la cabeza, desde 1996, alojando más de 113 millones de sitios (39.3 millones activos), seguido por Microsoft IIS con más de 55 millones (18.4 millones activos) y de QQ con 30 millones (!ojo! solo 122 mil activos) y Google con 14.2 millones (10.8 millones activos).