{"id":540,"date":"2016-10-03T09:44:30","date_gmt":"2016-10-03T08:44:30","guid":{"rendered":"http:\/\/tecnologiasweb.jsenso.es\/?p=540"},"modified":"2016-10-03T09:44:30","modified_gmt":"2016-10-03T08:44:30","slug":"los-codigos-respuesta-del-servidor-http-claves-arquitectura","status":"publish","type":"post","link":"https:\/\/blogs.ugr.es\/tecweb\/los-codigos-respuesta-del-servidor-http-claves-arquitectura\/","title":{"rendered":"Los c\u00f3digos de respuesta del servidor HTTP como claves en la arquitectura web"},"content":{"rendered":"<p>En muchas oc<img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-542\" src=\"https:\/\/blogs.ugr.es\/tecweb\/wp-content\/uploads\/sites\/55\/2018\/10\/\u00edndice.jpg\" alt=\"El cl\u00e1sico mensaje de error\" width=\"344\" height=\"111\" \/>asiones, cuando navegamos por la Web, o cuando buscamos en Google, nos encontramos con el famoso Error 404: Url not found. Para el usuario de a pie, este tipo de mensajes no son m\u00e1s que un incordio. Para el arquitecto de la informaci\u00f3n son pistas fundamentales que le permiten saber que en su sitio web hay un problema y, adem\u00e1s, c\u00f3mo tiene que solucionarlo.<\/p>\n<p>Antes de hablar del por qu\u00e9 de esos famosos c\u00f3digos, vamos a analizar en qu\u00e9 momento se producen. Para ello, hablaremos primero de c\u00f3mo funciona el protocolo HTTP.<\/p>\n<h2>El funcionamiento de HTTP<\/h2>\n<p>Se trata de un protocolo que trabaja a nivel de aplicaci\u00f3n, y que est\u00e1 soportado por los servicios de conexi\u00f3n TCP\/IP. Su funcionamiento es id\u00e9ntico al del resto de servicios de su entorno: el servidor est\u00e1 continuamente escuchando el puerto de comunicaciones TCP<a href=\"#_ftn1\" name=\"_ftnref1\"><\/a> a la espera de que llegue una solicitud de conexi\u00f3n por parte del cliente HTTP (el navegdor, por ejemplo). En cuanto llega dicha solicitud el mismo protocolo TCP se encarga de mantener la comunicaci\u00f3n y garantizar que el intercambio de datos se realiza sin errores. Es un proceso de solicitud\/respuesta. El cliente establece una conexi\u00f3n con un servidor por medio de una solicitud (por ejemplo, el fichero index.html). El servidor responde con un mensaje que contiene el estado de la operaci\u00f3n (si se encuentra ese recurso, si no aparece\u2026) y el resultado (el fichero index.html) que el cliente procesa, interpreta y muestra al usuario.<img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-543 aligncenter\" src=\"https:\/\/blogs.ugr.es\/tecweb\/wp-content\/uploads\/sites\/55\/2018\/10\/http_funcionamiento.gif\" alt=\"El funcionamiento de http. Fuente: http:\/\/www.profesordeinformatica.com\/servicios\/http\/funcionamiento\" width=\"320\" height=\"205\" \/><\/p>\n<p>Para que este protocolo funcione correctamente necesita de un mecanismo que permita identificar los recursos, con el fin de que el cliente los pueda llamar de la forma correcta, y el servidor sepa en todo momento y de manera un\u00edvoca qu\u00e9 es lo que se busca. Ese mecanismo es la URL (Uniform Resource Locator). Es una forma est\u00e1ndar de hacer referencia a cualquier recurso (servicio) de Internet (s\u00ed, porque no s\u00f3lo vale para el servicio HTTP).<\/p>\n<p>Si el servidor HTTP no puede mostrar el recurso solicitado, env\u00eda un c\u00f3digo de respuesta formado por tres d\u00edgitos. El primero indica el estado, mientras que los otros dos explican la naturaleza exacta del error. En otras palabras, es el origen del famoso Error 404: URL not found.<\/p>\n<h2>Los c\u00f3digos de respuesta<\/h2>\n<p>Esta tabla aglutina lo que representa cada uno de los c\u00f3digos que env\u00eda el servidor al cliente informando de su estado:<\/p>\n<table border=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td width=\"62\"><strong>C\u00f3digo<\/strong><\/td>\n<td width=\"122\"><strong>Mensaje<\/strong><\/td>\n<td width=\"365\"><strong>Descripci\u00f3n<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"62\"><strong>1xx<\/strong><\/td>\n<td width=\"122\"><strong>Mensaje de informaci\u00f3n<\/strong><\/td>\n<td width=\"365\"><strong>Estos c\u00f3digos no se utilizan en la versi\u00f3n 1.0 del protocolo<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"62\"><strong>2xx<\/strong><\/td>\n<td width=\"122\"><strong>\u00c9xito<\/strong><\/td>\n<td width=\"365\"><strong>Estos c\u00f3digos indican la correcta ejecuci\u00f3n de la transacci\u00f3n<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"62\">200<\/td>\n<td width=\"122\">OK<\/td>\n<td width=\"365\">La solicitud se llev\u00f3 a cabo de manera correcta<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">201<\/td>\n<td width=\"122\">CREATED<\/td>\n<td width=\"365\">Sigue a un comando POST e indica el \u00e9xito, la parte restante del cuerpo indica la direcci\u00f3n URL donde se ubicar\u00e1 el documento creado recientemente.<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">202<\/td>\n<td width=\"122\">ACCEPTED<\/td>\n<td width=\"365\">La solicitud ha sido aceptada, pero el procedimiento que sigue no se ha llevado a cabo<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">203<\/td>\n<td width=\"122\">PARTIAL INFORMATION<\/td>\n<td width=\"365\">Cuando se recibe este c\u00f3digo en respuesta a un comando de GET indica que la respuesta no est\u00e1 completa.<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">204<\/td>\n<td width=\"122\">NO RESPONSE<\/td>\n<td width=\"365\">El servidor ha recibido la solicitud, pero no hay informaci\u00f3n de respuesta<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">205<\/td>\n<td width=\"122\">RESET CONTENT<\/td>\n<td width=\"365\">El servidor le indica al navegador que borre el contenido en los campos de un formulario<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">206<\/td>\n<td width=\"122\">PARTIAL CONTENT<\/td>\n<td width=\"365\">Es una respuesta a una solicitud que consiste en el encabezado <em>range<\/em>. El servidor debe indicar el encabezado<em>content-Range<\/em><\/td>\n<\/tr>\n<tr>\n<td width=\"62\"><strong>3xx<\/strong><\/td>\n<td width=\"122\"><strong>Redirecci\u00f3n<\/strong><\/td>\n<td width=\"365\"><strong>Estos c\u00f3digos indican que el recurso ya no se encuentra en la ubicaci\u00f3n especificada<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"62\">301<\/td>\n<td width=\"122\">MOVED<\/td>\n<td width=\"365\">Los datos solicitados han sido transferidos a una nueva direcci\u00f3n<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">302<\/td>\n<td width=\"122\">FOUND<\/td>\n<td width=\"365\">Los datos solicitados se encuentran en una nueva direcci\u00f3n URL, pero, no obstante, pueden haber sido trasladados<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">303<\/td>\n<td width=\"122\">METHOD<\/td>\n<td width=\"365\">Significa que el cliente debe intentarlo con una nueva direcci\u00f3n; es preferible que intente con otro m\u00e9todo en vez de GET<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">304<\/td>\n<td width=\"122\">NOT MODIFIED<\/td>\n<td width=\"365\">Si el cliente llev\u00f3 a cabo un comando GET condicional (con la solicitud relativa a si el documento ha sido modificado desde la \u00faltima vez) y el documento no ha sido modificado, este c\u00f3digo se env\u00eda como respuesta.<\/td>\n<\/tr>\n<tr>\n<td width=\"62\"><strong>4xx<\/strong><\/td>\n<td width=\"122\"><strong>Error debido al cliente<\/strong><\/td>\n<td width=\"365\"><strong>Estos c\u00f3digos indican que la solicitud es incorrecta<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"62\">400<\/td>\n<td width=\"122\">BAD REQUEST<\/td>\n<td width=\"365\">La sintaxis de la solicitud se encuentra formulada de manera err\u00f3nea o es imposible de responder<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">401<\/td>\n<td width=\"122\">UNAUTHORIZED<\/td>\n<td width=\"365\">Los par\u00e1metros del mensaje aportan las especificaciones de formularios de autorizaci\u00f3n que se admiten. El cliente debe reformular la solicitud con los datos de autorizaci\u00f3n correctos<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">402<\/td>\n<td width=\"122\">PAYMENT REQUIRED<\/td>\n<td width=\"365\">El cliente debe reformular la solicitud con los datos de pago correctos<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">403<\/td>\n<td width=\"122\">FORBIDDEN<\/td>\n<td width=\"365\">El acceso al recurso simplemente se deniega<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">404<\/td>\n<td width=\"122\">NOT FOUND<\/td>\n<td width=\"365\">El servidor no hall\u00f3 nada en la direcci\u00f3n especificada. Se ha abandonado sin dejar una direcci\u00f3n para redireccionar&#8230;<\/td>\n<\/tr>\n<tr>\n<td width=\"62\"><strong>5xx<\/strong><\/td>\n<td width=\"122\"><strong>Error debido al servidor<\/strong><\/td>\n<td width=\"365\"><strong>Estos c\u00f3digos indican que existe un error interno en el servidor<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"62\">500<\/td>\n<td width=\"122\">INTERNAL ERROR<\/td>\n<td width=\"365\">El servidor encontr\u00f3 una condici\u00f3n inesperada que le impide seguir con la solicitud (una de esas cosas que les suceden a los servidores&#8230;)<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">501<\/td>\n<td width=\"122\">NOT IMPLEMENTED<\/td>\n<td width=\"365\">El servidor no admite el servicio solicitado (no puede saberlo todo&#8230;)<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">502<\/td>\n<td width=\"122\">BAD GATEWAY<\/td>\n<td width=\"365\">El servidor que act\u00faa como una puerta de enlace o proxy ha recibido una respuesta no v\u00e1lida del servidor al que intenta acceder<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">503<\/td>\n<td width=\"122\">SERVICE UNAVAILABLE<\/td>\n<td width=\"365\">El servidor no puede responder en ese momento debido a que se encuentra congestionado (todas las l\u00edneas de comunicaci\u00f3n se encuentran congestionadas, intentelo de nuevo m\u00e1s adelante)<\/td>\n<\/tr>\n<tr>\n<td width=\"62\">504<\/td>\n<td width=\"122\">GATEWAY TIMEOUT<\/td>\n<td width=\"365\">La respuesta del servidor ha llevado demasiado tiempo en relaci\u00f3n al tiempo de espera que la puerta de enlace pod\u00eda admitir (excedi\u00f3 el tiempo asignado&#8230;)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<h2>\u00bfY qu\u00e9 hago con esos c\u00f3digos?<\/h2>\n<p>Desde el punto de vista de la arquitectura de la informaci\u00f3n web estos c\u00f3digos arrojan una informaci\u00f3n muy valiosa que no deber\u00edamos desde\u00f1ar. Se puede acceder a ellos a trav\u00e9s del fichero log del servidor HTTP, y nos aporta datos muy importantes sobre el estado y diagn\u00f3stico del sitio web. Gracias a ellos podemos acceder de manera m\u00e1s sencilla a resolver errores graves del servicio, de posicionamiento, de estructuraci\u00f3n de la informaci\u00f3n, etc.<\/p>\n<ul>\n<li><strong>C\u00f3digos 2xx<\/strong>: en condiciones normales deber\u00edamos prestar atenci\u00f3n a qu\u00e9 ficheros importantes del servidor HTTP devuelven el c\u00f3digo 200 (especialmente robots.txt y sitemap.xml). Los errores 204 se suelen producir cuando uno de los frames de un sitio web contiene una p\u00e1gina en blanco, por lo que se puede solucionar poniendo alg\u00fan texto oculto (palabras con el mismo color que el fondo de la p\u00e1gina). Los errores 206 se producen cuando, por ejemplo, el cliente no recibe datos embebidos en un fichero binario, por ejemplo, cuando no se carga completamente un fichero PDF. Eso se soluciona reduciendo el tama\u00f1o del PDF, o ampliando el ancho de banda contratado en el hosting<\/li>\n<li><strong>C\u00f3digos 3xx<\/strong>: desde el punto de vista del posicionamiento web son los que m\u00e1s penalizan. Por ejemplo, el 301 se usar\u00e1 cuando se mueva un contenido determinado, que ya haya sido indizado por el motor de b\u00fasqueda. Para corregirlo bastar\u00e1n con realizar un redireccionamiento permanente, comunic\u00e1ndole de esta forma al robot que una o varias p\u00e1ginas han sido movidas a una nueva ubicaci\u00f3n de forma definitiva, as\u00ed el motor de b\u00fasqueda indizar\u00e1 la nueva p\u00e1gina, en vez de la redirigida. Con el 302 se indica que, de manera temporal, el contenido referenciado se ha movido, con lo que el motor de b\u00fasqueda seguir\u00e1 indizando la p\u00e1gina original y no dar\u00e1 de baja ese registro en la base de datos, provocando la p\u00e9rdida del posicionamiento conseguido. Si, por ejemplo, se cuenta con un ancho de banda muy limitado en el hosting, se puede usar el 304 para indicar que ese recurso no ha cambiado desde la \u00faltima solicitud y que, por lo tanto, no es necesario volver a rastrearlo.<\/li>\n<li><strong>C\u00f3digos 4xx<\/strong>: lo ideal es que si alguien introduce un URL en el navegador, a continuaci\u00f3n aparezca la informaci\u00f3n que desea. Si por el contrario aparece un error 4xx habr\u00e1 una penalizaci\u00f3n grave desde todos los puntos de vista. Ya no solo se perder\u00e1 posicionamiento, sino que si el hecho persiste se perder\u00e1n usuarios, visibilidad, se dejar\u00e1n de prestar servicios\u2026 en definitiva, nos autodescartamos del mercado. Por eso siempre viene bien contar con un gestor de enlaces rotos, que se encargue de automatizar el proceso de analizar, cada x tiempo, si existe este tipo de problemas. Si el error se produce por un servicio o recurso que est\u00e1 temporalmente inactivo, lo mejor es hacer una redirecci\u00f3n 301, con lo que se minimizar\u00e1n las p\u00e9rdidas.<\/li>\n<li><strong>C\u00f3digos 5xx<\/strong>: avisan de que hay algo en el servidor no est\u00e1 funcionando de manera correcta. Puede ser desde un servicio a un error interno.<\/li>\n<\/ul>\n<p>As\u00ed que ya sabes, en la web nada sale por accidente. Si aparece uno de estos errores hay que tomar medidas.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>En muchas ocasiones, cuando navegamos por la Web, o cuando buscamos en Google, nos encontramos con el famoso Error 404: Url not found. Para el usuario de a pie, este tipo de mensajes no son m\u00e1s que un incordio. Para el arquitecto de la informaci\u00f3n son pistas fundamentales que le permiten saber que en su [&hellip;]<\/p>\n","protected":false},"author":65,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[20,72,9,39,69],"tags":[97,98,61],"class_list":["post-540","post","type-post","status-publish","format-standard","category-arquitectura-de-la-informacion-web","category-arquitectura-de-los-sistemas-de-informacion-basados-en-la-web","category-claves-para-el-posicionamiento","category-sistemas-de-etiquetado","category-sistemas-de-navegacion","tag-arquitectura-web","tag-http","tag-seo","entry"],"_links":{"self":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/posts\/540","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/users\/65"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/comments?post=540"}],"version-history":[{"count":0,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/posts\/540\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/media?parent=540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/categories?post=540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/tags?post=540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}