Blog

Cuando navegamos por internet, se envían constantemente códigos de estado HTTP. Y, a veces, recibimos todo tipo de errores HTTP. Desde errores 3xx que suelen pasar desapercibidos por el usuario a errores 4xx basados en peticiones incorrectas del lado del cliente hasta errores 5xx relacionados con fallos provenientes del servidor.

Los errores 4xx suelen darse cuando la página que se está intentando cargar no existe o tiene el acceso bloqueado. Existen muchos tipos de errores HTTP, pero en este artículo vamos a centrarnos en los errores 4xx o errores del cliente más habituales.

Error 400 Bad Request

Básicamente, la petición HTTP no se ha producido satisfactoriamente y la petición no puede procesarse. Un error 400 Solicitud Incorrecta puede deberse a diversos factores:

• Al igual que un error 404, la URL no tiene un formato válido; esto es, la solicitud tiene una sintaxis incorrecta.
• Registros DNS obsoletos.
• Existen servidores web que limitan la longitud de los encabezados. Por lo que pueden rechazarse encabezados demasiado largos.
• El servidor puede denegar la carga de archivos muy pesados.
• Las cookies del navegador contienen errores.

Si usamos un servidor IIS 7.0, IIS 7.5 o IIS 8.0 podremos extraer algunos datos del código de estado.

• 400.1: destination header inválido.
• 400.2: depth header inválido.
• 400.3: if header inválido.
• 400.4: overwrite header inválido.
• 400.5: translate header inválido.
• 400.6: request body inválido.
• 400.7: longitud del contenido inválida.
• 400.8: timeout inválido.
• 400.9: lock token inválido.

Aunque suele producirse en el navegador, el error 400 no está exento de producirse fuera del. Por ejemplo, un cliente de correo electrónico, puede recibir este código de estado al comunicarse con el servidor.

Error 401 Authorization Required

El error 401 Se Requiere Autorización se produce, tal y como el nombre indica, porque se requiere autorización para acceder a un recurso o una URL. Puede resultar similar al error 404, pero en este caso es posible acceder a la misma mediante una solicitud de usuario y contraseña.

Cada servidor suele administrar la autentificación de usuarios de modo independiente, por lo que puede producirse un error 401 al no poder validar algunas credenciales. Este error también puede deberse a diversas causas como: no tenemos las credenciales de acceso, las claves son incorrectas o porque hayamos sido bloqueados.

Error 403 Forbidden

Un error 403 Prohibido significa que no se ha obtenido permiso para acceder a la URL de destino. Como usuarios, nos solemos encontrar con el error 403 cuando estamos tratando de acceder a una dirección web que tiene prohibido el acceso. El mensaje suele ser así: Acceso denegado. No tiene permiso para acceder.

También existe la posibilidad de que el culpable de dicho error sea el servidor; o incluso que en nuestro equipo haya un malware que controle el navegador o las credenciales de acceso. De todas formas, las estadísticas demuestran que deberías descartar todas estas opciones en un principio.

Error 404 Not Found

El error 404 No Encontrado es el error HTTP 4xx más habitual de todos. Se trata de un código de respuesta estándar que indica que se ha podido establecer la conexión con el servidor pero no se ha podido encontrar el elemento solicitado. En resumidas cuentas: no podemos acceder a la página web porque ya no existe.

Es un error común en páginas web que han sufrido cambios o en gestores de contenido como WordPress. Es más, es posible configurar una landing de aterrizaje para cuando se produzcan errores 404 en la web.

Error 406 Not Acceptable

El error 406 No Aceptable ocurre cuando el cliente solicita una respuesta utilizando encabezados que el servidor no puede cumplir. Es decir, el servidor no puede responder con el encabezado accept especificado en la solicitud. Esto ocurre en contadas ocasiones ya que casi todos los navegadores web aceptan directrices */* en el encabezado accept.

Existen diferentes encabezados de aceptación:

• Accept: tipos MIME aceptados por el cliente, por ejemplo, archivos HTML.
• Accept-Charset: conjunto de caracteres aceptados por el cliente.
• Accept-Encoding: codificación de los datos aceptada por el cliente.
• Accept Language: los lenguajes naturales aceptados por el cliente.
• Accept-Ranges: los rangos de bytes que se aceptan desde el recurso.

Por lo tanto, si el servidor web detecta que el cliente no puede aceptar los datos que quiere enviar, devolverá un código de error 406 No Aceptable.

Pero también puede suceder lo contrario. El servidor no conoce la extensión de la solicitud y trata de buscar una aplicación instalada en el para servir el archivo. En el caso de que no exista ninguna otra aplicación que sea capaz de servir el archivo, devolverá un error 406. Incluso existe la posibilidad de devolver un 406 si el servidor no está seguro sobre el tipo de MIME del archivo solicitado. Lo cual está bien ya que puede evitar pérdidas de información confidencial guardada en archivos como .pass o .ini.

Este error suele ser difícil de detectar y también determinar su causa debido a que existen más de 50 códigos de estado. De todas formas, resulta extremadamente inusual.

Error 410 Gone

Un error 410 Ya No Disponible notifica que la URL a la que estamos intentando acceder no existe. La diferencia principal entre el error 410 y el 404 es que la cabecera dice a los bots que la URL no existe y que no existirá jamás, por lo que no hace falta que ningún bot vuelva a rastrearla.

Normalmente, este tipo de error HTTP suele ser causada de forma intencionada para evitar el rastreo de esa URL. Y, si no, también existe la posibilidad de crear redirecciones 301 desde el fichero .htaccess.

Y hasta aquí llega el artículo sobre errores 4xx. Si quieres mantenerte informado sobre todo lo relacionado con los dominios, hosting web y programación, puedes consultar nuestro blog .

El Housing o Co-Location es el alquiler de un espacio físico en un Centro de Datos que suele ser propiedad del proveedor y se trata de un entorno totalmente adaptado. El proveedor de housing renta sus instalaciones para que los clientes puedan implantar sus propios servidores en un lugar optimizado en cuanto a refrigeración y conectividad. Asimismo, proporciona potencia eléctrica y seguridad total a dichos servidores.

¿Por qué contratar un servicio de housing?

Existen múltiples razones para alquilar un espacio en un Centro de Datos, como la garantía de un funcionamiento correcto e ininterrumpido en unas instalaciones especializadas, o el ahorro de gasto derivado del mantenimiento.

Otra de las razones principales para transportar los servidores a este tipo de instalaciones es la necesidad de un lugar seguro. Suele ser un servicio bastante demandado por empresas; por razones de seguridad o porque no se reúnen las condiciones adecuadas para el alojamiento. Un proveedor de hosting no puede arriesgarse a tener sus servidores inoperativos o con riesgo de pérdida de información debido a múltiples causas.

El cliente tipo de este tipo de servicios suele ser una empresa grande que cuenta con recursos tecnológicos potentes y requiere de un entorno de máxima seguridad. El objetivo del Data Center es minimizar riesgos eléctricos, de climatización y pérdida de información.

¿Cuál es la diferencia entre hosting y housing?

Cuando hablamos de hosting o alojamiento web nos referimos al alquiler de un servidor en el que se almacena la información de nuestro site. Es decir, un plan de hosting nos permite ser visibles en internet. Al contratar un servidor compartido o dedicado, tenemos acceso al mismo, pero la máquina física es propiedad del proveedor. En cambio, el housing o co-location, es el alquiler de un espacio físico en un Data Center que asegura conectividad ininterrumpida y disponibilidad total. Se alquila un determinado espacio, no un servidor.

Ventajas e inconvenientes

Entre las ventajas del housing destacan:

• Reducción de gastos. El ahorro de costes a largo plazo resulta remarcable, más aún cuando se trata de un alto volumen de servidores.
• Alta seguridad. Protección de datos personales, antirrobo y anti-incendios.
• Posibilidad de reventa. Podemos revender servicios de alojamiento web a terceros.
• Más espacio. Contar con un emplazamiento de altas prestaciones mayor y más seguro.
• Recursos ilimitados. No hay ningún inconveniente si queremos trabajar en varios proyectos simultáneamente.
• Escalabilidad total. Ya sea para servicios de paquetes de transferencia o contratar una monitorización siempre es posible aumentar los recursos.
• Climatización. Refrigeración y ventilación de calidad.

Pero no todo son ventajas, la contratación de este servicio también tiene aspectos negativos:

• Inversión elevada. La compra o el alquiler de un servidor no está al alcance de cualquiera.
• Requerimiento de personal. La configuración y la administración corre a cargo del cliente, por lo que deberá contar con personal cualificado.
• Mantenimiento continuo. Licencias, software… todo es responsabilidad del cliente. También las actualizaciones de hardware y posibles averías.
• Posibles desplazamientos. En caso de que hubiese averías resultaría necesario acercarse al Data Center para subsanar dichos errores.

Según sus características, el housing puede ofrecer altos ingresos a aquellas compañías que puedan costear el mantenimiento del servicio. Por lo que este servicio de housing puede resultar adecuado para empresas grandes (o medianas) e incluso para multinacionales, pero no resulta apto para proyectos de pequeña envergadura.

Hace unos días Google anunciaba mejoras en la protección de datos de sus usuarios; de manera que las aplicaciones de terceros que utilicen las APIs de la compañía, solo puedan tener acceso a la información necesaria. Hasta el momento, no ha sido nada extraño el hecho de que determinadas aplicaciones solicitasen al usuario el acceso a funcionalidades que nada tenían que ver con la app en cuestión. Y ahora, Google quiere mejorar en esto; y de paso tapar un problema igual de grave: la exposición de miles de datos de los usuarios de Google+.

A principios de año, Google apostaba por Project Strobe, una auditoría interna con la que evaluar desde cero el funcionamiento de sus diferentes aplicaciones y poder mejorar la privacidad y la seguridad de sus servicios. Auditoría de la que salió un desagradable descubrimiento: un fallo de seguridad en la API de Google+. Como consecuencia de dicha auditoría, Google ha lanzado 4 medidas para paliar el problema y prevenir futuras brechas de seguridad.

1. El cierre de Google+

Muchos ni siquiera habíamos notado que Google+ seguía existiendo, pero ahí sigue. Y seguirá hasta agosto del próximo 2019, fecha máxima establecida por la compañía para su cierre. Pero la red social de Google no cierra por su escasísima adopción, sino por la exposición de los datos de más de 500.000 usuarios entre 2015 y 2018.

Un bug que fue corregido en marzo de este mismo año y que ha estado silenciado hasta ahora; algo que hubiera sido ilegal de haber sucedido solo unos meses después. El nuevo reglamento de Protección de Datos (RGPD) obliga a advertir al usuario en un plazo inferior a 72 horas después de su descubrimiento de que sus datos han sido comprometidos.

Este error en la API de Google+ permitiría el acceso a terceros no solo a datos del perfil no públicos del usuario, sino también a los de sus amigos. A pesar de ello, Google dice no haber evidencia de que dicha información se haya utilizado de forma incorrecta y que en ningún caso se trata de datos sensibles; como mensajes o cuentas bancarias.

Así que, aprovechando una filtración del bug de seguridad de Google+ por parte del Wall Street Journal, y con la excusa de mejorar la gestión de permisos, la compañía ha anunciado el cierre de su red social. Una muerte anunciada ya que, según Google, el 90% de las sesiones duraban menos de 5 segundos; por lo que mantenerla se hacía insostenible. Hasta la llegada del cierre definitivo, Google facilitará herramientas de migración a los usuarios con las que exportar los datos almacenados en el perfil de Google+. En el caso de los perfiles de empresa la situación será diferente: se mantendrán algunas funcionalidades y se añadirán otras; dando lugar a un producto corporativo totalmente distinto.

2. Gestión de permisos a las aplicaciones

Como segunda medida, Google proporcionará herramientas granulares para ofrecer permisos a aplicaciones de terceros. Con ello se pretende que las aplicaciones no puedan tener acceso total a la información del usuario cuando únicamente necesitan una parte especifica. De esta forma se evitará que, por ejemplo, una aplicación de linterna pueda tener acceso a la agenda de contactos; una funcionalidad que nada tiene que ver con el propósito de la app.

Además, los permisos requerirán de permiso explícito. Es decir, las aplicaciones tendrán que mostrar una página para cada uno de los permisos que quieran solicitar y que el usuario tendrá que aceptar o denegar. Así, en lugar de ver todos los permisos que se solicitan en una misma pantalla, se hará de forma independiente y deberá ser posible aceptar unos y denegar otros.

3. Acceso a Gmail limitado

Con estas medidas, la política de acceso a la API de Gmail también sufrirá modificaciones. Con lo que únicamente las aplicaciones relacionadas con las funcionalidades de Gmail podrán tener acceso a los datos del usuario. Por ejemplo, los gestores de correo, las aplicaciones para almacenamiento en la nube o apps para mejorar la productividad. Nuevas normas que tendrán que ser aceptadas por las aplicaciones antes de solicitar permiso alguno al usuario.

Si quieres revisar qué aplicaciones tienen acceso a tus datos en cuentas de Google, entre las que se incluye Gmail, puedes hacerlo con la herramienta para revisar la seguridad. Además de permitir revisar tu actividad reciente en relación a la seguridad de tus cuentas; te permite mejorar la protección.

4. Limitar el acceso a llamadas, contactos y SMS

Algunas aplicaciones, especialmente en el caso de Android, solicitan permiso para acceder al teléfono del usuario; incluyendo su registro de llamadas y los mensajes de texto. Un acceso que solo debería tener la aplicación asignada para realizar llamar o enviar y recibir SMS; con la excepción de las herramientas para la realización de copias de seguridad y el contestador.

Es evidente que Google ha vendido un fallo de seguridad como una mejora para la gestión de permisos a terceros. Además, en los próximos meses anunciarán nuevas medidas y limitaciones para que el usuario sepa qué permisos otorga y a qué aplicaciones. Lo que no exime a Google de una falta de transparencia con sus usuarios; posiblemente motivada por escándalos similares que se produjeron prácticamente al mismo tiempo, como el caso Cambridge Analytics. Y es precisamente esto, la falta de transparencia de algunas compañías con sus usuarios, una de las cosas que se pretenden corregir con la RGPD.

Si quieres evitar problemas de este tipo, te recomendamos pasarte al webmail privado; de forma que nadie tenga acceso a tus correos. Y, sobre todo, controla qué accesos permites a tus equipos para evitar que tus datos puedan verse comprometidos.