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.

Si en los últimos meses te has pasado por las redes sociales, o incluso si no lo has hecho, es muy probable que hayas oído hablar de ella. Bueno, de ella y de sus problemillas con la informática. Porque, sí, Paquita Salas no ha sabido entenderse con su bandeja de correo y también ha tenido problemas con su dominio. Pero es que Paquita Salas somos, un poco, todos. Los problemas informáticos de Paquita son también habituales en el día a día de cualquier usuario de internet. ¿Quieres evitar ser la nueva Paquita de la informática?

Paquita Salas y el spam

Aunque no te lo creas muchos no saben qué es eso del spam o correo basura. Y muchos de los que saben de qué se trata, no saben dónde se encuentra esta bandeja. Otros simplemente han oído hablar de ello y la pobre Paquita Salas, ni eso.

El spam no es más que esos correos electrónicos que, generalmente, no queremos recibir. Esos mails publicitarios a los que nos suscribimos casi sin darnos cuenta por contratar o utilizar algún servicio; una práctica que ya no debería hacerse, al menos no sin autorización, con el nuevo RGPD. También se consideran correos basura a aquellos que provienen de un remitente desconocido o cuando se envían emails de forma masiva.

Para molestar al usuario lo menos posible, es habitual que los clientes de correo realicen un filtrado de los emails que llegan a tu buzón; normalmente, en función a unas determinadas reglas o si otros usuarios ya han marcado como spam notificaciones que provienen del mismo remitente. De esta forma, aplicaciones como Gmail pueden proporcionar una mejor experiencia a sus usuarios a través de filtros antispam.

Pero las bandejas de spam suelen tener un período de caducidad. Es decir, que, si no consultas con cierta frecuencia los emails que tu cliente de correo envía a la carpeta de spam, es probable que los acabes perdiendo. O puede ser que te enteres demasiado tarde de algo importante, como le pasó a Paquita Salas.

Si Paquita hubiera sabido qué era el spam y cómo consultarlo, no se hubiera enterado tan tarde del cambio de horario. Ese email que nunca llegó, porque Paquita no tenía una cuenta spam, o eso creían ella y Magüi. Pero, bueno, que lo mismo le pasó unos años antes con el fax; y eso nada tenía que ver con notificaciones no deseadas.

Cuando te quedas sin ‘domain’

Si el spam fue el protagonista tecnológico de la primera temporada de la serie, en la segunda reinó el dominio. Como ya hemos contado en otras ocasiones, los dominios no son tan diferentes a los humanos, al menos en lo que a su ciclo de vida se refiere.

Paquita pensó que su ‘domain’ era de esas cosas que solo tienes que hacer una vez en la vida, pero no. Que registras el dominio una vez y dura para siempre sin tener que preocuparte por su renovación. Pero, cuando decidió utilizar su abandonada web para promocionar sus eventos y servicios, se llevó una desagradable sorpresa. Y es que Ps Management era un dominio que ya no le pertenecía. Ahora su dominio le pertenece a alguien que, además de haber estado hábil para registrarlo, a buen seguro no tendrá ni idea de español. Y, claro, la pobre Paquita ha tenido que cambiar su web de representación de artistas, ahora puedes encontrar su sitio web en Ps Management.

Desgraciadamente esta es una práctica muy habitual que ha hecho todo un negocio del registro de dominios. Hay quienes se dedican a registrar dominios al precio habitual para revenderlos después por un coste muy superior. Un chantaje al que muchos ceden porque cualquier proyecto gira entorno a una web y un dominio.

No seas Paquita

Para evitar hacerte un Paquita Salas, en Linube contamos con un servicio de renovación automática de los dominios. De esta forma, puedes estar tranquilo, que tu dominio no caducará hasta que tú decidas que no quieres renovarlo más. Además, te notificaremos por email que tu dominio está a punto de caducar; así que por si acaso atento a tu spam.

Y, como consejo, si estás pensando en iniciar cualquier proyecto, mira si el dominio está disponible. Si lo está, lo esperes más para registrar el dominio. Así, el día que todos conozcan tu proyecto, podrán buscar información en tu sitio web; y no en uno que no lleve el mismo nombre.

Es evidente que Paquita Salas nos ha enseñado mucho. El personaje creado por ‘Los Javis’, nos ha llevado de vuelta al panorama artístico español de los 80; pero también nos está enseñando el uso de las redes sociales y algunos de los problemas más habituales en relación al mundo del hosting. De sus inconvenientes con la informática podemos aprender todos, así que pongámoslo en práctica, evita hacerte ‘un Paquita Salas’; pero disfruta de sus aventuras en Netflix.