From 9712f14db50c3cbdd3e627203a047406b7987207 Mon Sep 17 00:00:00 2001 From: Alexander Date: Mon, 3 Oct 2022 13:57:41 -0500 Subject: [PATCH 01/17] http html cleanup --- .../index.html | 2 +- .../cors/errors/corsdidnotsucceed/index.html | 4 ++-- files/es/web/http/cors/index.html | 16 ++++++++-------- files/es/web/http/csp/index.html | 6 ------ files/es/web/http/headers/accept/index.html | 6 +++--- .../access-control-allow-origin/index.html | 1 - .../headers/content-security-policy/index.html | 8 ++------ files/es/web/http/headers/index.html | 1 + files/es/web/http/headers/link/index.html | 4 ++-- files/es/web/http/headers/pragma/index.html | 2 +- .../web/http/headers/referrer-policy/index.html | 2 +- files/es/web/http/headers/set-cookie/index.html | 4 ++-- files/es/web/http/index.html | 1 - files/es/web/http/methods/patch/index.html | 2 +- files/es/web/http/methods/put/index.html | 2 +- files/es/web/http/status/206/index.html | 4 ++-- files/es/web/http/status/index.html | 6 ++---- 17 files changed, 29 insertions(+), 42 deletions(-) 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 index aafb4fb35fc34a..4b038404085689 100644 --- 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 @@ -62,7 +62,7 @@

Hacer que tu página funcione

Decidir el caso

-

Este es un tema muy subjetivo que podría considerarse un problema de bikeshedding. Si desea leer más a fondo, lea algunos de los muchos artículos de este tema.

+

Este es un tema muy subjetivo que podría considerarse un problema de bikeshedding. Si desea leer más a fondo, lea algunos de los muchos artículos de este tema.

Ver también

diff --git a/files/es/web/http/cors/errors/corsdidnotsucceed/index.html b/files/es/web/http/cors/errors/corsdidnotsucceed/index.html index 9caf2fd86c4b70..fac768bc704b2a 100644 --- a/files/es/web/http/cors/errors/corsdidnotsucceed/index.html +++ b/files/es/web/http/cors/errors/corsdidnotsucceed/index.html @@ -30,10 +30,10 @@

¿Qué salió mal?

Otras causas posibles:

diff --git a/files/es/web/http/cors/index.html b/files/es/web/http/cors/index.html index 0c13bd7d00dd0c..2ece3b7581000a 100644 --- a/files/es/web/http/cors/index.html +++ b/files/es/web/http/cors/index.html @@ -80,7 +80,7 @@

Solicitudes simples

Nota: 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.
-

Por ejemplo, suponga que el contenido web en el dominio http://foo.example desea invocar contenido en el dominio http://bar.other. Código de este tipo puede ser utilizado dentro de JavaScript desplegado en foo.example:

+

Por ejemplo, suponga que el contenido web en el dominio http://foo.example desea invocar contenido en el dominio http://bar.other. Código de este tipo puede ser utilizado dentro de JavaScript desplegado en foo.example:

var invocation = new XMLHttpRequest();
 var url = 'http://bar.other/resources/public-data/';
@@ -120,13 +120,13 @@ 
Solicitudes simples

 [XML Data]
-

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 Origin: en la línea 10 de arriba, lo que muestra que la invocación proviene del contenido en el dominio http://foo.example.

+

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 Origin: en la línea 10 de arriba, lo que muestra que la invocación proviene del contenido en el dominio http://foo.example.

-

Las líneas 13 - 22 muestran la respuesta HTTP del servidor en el dominio http://bar.other. En respuesta, el servidor envía de vuelta una cabecera Access-Control-Allow-Origin:, mostrado arriba en la línea 16. El uso de la cabecera Origin: y Access-Control-Allow-Origin: muestran el protocolo de control de acceso en su uso más simple. En este caso, el servidor responde con un Access-Control-Allow-Origin: * lo que significa que el recurso puede ser accedido por cualquier dominio en una forma de sitio cruzado. Si el dueño del recurso en http://bar.other deseara restringir el acceso al recurso solamente para http://foo.example, debería devolver lo siguiente:

+

Las líneas 13 - 22 muestran la respuesta HTTP del servidor en el dominio http://bar.other. En respuesta, el servidor envía de vuelta una cabecera Access-Control-Allow-Origin:, mostrado arriba en la línea 16. El uso de la cabecera Origin: y Access-Control-Allow-Origin: muestran el protocolo de control de acceso en su uso más simple. En este caso, el servidor responde con un Access-Control-Allow-Origin: * lo que significa que el recurso puede ser accedido por cualquier dominio en una forma de sitio cruzado. Si el dueño del recurso en http://bar.other deseara restringir el acceso al recurso solamente para http://foo.example, debería devolver lo siguiente:

-

Access-Control-Allow-Origin: http://foo.example

+

Access-Control-Allow-Origin: http://foo.example

-

Note que ahora, ningún otro dominio aparte de http://foo.example (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 Origin.

+

Note que ahora, ningún otro dominio aparte de http://foo.example (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 Origin.

Solicitudes Verificadas

@@ -246,7 +246,7 @@

Solicitudes con credenciales

La capacidad más interesante expuesta tanto por XMLHttpRequest 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 XMLHttpRequest de un sitio curzado, los exploradores no enviarán credenciales. Una bandera específica tiene que ser establecida en el objeto XMLHttpRequest cuando este es invocado.

-

En este ejemplo, el contenido cargado originalmente desde http://foo.example hace una solicitud GET simple a un recurso en http://bar.other que establece Cookies. El contenido en foo.example puede contener un JavaScript como este:

+

En este ejemplo, el contenido cargado originalmente desde http://foo.example hace una solicitud GET simple a un recurso en http://bar.other que establece Cookies. El contenido en foo.example puede contener un JavaScript como este:

var invocation = new XMLHttpRequest();
 var url = 'http://bar.other/resources/credentialed-content/';
@@ -297,7 +297,7 @@ 
Solicitudes con credenciales

 [text/plain payload]
-

Pese a que la línea 11 contiene la Cookie destinada para el contenido en http://bar.other, si bar.other no responde con Access-Control-Allow-Credentials: true (línea 19) la respuesta será ignorada y no puesta a disposición para el contenido web. Nota Importante: cuando se responde a una solicitud con credeciales, el servidor debe especificar un dominio, y no puede usar comodines. El ejemplo de arriba fallará si la cabecera fuera un comodín como: Access-Control-Allow-Origin: *. Dado que Access-Control-Allow-Origin menciona explícitamente http://foo.example, el contenido de credenciales competente es devuelto al contenido web invocador. Observe que, en la línea 22, se establece una cookie adicional.

+

Pese a que la línea 11 contiene la Cookie destinada para el contenido en http://bar.other, si bar.other no responde con Access-Control-Allow-Credentials: true (línea 19) la respuesta será ignorada y no puesta a disposición para el contenido web. Nota Importante: cuando se responde a una solicitud con credeciales, el servidor debe especificar un dominio, y no puede usar comodines. El ejemplo de arriba fallará si la cabecera fuera un comodín como: Access-Control-Allow-Origin: *. Dado que Access-Control-Allow-Origin menciona explícitamente http://foo.example, el contenido de credenciales competente es devuelto al contenido web invocador. Observe que, en la línea 22, se establece una cookie adicional.

Todos estos ejemplos pueden verse funcionando aquí. La siguiente sección se refiere a las verdaderas cabeceras HTTP.

@@ -316,7 +316,7 @@

Access-Control-Allow-Origin

Por ejemplo, para permitir a http://mozilla.com acceder al recurso, usted puede especificar:

-
Access-Control-Allow-Origin: http://mozilla.com
+
Access-Control-Allow-Origin: http://mozilla.com

Si el servidor especifica un host de origen en vez de "*", entonces se debe incluir Origin en el encabezado de respuesta Vary para indicar a los clientes que las respuestas del servidor difieren basándose en el valor del encabezado de respuesta Origin.

diff --git a/files/es/web/http/csp/index.html b/files/es/web/http/csp/index.html index fcd294933dce85..05a8a8948978fc 100644 --- a/files/es/web/http/csp/index.html +++ b/files/es/web/http/csp/index.html @@ -180,12 +180,6 @@

Compatibilidad del navegador

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 debido a que la Política de Seguridad del Contenido no permite el contenido.

-
-
-
- - -

Vea también

diff --git a/files/es/web/http/headers/link/index.html b/files/es/web/http/headers/link/index.html index 76d4b72b967af6..1b4a86b2948cfc 100644 --- a/files/es/web/http/headers/link/index.html +++ b/files/es/web/http/headers/link/index.html @@ -55,12 +55,12 @@

< {{RFC(8288, "Link Serialisation in HTTP Headers", 3)}} - IETF RFC + IETF RFC {{RFC(5988, "The Link Header Field", 5)}} - IETF RFC + IETF RFC Definición inicial diff --git a/files/es/web/http/headers/pragma/index.html b/files/es/web/http/headers/pragma/index.html index 3efa64598df48d..d6bc3d93978633 100644 --- a/files/es/web/http/headers/pragma/index.html +++ b/files/es/web/http/headers/pragma/index.html @@ -7,7 +7,7 @@

El Pragmaencabezado 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. Se utiliza para la compatibilidad con versiones anteriores de las memorias caché HTTP / 1.0 en las que el Cache-Controlencabezado HTTP / 1.1 aún no está presente.

-
+

Nota : Pragmano se especifica para las respuestas HTTP y, por lo tanto, no es un reemplazo confiable para el Cache-Controlencabezado HTTP / 1.1 general , aunque se comporta de la misma manera que Cache-Control: no-cache, si el Cache-Controlcampo del encabezado se omite en una solicitud. Utilice Pragmasolo para compatibilidad con versiones anteriores con clientes HTTP / 1.0.

diff --git a/files/es/web/http/headers/referrer-policy/index.html b/files/es/web/http/headers/referrer-policy/index.html index d93fdf73a9b846..b9d7cd94655a01 100644 --- a/files/es/web/http/headers/referrer-policy/index.html +++ b/files/es/web/http/headers/referrer-policy/index.html @@ -202,7 +202,7 @@

Compatibilidad entre navegadores

Notas:

    -
  • A partir de la versión 53 en adelante, Gecko incluye una preferencia de about:config para permitir a los usuarios definir su directiva Referrer-Policy predeterminada: network.http.referer.userControlPolicy.
    • +
  • A partir de la versión 53 en adelante, Gecko incluye una preferencia de about:config para permitir a los usuarios definir su directiva Referrer-Policy predeterminada: network.http.referer.userControlPolicy.
  • A partir de la versión 59 (consulte el informe n.º 587523), esta preferencia ha cambiado de nombre: ahora son network.http.referer.defaultPolicy y network.http.referer.defaultPolicy.pbmode.
diff --git a/files/es/web/http/headers/set-cookie/index.html b/files/es/web/http/headers/set-cookie/index.html index 172c921e0c70b5..5b804d0f485a4a 100644 --- a/files/es/web/http/headers/set-cookie/index.html +++ b/files/es/web/http/headers/set-cookie/index.html @@ -98,8 +98,8 @@

Directivas

Path=<path-value> {{optional_inline}}
-
Una ruta que debe existir en la URL solicitada, o el navegador no enviará el encabezado Cookie.
-
El caracter diagonal (/) es interpretado como un separador de directorios y subdirectorios que serán también comparados: para Path=/docs, /docs, /docs/Web/, y /docs/Web/HTTP todos tendrán que coincidir.
+
Una ruta que debe existir en la URL solicitada, o el navegador no enviará el encabezado Cookie. + El caracter diagonal (/) es interpretado como un separador de directorios y subdirectorios que serán también comparados: para Path=/docs, /docs, /docs/Web/, y /docs/Web/HTTP todos tendrán que coincidir.
Secure {{optional_inline}}
Una cookie segura es sólo enviada al servidor cuando una petición es enviada con el esquema https:. (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.)

Nota: Sitios inseguros (http:) no puenden almacenar directivas "seguras" apartir de Chrome 52+ y Firefox 52+.

diff --git a/files/es/web/http/index.html b/files/es/web/http/index.html index 12df18b6c479df..f450bf094b3a28 100644 --- a/files/es/web/http/index.html +++ b/files/es/web/http/index.html @@ -45,7 +45,6 @@

Tutoriales

Se muestra y explica cómo es una sesión HTTP típica.
Manejo de conexión en HTTP/1.X
Se describen los tres tipos de gestiones posibles en una sesión HTTP/1.x, sus principales ventajas e inconvenientes.
-

diff --git a/files/es/web/http/methods/patch/index.html b/files/es/web/http/methods/patch/index.html index e6b95607ec78a8..737c6c33f7c3a5 100644 --- a/files/es/web/http/methods/patch/index.html +++ b/files/es/web/http/methods/patch/index.html @@ -70,7 +70,7 @@

Respuesta

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.

-
HTTP/1.1 204 No Content
+
HTTP/1.1 204 No Content
 Content-Location: /file.txt
 ETag: "e0023aa4f"

 
diff --git a/files/es/web/http/methods/put/index.html b/files/es/web/http/methods/put/index.html
index 3b5c5d00c90c3e..d79cdda40d924f 100644
--- a/files/es/web/http/methods/put/index.html
+++ b/files/es/web/http/methods/put/index.html
@@ -62,7 +62,7 @@ 
Respuestas

 
 
Si el elemento de destino no existe y la petición PUT lo crea de forma satisfactoria, entonces el servidor debe informar al usuario enviando una respuesta {{HTTPStatus("201")}} (Created) .

 
-
HTTP/1.1 201 Created
+
HTTP/1.1 201 Created
 Content-Location: /nuevo.html

 
 
Si el elemento existe actualmente y es modificado de forma satisfactoria, entonces el servidor de origen debe enviar una respuesta {{HTTPStatus("200")}} (OK) o una respuesta {{HTTPStatus("204")}} (No Content) para indicar que la modificación del elemento se ha realizado sin problemas.

diff --git a/files/es/web/http/status/206/index.html b/files/es/web/http/status/206/index.html
index e33ef68d1b484a..8ea0ba9297d83b 100644
--- a/files/es/web/http/status/206/index.html
+++ b/files/es/web/http/status/206/index.html
@@ -19,7 +19,7 @@ 
Ejemplos

 
 
Una respuesta conteniendo un solo rango:

 
-
HTTP/1.1 206 Partial Content
+
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
@@ -30,7 +30,7 @@ 
Ejemplos

 
 
Una respuesta conteniendo varios rangos:

 
-
HTTP/1.1 206 Partial Content
+
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
diff --git a/files/es/web/http/status/index.html b/files/es/web/http/status/index.html
index 3831e38435332e..4ab7bfa00252bf 100644
--- a/files/es/web/http/status/index.html
+++ b/files/es/web/http/status/index.html
@@ -38,10 +38,10 @@ 
Respuestas informativas

 
Respuestas satisfactorias

 
 
    
- 
  • GET: El recurso se ha obtenido y se transmite en el cuerpo del mensaje.
    • 
+ 
  •     GET: El recurso se ha obtenido y se transmite en el cuerpo del mensaje.
    • 
  
  • HEAD: Los encabezados de entidad están en el cuerpo del mensaje.
    • 
  
  • PUT o POST: El recurso que describe el resultado de la acción se transmite en el cuerpo del mensaje.
    • 
- 
  • TRACE: El cuerpo del mensaje contiene el mensaje de solicitud recibido por el servidor.
    • 
+ 
  • TRACE: El cuerpo del mensaje contiene el mensaje de solicitud recibido por el servidor.    
    • 
 

 
 

@@ -76,7 +76,6 @@ 
Redirecciones

  
Este código de respuesta significa que la URI  del recurso solicitado ha sido cambiado. Probablemente una nueva URI sea devuelta en la respuesta.

  
{{HTTPStatus(302, "302 Found")}}

  
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.

- 

  
{{HTTPStatus(303, "303 See Other")}}

  
El servidor envía esta respuesta para dirigir al cliente a un nuevo recurso solicitado a otra dirección usando una petición GET.

  
{{HTTPStatus(304, "304 Not Modified")}}

@@ -84,7 +83,6 @@ 
Redirecciones

  
305 Use Proxy {{deprecated_inline}}

  
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.

  
306 unused

- 

  
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.

  
{{HTTPStatus(307, "307 Temporary Redirect")}}

  
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 302 Found, con la excepción de que el agente usuario no debe cambiar el método HTTP usado: si un POST fue usado en la primera petición, otro POST debe ser usado en la segunda petición.


From 16677ca7e34ca8f0d3f2f737cfb7e82bc737e1e9 Mon Sep 17 00:00:00 2001
From: Alexander 
Date: Mon, 3 Oct 2022 13:58:16 -0500
Subject: [PATCH 02/17] http rename html to md

---
 .../{index.html => index.md}                                      | 0
 .../http/cors/errors/corsdidnotsucceed/{index.html => index.md}   | 0
 files/es/web/http/cors/{index.html => index.md}                   | 0
 files/es/web/http/csp/{index.html => index.md}                    | 0
 files/es/web/http/headers/accept/{index.html => index.md}         | 0
 .../headers/access-control-allow-origin/{index.html => index.md}  | 0
 .../http/headers/content-security-policy/{index.html => index.md} | 0
 files/es/web/http/headers/{index.html => index.md}                | 0
 files/es/web/http/headers/link/{index.html => index.md}           | 0
 files/es/web/http/headers/pragma/{index.html => index.md}         | 0
 .../es/web/http/headers/referrer-policy/{index.html => index.md}  | 0
 files/es/web/http/headers/set-cookie/{index.html => index.md}     | 0
 files/es/web/http/{index.html => index.md}                        | 0
 files/es/web/http/methods/patch/{index.html => index.md}          | 0
 files/es/web/http/methods/put/{index.html => index.md}            | 0
 files/es/web/http/status/206/{index.html => index.md}             | 0
 files/es/web/http/status/{index.html => index.md}                 | 0
 17 files changed, 0 insertions(+), 0 deletions(-)
 rename files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/{index.html => index.md} (100%)
 rename files/es/web/http/cors/errors/corsdidnotsucceed/{index.html => index.md} (100%)
 rename files/es/web/http/cors/{index.html => index.md} (100%)
 rename files/es/web/http/csp/{index.html => index.md} (100%)
 rename files/es/web/http/headers/accept/{index.html => index.md} (100%)
 rename files/es/web/http/headers/access-control-allow-origin/{index.html => index.md} (100%)
 rename files/es/web/http/headers/content-security-policy/{index.html => index.md} (100%)
 rename files/es/web/http/headers/{index.html => index.md} (100%)
 rename files/es/web/http/headers/link/{index.html => index.md} (100%)
 rename files/es/web/http/headers/pragma/{index.html => index.md} (100%)
 rename files/es/web/http/headers/referrer-policy/{index.html => index.md} (100%)
 rename files/es/web/http/headers/set-cookie/{index.html => index.md} (100%)
 rename files/es/web/http/{index.html => index.md} (100%)
 rename files/es/web/http/methods/patch/{index.html => index.md} (100%)
 rename files/es/web/http/methods/put/{index.html => index.md} (100%)
 rename files/es/web/http/status/206/{index.html => index.md} (100%)
 rename files/es/web/http/status/{index.html => index.md} (100%)

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.md
similarity index 100%
rename from files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html
rename to files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md
diff --git a/files/es/web/http/cors/errors/corsdidnotsucceed/index.html b/files/es/web/http/cors/errors/corsdidnotsucceed/index.md
similarity index 100%
rename from files/es/web/http/cors/errors/corsdidnotsucceed/index.html
rename to files/es/web/http/cors/errors/corsdidnotsucceed/index.md
diff --git a/files/es/web/http/cors/index.html b/files/es/web/http/cors/index.md
similarity index 100%
rename from files/es/web/http/cors/index.html
rename to files/es/web/http/cors/index.md
diff --git a/files/es/web/http/csp/index.html b/files/es/web/http/csp/index.md
similarity index 100%
rename from files/es/web/http/csp/index.html
rename to files/es/web/http/csp/index.md
diff --git a/files/es/web/http/headers/accept/index.html b/files/es/web/http/headers/accept/index.md
similarity index 100%
rename from files/es/web/http/headers/accept/index.html
rename to files/es/web/http/headers/accept/index.md
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.md
similarity index 100%
rename from files/es/web/http/headers/access-control-allow-origin/index.html
rename to files/es/web/http/headers/access-control-allow-origin/index.md
diff --git a/files/es/web/http/headers/content-security-policy/index.html b/files/es/web/http/headers/content-security-policy/index.md
similarity index 100%
rename from files/es/web/http/headers/content-security-policy/index.html
rename to files/es/web/http/headers/content-security-policy/index.md
diff --git a/files/es/web/http/headers/index.html b/files/es/web/http/headers/index.md
similarity index 100%
rename from files/es/web/http/headers/index.html
rename to files/es/web/http/headers/index.md
diff --git a/files/es/web/http/headers/link/index.html b/files/es/web/http/headers/link/index.md
similarity index 100%
rename from files/es/web/http/headers/link/index.html
rename to files/es/web/http/headers/link/index.md
diff --git a/files/es/web/http/headers/pragma/index.html b/files/es/web/http/headers/pragma/index.md
similarity index 100%
rename from files/es/web/http/headers/pragma/index.html
rename to files/es/web/http/headers/pragma/index.md
diff --git a/files/es/web/http/headers/referrer-policy/index.html b/files/es/web/http/headers/referrer-policy/index.md
similarity index 100%
rename from files/es/web/http/headers/referrer-policy/index.html
rename to files/es/web/http/headers/referrer-policy/index.md
diff --git a/files/es/web/http/headers/set-cookie/index.html b/files/es/web/http/headers/set-cookie/index.md
similarity index 100%
rename from files/es/web/http/headers/set-cookie/index.html
rename to files/es/web/http/headers/set-cookie/index.md
diff --git a/files/es/web/http/index.html b/files/es/web/http/index.md
similarity index 100%
rename from files/es/web/http/index.html
rename to files/es/web/http/index.md
diff --git a/files/es/web/http/methods/patch/index.html b/files/es/web/http/methods/patch/index.md
similarity index 100%
rename from files/es/web/http/methods/patch/index.html
rename to files/es/web/http/methods/patch/index.md
diff --git a/files/es/web/http/methods/put/index.html b/files/es/web/http/methods/put/index.md
similarity index 100%
rename from files/es/web/http/methods/put/index.html
rename to files/es/web/http/methods/put/index.md
diff --git a/files/es/web/http/status/206/index.html b/files/es/web/http/status/206/index.md
similarity index 100%
rename from files/es/web/http/status/206/index.html
rename to files/es/web/http/status/206/index.md
diff --git a/files/es/web/http/status/index.html b/files/es/web/http/status/index.md
similarity index 100%
rename from files/es/web/http/status/index.html
rename to files/es/web/http/status/index.md

From bed2b3a133b3077e192aec03644e17a2db8f57e3 Mon Sep 17 00:00:00 2001
From: Alexander 
Date: Mon, 3 Oct 2022 13:58:25 -0500
Subject: [PATCH 03/17] http h2m replace

---
 .../index.md                                  |  64 +-
 .../cors/errors/corsdidnotsucceed/index.md    |  40 +-
 files/es/web/http/cors/index.md               | 362 +++++----
 files/es/web/http/csp/index.md                | 234 +++---
 files/es/web/http/headers/accept/index.md     | 128 ++--
 .../access-control-allow-origin/index.md      | 110 ++-
 .../headers/content-security-policy/index.md  | 394 +++++-----
 files/es/web/http/headers/index.md            | 719 ++++++++----------
 files/es/web/http/headers/link/index.md       |  81 +-
 files/es/web/http/headers/pragma/index.md     |  96 ++-
 .../web/http/headers/referrer-policy/index.md | 307 +++-----
 files/es/web/http/headers/set-cookie/index.md | 274 ++++---
 files/es/web/http/index.md                    | 106 ++-
 files/es/web/http/methods/patch/index.md      | 125 ++-
 files/es/web/http/methods/put/index.md        | 127 ++--
 files/es/web/http/status/206/index.md         |  77 +-
 files/es/web/http/status/index.md             | 346 ++++-----
 17 files changed, 1639 insertions(+), 1951 deletions(-)

diff --git a/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md
index 4b038404085689..699217cb14194d 100644
--- a/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md
+++ b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md
@@ -9,63 +9,57 @@ tags:
   - no www
 translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
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.

+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.
 
-
¿Qué son los nombres de dominio?

+## ¿Qué son los nombres de dominio?
 
-
En una URL HTTP, la primera subcadena que sigue a la inicial http:// o https:// se llama nombre de dominio. El nombre de dominio está alojado en un servidor donde residen los documentos.

+En una URL HTTP, la primera subcadena que sigue a la inicial `http://` o `https://` se llama nombre de dominio. El nombre de dominio está alojado en un servidor donde residen los documentos.
 
-
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.

+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.
 
-
¿Entonces, ¿tengo que elegir uno u otro para mi sitio web?

+## ¿Entonces, ¿tengo que elegir uno u otro para mi sitio web?
 
-
    
- 
  • Sí, 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.
    • 
- 
  • No, puedes tener dos. Lo que es importante es que seas coherente y consistente con cuál es el dominio oficial. A este dominio oficial se le llama nombre canónico. 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.
    • 
-

+- **Sí**, 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.
+- **No**, puedes tener dos. Lo que es importante es que seas coherente y consistente con cuál es el dominio oficial. **A este dominio oficial se le llama nombre _canónico_.** 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.
 
-
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.

+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.
 
-
Técnicas para las URL canónicas.

+## Técnicas para las URL canónicas.
 
-
Hay diferentes maneras de elegir qué sitio web es canónico.

+Hay diferentes maneras de elegir qué sitio web es _canónico_.
 
-
Usando redirecciones HTTP 301 

+### Usando redirecciones HTTP 301
 
-
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.

+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.
 
-
Ejemplo:

+Ejemplo:
 
-
    
- 
  1. Un servidor recibe una petición para http://www.example.org/whaddup (cuando el dominio canónico es example.org)
    2. 
- 
  2. El servidor responde con un código {{HTTPStatus(301)}} con la cabecera {{HTTPHeader("Location")}}: http://example.org/whaddup.
    3. 
- 
  3. El cliente emite una solicitud al dominio canónico.: http://example.org/whatddup
    4. 
-

+1.  Un servidor recibe una petición para `http://www.example.org/whaddup` (cuando el dominio canónico es example.org)
+2.  El servidor responde con un código {{HTTPStatus(301)}} con la cabecera `{{HTTPHeader("Location")}}: http://example.org/whaddup`.
+3.  El cliente emite una solicitud al dominio canónico.: `http://example.org/whatddup`
 
-
El HTML5 boilerplate project tiene un ejemplo sobre cómo configurar un servidor Apache para redirigir un dominio a otro.

+El [HTML5 boilerplate project](https://github.com/h5bp/html5-boilerplate) tiene un ejemplo sobre [cómo configurar un servidor Apache para redirigir un dominio a otro](https://github.com/h5bp/html5-boilerplate/blob/7a22a33d4041c479d0962499e853501073811887/.htaccess#L219-L258).
 
-
+### `Usando `
 
-
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.

+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.
 
-
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, http://www.example.org/whaddup serviría el mismo contenido que  http://example.org/whaddup, pero con un elemento {{htmlelement("link")}} adicional en la cabecera:

+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, `http://www.example.org/whaddup` serviría el mismo contenido que `http://example.org/whaddup`, pero con un elemento {{htmlelement("link")}} adicional en la cabecera:
 
-
<link href="http://example.org/whaddup" rel="canonical">

+``
 
-
A diferencia del caso anterior, el historial del navegador considerará las direcciones URL no www y www como entradas independientes.

+A diferencia del caso anterior, el historial del navegador considerará las direcciones URL no www y www como entradas independientes.
 
-
Hacer que tu página funcione para ambas

+## Hacer que tu página funcione para ambas
 
-
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.

+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.
 
-
Decidir el caso

+## Decidir el caso
 
-
Este es un tema muy subjetivo que podría considerarse un problema de bikeshedding. Si desea leer más a fondo, lea algunos de los  muchos artículos de este tema.

+Este es un tema muy subjetivo que podría considerarse un problema de [bikeshedding](http://bikeshed.com/). Si desea leer más a fondo, lea algunos de los [muchos artículos](http://www.themezilla.com/should-you-use-www-in-your-url-or-not/) de este tema.
 
-
Ver también

+## Ver también
 
-
+- [Estadísticas sobre lo que la gente escribe en la barra de URL](https://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/) (2011)
diff --git a/files/es/web/http/cors/errors/corsdidnotsucceed/index.md b/files/es/web/http/cors/errors/corsdidnotsucceed/index.md
index fac768bc704b2a..30d1a367baf7aa 100644
--- a/files/es/web/http/cors/errors/corsdidnotsucceed/index.md
+++ b/files/es/web/http/cors/errors/corsdidnotsucceed/index.md
@@ -14,35 +14,31 @@ tags:
   - solución de problemas
 translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
Razón

+## Razón
 
-
Razón: La solicitud CORS no resultó exitosa
-

+```
+Razón: La solicitud CORS no resultó exitosa
+```
 
-
¿Qué salió mal?

+## ¿Qué salió mal?
 
-
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

+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
 
-
En muchos casos, es causado por un complemento del navegador (Ej, un bloqueador de anuncios o un protector de privacidad) que bloquea la solicitud.

+En muchos casos, es causado por un complemento del navegador (Ej, un bloqueador de anuncios o un protector de privacidad) que bloquea la solicitud.
 
-
Otras causas posibles:

+Otras causas posibles:
 
-
    
- 
  •  Intentar acceder a un recurso https que tenga un certificado no válido, causará este error.
    • 
- 
  • Intentar acceder a un recurso http desde una página con un origen https también causará este error.
    • 
- 
  • A partir de Firefox 68, las páginas https no pueden acceder a http://localhost, aunque esto puede ser modificado por el Error 1488740.
    • 
- 
  • El servidor no respondió a la solicitud actual (incluso si respondió la solicitud Preflight. Un escenario podría ser un servicio HTTP en desarrollo que "entró en pánico" sin devolver ningún dato. 
    • 
-

+- Intentar acceder a un recurso `https` que tenga un certificado no válido, causará este error.
+- Intentar acceder a un recurso `http` desde una página con un origen `https` también causará este error.
+- A partir de Firefox 68, las páginas `https` no pueden acceder a `http://localhost`, aunque esto puede ser modificado por el [Error 1488740](https://bugzilla.mozilla.org/show_bug.cgi?id=1488740).
+- El servidor no respondió a la solicitud actual (incluso si respondió la [solicitud Preflight](/es/docs/Glossary/Preflight_peticion). Un escenario podría ser un servicio HTTP en desarrollo que "entró en pánico" sin devolver ningún dato.
 
-

-

+
 
-
Véase también

+## Véase también
 
-
+- [Errores CORS](/es/docs/Web/HTTP/CORS/Errors)
+- Glosario: {{Glossary("CORS")}}
+- [Introducción a CORS](/es/docs/Web/HTTP/CORS)
diff --git a/files/es/web/http/cors/index.md b/files/es/web/http/cors/index.md
index 2ece3b7581000a..474e6475840b6e 100644
--- a/files/es/web/http/cors/index.md
+++ b/files/es/web/http/cors/index.md
@@ -4,85 +4,78 @@ slug: Web/HTTP/CORS
 translation_of: Web/HTTP/CORS
 original_slug: Web/HTTP/Access_control_CORS
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
El Intercambio de Recursos de Origen Cruzado ({{Glossary("CORS")}}) es un mecanismo que utiliza cabeceras {{Glossary("HTTP")}} adicionales para permitir que un {{Glossary("user agent")}} 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ó.

+El Intercambio de Recursos de Origen Cruzado ({{Glossary("CORS")}}) es un mecanismo que utiliza cabeceras {{Glossary("HTTP")}} adicionales para permitir que un {{Glossary("user agent")}} 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ó.
 
-
Un ejemplo de solicitud de origen cruzado: el código JavaScript frontend de una aplicación web que es localizada en http://domain-a.com utiliza {{domxref("XMLHttpRequest")}} para cargar el recurso http://api.domain-b.com/data.json.

+Un ejemplo de solicitud de origen cruzado: el código JavaScript frontend de una aplicación web que es localizada en `http://domain-a.com` utiliza {{domxref("XMLHttpRequest")}} para cargar el recurso `http://api.domain-b.com/data.json`.
 
-
Por razones de seguridad, los exploradores restringen las solicitudes HTTP de origen cruzado iniciadas dentro de un script. Por ejemplo, XMLHttpRequest y la API Fetch siguen la política de mismo-origen. Ésto significa que una aplicación que utilice esas APIs XMLHttpRequest sólo puede hacer solicitudes HTTP a su propio dominio, a menos que se utilicen cabeceras CORS.

+Por razones de seguridad, los exploradores restringen las solicitudes HTTP de origen cruzado iniciadas dentro de un script. Por ejemplo, [XMLHttpRequest](/es/docs/Web/API/XMLHttpRequest) y la API [Fetch](/es/docs/Web/API/Fetch_API) siguen la [política de mismo-origen](/es/docs/Web/Security/Same-origin_policy). Ésto significa que una aplicación que utilice esas APIs [XMLHttpRequest](/es/docs/Web/API/XMLHttpRequest) sólo puede hacer solicitudes HTTP a su propio dominio, a menos que se utilicen cabeceras CORS.
 
-

+![](https://mdn.mozillademos.org/files/14295/CORS_principle.png)
 
-
El W3C Grupo de Trabajo de Aplicaciones Web recomienda el nuevo mecanismo de Intercambio de Recursos de Origen Cruzado (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  contenedor API (como XMLHttpRequest o Fetch) para ayudar a mitigar los riesgos de solicitudes HTTP de origen cruzado.

+El [W3C](http://www.w3.org/) [Grupo de Trabajo de Aplicaciones Web](http://www.w3.org/2008/webapps/) recomienda el nuevo mecanismo de [Intercambio de Recursos de Origen Cruzado](http://www.w3.org/TR/cors/) (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 **contenedor API** (como [XMLHttpRequest](/es/docs/Web/API/XMLHttpRequest) o [Fetch](/es/docs/Web/API/Fetch_API)) para ayudar a mitigar los riesgos de solicitudes HTTP de origen cruzado.
 
-
¿Quién debería leer este artículo?

+## ¿Quién debería leer este artículo?
 
-
Todo el mundo, de verdad.

+Todo el mundo, de verdad.
 
-
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 intercambio de origen cruzado desde una perspectiva de servidor (con fragmentos de código PHP).

+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 [intercambio de origen cruzado desde una perspectiva de servidor (con fragmentos de código PHP)](/es/docs/Web/HTTP/Server-Side_Access_Control).
 
-
¿Qué peticiones utiliza CORS?

+## ¿Qué peticiones utiliza CORS?
 
-
Este estándar de intercambio de origen cruzado es utilizado para habilitar solicitudes HTTP de sitios cruzados para:

+Este [estándar de intercambio de origen cruzado](http://www.w3.org/TR/cors/) es utilizado para habilitar solicitudes HTTP de sitios cruzados para:
 
-
+- Invocaciones de las APIs [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest") o [Fetch](/es/docs/Web/API/Fetch_API) en una manera de sitio cruzado, como se discutió arriba.
+- Fuentes Web (para usos de fuente en dominios cruzados `@font-face` dentro de CSS), [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.](https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements)
+- Texturas WebGL.
+- Imágenes dibujadas en patrones usando [`drawImage`](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage).
+- Hojas de estilo (para acceso [CSSOM](/es/docs/Web/CSS/CSSOM_View)).
+- Scripts (para excepciones inmutadas).
 
-
Este artículo es una discusión general sobre Intercambio de Recursos de Origin Cruzado e incluye una discusión sobre las cabeceras HTTP.

+Este artículo es una discusión general sobre Intercambio de Recursos de Origin Cruzado e incluye una discusión sobre las cabeceras HTTP.
 
-
Resumen

+## Resumen
 
-
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 GET, o para la utilización de POST 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 OPTIONS, 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.

+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 `GET`, o para la utilización de `POST` 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 `OPTIONS`, 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.
 
-
Las secciones siguientes discuten escenarios, así como el análisis de las cabeceras HTTP usados.

+Las secciones siguientes discuten escenarios, así como el análisis de las cabeceras HTTP usados.
 
-
Ejemplos de escenarios de control de accesos

+## Ejemplos de escenarios de control de accesos
 
-
Aquí, presentamos tres escenarios que ilustran cómo funciona el Intercambio de Recursos de Origen Cruzado. Todos estos ejemplos utilizan el objeto XMLHttpRequest, que puede ser utilizado para hacer invocaciones de sitios cruzados en cualquier explorador soportado.

+Aquí, presentamos tres escenarios que ilustran cómo funciona el Intercambio de Recursos de Origen Cruzado. Todos estos ejemplos utilizan el objeto [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest"), que puede ser utilizado para hacer invocaciones de sitios cruzados en cualquier explorador soportado.
 
-
Los fragmentos de JavaScript incluidos en estas secciones (y las instancias ejecutadas del código servidor que correctamente maneja las solicitudes de sitios cruzados) pueden ser encontrados "en acción" aquí, y pueden ser trabajados en exploradores que soportan XMLHttpRequest de sitios cruzados. Una discusión de Intercambio de Recursos de Origen Cruzado desde una perspectiva de servidor (incluyendo fragmentos de código PHP) puede ser encontrada aquí.

+Los fragmentos de JavaScript incluidos en estas secciones (y las instancias ejecutadas del código servidor que correctamente maneja las solicitudes de sitios cruzados) [pueden ser encontrados "en acción" aquí](http://arunranga.com/examples/access-control/), y pueden ser trabajados en exploradores que soportan [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest") de sitios cruzados. Una discusión de Intercambio de Recursos de Origen Cruzado desde una [perspectiva de servidor (incluyendo fragmentos de código PHP) puede ser encontrada aquí](/es/docs/Web/HTTP/Server-Side_Access_Control "En/Server-Side Access Control").
 
-
Solicitudes simples

+### Solicitudes simples
 
-
Una solicitud de sitio cruzado es aquella que cumple las siguientes condiciones:

+Una solicitud de sitio cruzado es aquella que cumple las siguientes condiciones:
 
-
    
- 
  • Los únicos métodos aceptados son:
-  
      
-   
    • GET
      • 
-   
    • HEAD
      • 
-   
    • POST.
      • 
-  
    
- 
    • 
- 
  • Aparte de las cabeceras establecidas automáticamente por el agente usuario (ej. Connection, User-Agent,etc.), las únicas cabeceras que están permitidas para establecer manualmente son:
-  
      
-   
    • Accept
      • 
-   
    • Accept-Language
      • 
-   
    • Content-Language
      • 
-   
    • Content-Type
      • 
-  
    
- 
    • 
- 
  • Los únicos valores permitidos de la cabecera Content-Type son:
-  
      
-   
    • application/x-www-form-urlencoded
      • 
-   
    • multipart/form-data
      • 
-   
    • text/plain
      • 
-  
    
- 
    • 
-

+- Los únicos métodos aceptados son:
 
-
Nota: 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.

+  - GET
+  - HEAD
+  - POST.
 
-
Por ejemplo, suponga que el contenido web en el dominio http://foo.example desea invocar contenido en el dominio http://bar.other. Código de este tipo puede ser utilizado dentro de JavaScript desplegado en foo.example:

+- Aparte de las cabeceras establecidas automáticamente por el agente usuario (ej. `Connection, User-Agent,`etc.), las únicas cabeceras que están permitidas para establecer manualmente son:
 
-
var invocation = new XMLHttpRequest();
+  - `Accept`
+  - `Accept-Language`
+  - `Content-Language`
+  - `Content-Type`
+
+- Los únicos valores permitidos de la cabecera `Content-Type` son:
+
+  - `application/x-www-form-urlencoded`
+  - `multipart/form-data`
+  - `text/plain`
+
+> **Nota:** 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.
+
+Por ejemplo, suponga que el contenido web en el dominio `http://foo.example` desea invocar contenido en el dominio `http://bar.other`. Código de este tipo puede ser utilizado dentro de JavaScript desplegado en foo.example:
+
+```js
+var invocation = new XMLHttpRequest();
 var url = 'http://bar.other/resources/public-data/';
 
 function callOtherDomain() {
@@ -92,11 +85,12 @@ function callOtherDomain() {
     invocation.send();
   }
 }
-

+```
 
-
Dejándonos ver lo que el explorador enviará al servidor en este caso, y veamos como responde el servidor:

+Dejándonos ver lo que el explorador enviará al servidor en este caso, y veamos como responde el servidor:
 
-
GET /resources/public-data/ HTTP/1.1
+```shell
+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
@@ -118,34 +112,31 @@ Transfer-Encoding: chunked
 Content-Type: application/xml
 
 [XML Data]
-

+```
 
-
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 Origin:  en la línea 10 de arriba, lo que muestra que la invocación proviene del contenido en el dominio http://foo.example.

+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 `Origin:` en la línea 10 de arriba, lo que muestra que la invocación proviene del contenido en el dominio `http://foo.example`.
 
-
Las líneas 13 - 22  muestran la respuesta HTTP del servidor en el dominio http://bar.other.  En respuesta, el servidor envía de vuelta una cabecera Access-Control-Allow-Origin:, mostrado arriba en la línea 16.  El uso de la cabecera Origin: y Access-Control-Allow-Origin: muestran el protocolo de control de acceso en su uso más simple.  En este caso, el servidor responde con un Access-Control-Allow-Origin: * lo que significa que el recurso puede ser accedido por cualquier dominio en una forma de sitio cruzado. Si el dueño del recurso en http://bar.other deseara restringir el acceso al recurso solamente para http://foo.example, debería devolver lo siguiente:

+Las líneas 13 - 22 muestran la respuesta HTTP del servidor en el dominio `http://bar.other`. En respuesta, el servidor envía de vuelta una cabecera `Access-Control-Allow-Origin:`, mostrado arriba en la línea 16. El uso de la cabecera `Origin:` y `Access-Control-Allow-Origin:` muestran el protocolo de control de acceso en su uso más simple. En este caso, el servidor responde con un `Access-Control-Allow-Origin: *` lo que significa que el recurso puede ser accedido por **cualquier** dominio en una forma de sitio cruzado. Si el dueño del recurso en `http://bar.other` deseara restringir el acceso al recurso solamente para `http://foo.example`, debería devolver lo siguiente:
 
-
Access-Control-Allow-Origin: http://foo.example

+`Access-Control-Allow-Origin: http://foo.example`
 
-
Note que ahora, ningún otro dominio aparte de http://foo.example (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 Origin.

+Note que ahora, ningún otro dominio aparte de `http://foo.example` (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 `Origin.`
 
-
Solicitudes Verificadas

+### Solicitudes Verificadas
 
-
A diferencia de las solicitudes simples (discutidas arriba), las solicitudes "verificadas" envían primero una solicitud HTTP por el método OPTIONS 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í:

+A diferencia de las solicitudes simples (discutidas arriba), las solicitudes "verificadas" envían primero una solicitud HTTP por el método `OPTIONS` 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í:
 
-
    
- 
  • Usa métodos distintos a GET, HEAD o POST.  También, si POST es utilizado para enviar solicitudes de información con Content-Type distinto a application/x-www-form-urlencoded, multipart/form-data, o text/plain, ej. si la solicitud POST envía una carga XML al servidor utilizando application/xml or text/xml, entonces la solicitud es verificada.
    • 
- 
  • Se establecen encabezados personalizados (ej. la solicitud usa un encabezado como X-PINGOTHER)
    • 
-

+- Usa métodos **distintos** a `GET, HEAD` `o POST`. También, si `POST` es utilizado para enviar solicitudes de información con Content-Type **distinto** a` application/x-www-form-urlencoded`, `multipart/form-data`, o `text/plain`, ej. si la solicitud `POST` envía una carga XML al servidor utilizando `application/xml` or `text/xml`, entonces la solicitud **es** verificada.
+- Se establecen encabezados personalizados (ej. la solicitud usa un encabezado como `X-PINGOTHER`)
 
-

-
Nota: Empezando en {{Gecko("2.0")}}, las codificaciones de datos text/plain, application/x-www-form-urlencoded, y multipart/form-data pueden ser enviadas en sitios cruzados sin verificación. Anteriormente, solo text/plain podía ser enviado sin verificación.

-

+> **Nota:** Empezando en {{Gecko("2.0")}}, las codificaciones de datos `text/plain`, `application/x-www-form-urlencoded`, y `multipart/form-data` pueden ser enviadas en sitios cruzados sin verificación. Anteriormente, solo` text/plain` podía ser enviado sin verificación.
 
-
Un ejemplo de este tipo de invocación puede ser:

+Un ejemplo de este tipo de invocación puede ser:
 
-
var invocation = new XMLHttpRequest();
+```js
+var invocation = new XMLHttpRequest();
 var url = 'http://bar.other/resources/post-here/';
-var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
+var body = 'Arun';
 
 function callOtherDomain(){
   if(invocation)
@@ -159,13 +150,14 @@ function callOtherDomain(){
 }
 
 ......
-

+```
 
-
En el ejemplo de arriba, la línea 3 crea un cuerpo XML para enviar con la solicitud POST en la línea 8.  También, en la línea 9, se establece una cabecera HTTP de solicitud "personalizado" (no estándar X-PINGOTHER: pingpong).  Dichas cabeceras no son parte del protocolo HTTP/1.1, pero son útiles generalmente en aplicaciones web. Dado que la solicitud (POST) usa un Content-Type application/xml, y dado que se establece una cabecera personalizada, la solicitud es verificada.

+En el ejemplo de arriba, la línea 3 crea un cuerpo XML para enviar con la solicitud `POST` en la línea 8. También, en la línea 9, se establece una cabecera HTTP de solicitud "personalizado" (no estándar `X-PINGOTHER: pingpong`). Dichas cabeceras no son parte del protocolo HTTP/1.1, pero son útiles generalmente en aplicaciones web. Dado que la solicitud (`POST`) usa un Content-Type `application/xml`, y dado que se establece una cabecera personalizada, la solicitud es verificada.
 
-
Veamos este intercambio completo entre un cliente y un servidor:

+Veamos este intercambio completo entre un cliente y un servidor:
 
-
OPTIONS /resources/post-here/ HTTP/1.1
+```shell
+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
@@ -208,7 +200,7 @@ Origin: http://foo.example
 Pragma: no-cache
 Cache-Control: no-cache
 
-<?xml version="1.0"?><person><name>Arun</name></person>
+Arun
 
 
 HTTP/1.1 200 OK
@@ -223,32 +215,36 @@ Connection: Keep-Alive
 Content-Type: text/plain
 
 [Some GZIP'd payload]
-

+```
 
-
Las líneas 1 - 12 arriba representan la solicitud verificada con los métodos OPTIONS. 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 idempotente, 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):

+Las líneas 1 - 12 arriba representan la solicitud verificada con los métodos `OPTIONS`. 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 **idempotente**, 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):
 
-
Access-Control-Request-Method: POST
+```
+Access-Control-Request-Method: POST
 Access-Control-Request-Headers: X-PINGOTHER
-

+```
 
-
La cabecera Access-Control-Request-Method 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 POST. La cabecera Access-Control-Request-Headers notifica al servidor que cuando la solicitud real sea enviada, será enviada con un encabezado X-PINGOTHER personalizado.  Ahora, el servidor tiene la oportunidad para determinar si desea aceptar la solicitud bajo estas circunstancias.

+La cabecera `Access-Control-Request-Method` 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 `POST`. La cabecera `Access-Control-Request-Headers` notifica al servidor que cuando la solicitud real sea enviada, será enviada con un encabezado `X-PINGOTHER` personalizado. Ahora, el servidor tiene la oportunidad para determinar si desea aceptar la solicitud bajo estas circunstancias.
 
-
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 X-PINGOTHER son aceptadas. En particular, echemos un vistazo a las líneas 18-21:

+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 `X-PINGOTHER` son aceptadas. En particular, echemos un vistazo a las líneas 18-21:
 
-
Access-Control-Allow-Origin: http://foo.example
+```
+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

+Access-Control-Max-Age: 1728000
+```
 
-
El servidor responde con Access-Control-Allow-Methods y dice que POST, GET, y OPTIONS son métodos viables para consultar el recurso en cuestión.  Observe que esta cabecera es similar al HTTP/1.1 Allow: encabezado de respuesta, pero usado estrictamente dentro del contexto del control de acceso.  El servidor también envía Access-Control-Allow-Headers con un valor de X-PINGOTHER, confirmando que es una cabecera permitida para ser usado en la solicitud real.  Como Access-Control-Allow-Methods, Access-Control-Allow-Headers es una lista separada por comas de cabeceras aceptables.  Finalmente, Access-Control-Max-Age 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.

+El servidor responde con `Access-Control-Allow-Methods` y dice que `POST`, `GET`, y `OPTIONS` son métodos viables para consultar el recurso en cuestión. Observe que esta cabecera es similar al [HTTP/1.1 Allow: encabezado de respuesta](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7), pero usado estrictamente dentro del contexto del control de acceso. El servidor también envía `Access-Control-Allow-Headers` con un valor de `X-PINGOTHER`, confirmando que es una cabecera permitida para ser usado en la solicitud real. Como `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers` es una lista separada por comas de cabeceras aceptables. Finalmente, `Access-Control-Max-Age` 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.
 
-
Solicitudes con credenciales

+### Solicitudes con credenciales
 
-
La capacidad más interesante expuesta tanto por XMLHttpRequest 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 XMLHttpRequest de un sitio curzado, los exploradores no enviarán credenciales. Una bandera específica tiene que ser establecida en el objeto XMLHttpRequest cuando este es invocado.

+La capacidad más interesante expuesta tanto por [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest") 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 [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest") de un sitio curzado, los exploradores no enviarán credenciales. Una bandera específica tiene que ser establecida en el objeto [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest") cuando este es invocado.
 
-
En este ejemplo, el contenido cargado originalmente desde http://foo.example hace una solicitud GET simple a un recurso en http://bar.other que establece Cookies. El contenido en foo.example puede contener un JavaScript como este:

+En este ejemplo, el contenido cargado originalmente desde `http://foo.example` hace una solicitud GET simple a un recurso en `http://bar.other` que establece Cookies. El contenido en foo.example puede contener un JavaScript como este:
 
-
var invocation = new XMLHttpRequest();
+```js
+var invocation = new XMLHttpRequest();
 var url = 'http://bar.other/resources/credentialed-content/';
 
 function callOtherDomain(){
@@ -258,13 +254,15 @@ function callOtherDomain(){
     invocation.onreadystatechange = handler;
     invocation.send();
   }
-}

+}
+```
 
-
La línea 7 muestra la bandera en XMLHttpRequest que tiene que ser establecida para poder hacer la invocación con Cookies, es decir, el valor booleano withCredentials.  Por defecto, la invocación es hecha sin Cookies. Dado que esta es una simple solicitud GET, no es verificada, pero el explorador rechazará cualquier respuesta que no tiene el encabezado Access-Control-Allow-Credentials: true,y no hará disponible la respuesta para invocar contenido web.

+La línea 7 muestra la bandera en [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest") que tiene que ser establecida para poder hacer la invocación con Cookies, es decir, el valor booleano `withCredentials`. Por defecto, la invocación es hecha sin Cookies. Dado que esta es una simple solicitud `GET`, no es verificada, pero el explorador **rechazará** cualquier respuesta que no tiene el encabezado `Access-Control-Allow-Credentials: true`,y **no** hará disponible la respuesta para invocar contenido web.
 
-
A continuación se proporciona una muestra de intercambio entre un cliente y un servidor:

+A continuación se proporciona una muestra de intercambio entre un cliente y un servidor:
 
-
GET /resources/access-control-with-credentials/ HTTP/1.1
+```shell
+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
@@ -295,145 +293,139 @@ Content-Type: text/plain
 
 
 [text/plain payload]
-

+```
 
-
Pese a que la línea 11 contiene la Cookie destinada para el contenido en http://bar.other, si bar.other no responde con Access-Control-Allow-Credentials: true (línea 19) la respuesta será ignorada y no puesta a disposición para el contenido web. Nota Importante: cuando se responde a una solicitud con credeciales, el servidor debe especificar un dominio, y no puede usar comodines. El ejemplo de arriba fallará si la cabecera fuera un comodín como: Access-Control-Allow-Origin: *.  Dado que Access-Control-Allow-Origin menciona explícitamente http://foo.example, el contenido de credenciales competente es devuelto al contenido web invocador. Observe que, en la línea 22, se establece una cookie adicional.

+Pese a que la línea 11 contiene la Cookie destinada para el contenido en `http://bar.other`, si bar.other no responde con `Access-Control-Allow-Credentials: true` (línea 19) la respuesta será ignorada y no puesta a disposición para el contenido web. **Nota Importante:** cuando se responde a una solicitud con credeciales, el servidor **debe\*\*** \*_especificar un dominio, y no puede usar comodines. El ejemplo de arriba fallará si la cabecera fuera un comodín como: `Access-Control-Allow-Origin: _`. Dado que `Access-Control-Allow-Origin`menciona explícitamente`http://foo.example`, el contenido de credenciales competente es devuelto al contenido web invocador. Observe que, en la línea 22, se establece una cookie adicional.
 
-
Todos estos ejemplos pueden verse funcionando aquí.  La siguiente sección se refiere a las verdaderas cabeceras HTTP.

+Todos estos ejemplos pueden [verse funcionando aquí](http://arunranga.com/examples/access-control/). La siguiente sección se refiere a las verdaderas cabeceras HTTP.
 
-
Las cabeceras HTTP de respuesta

+## Las cabeceras HTTP de respuesta
 
-
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.

+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.
 
-
Access-Control-Allow-Origin

+### Access-Control-Allow-Origin
 
-
Un recurso devuelto puede tener una cabecera Access-Control-Allow-Origin, con la siguiente sintaxis:

+Un recurso devuelto puede tener una cabecera `Access-Control-Allow-Origin`, con la siguiente sintaxis:
 
-
Access-Control-Allow-Origin: <origin> | *
-

+```
+Access-Control-Allow-Origin:  | *
+```
 
-
El parámetro origin específica una URI que puede tener acceso al recurso.  El explorador debe asegurar esto. Para solicitudes sin credenciales, el servidor debe especificar "*" como un comodín permitiendo, de este modo, el acceso al recurso a cualquier origen.

+El parámetro `origin` específica una URI que puede tener acceso al recurso. El explorador debe asegurar esto. Para solicitudes **sin** credenciales, el servidor debe especificar "\*" como un comodín permitiendo, de este modo, el acceso al recurso a cualquier origen.
 
-
Por ejemplo, para permitir a http://mozilla.com acceder al recurso, usted puede especificar:

+Por ejemplo, para permitir a http\://mozilla.com acceder al recurso, usted puede especificar:
 
-
Access-Control-Allow-Origin: http://mozilla.com

+```
+Access-Control-Allow-Origin: http://mozilla.com
+```
 
-
Si el servidor especifica un host de origen en vez de "*", entonces se debe incluir Origin en el encabezado de respuesta Vary para indicar a los clientes que las respuestas del servidor difieren basándose en el valor del encabezado de respuesta Origin.

+Si el servidor especifica un host de origen en vez de "\*", entonces se debe incluir Origin en el encabezado de respuesta Vary para indicar a los clientes que las respuestas del servidor difieren basándose en el valor del encabezado de respuesta Origin.
 
-
Access-Control-Expose-Headers

+### Access-Control-Expose-Headers
 
-
Esta cabecera permite una whitelist de cabeceras del servidor que los exploradores tienen permitido acceder. Por ejemplo:

+Esta cabecera permite una _whitelist_ de cabeceras del servidor que los exploradores tienen permitido acceder. Por ejemplo:
 
-
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
-

+```
+Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
+```
 
-
Esto permite a las cabeceras X-My-Custom-Header y X-Another-Custom-Header ser expuestos al explorador.

+Esto permite a las cabeceras `X-My-Custom-Header` y` X-Another-Custom-Header` ser expuestos al explorador.
 
-
Access-Control-Max-Age

+### Access-Control-Max-Age
 
-
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.

+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.
 
-
Access-Control-Max-Age: <delta-seconds>
-

+```
+Access-Control-Max-Age: 
+```
 
-
El parámetro delta-seconds indica el número de segundos en que los resultados pueden ser capturados.

+El parámetro `delta-seconds` indica el número de segundos en que los resultados pueden ser capturados.
 
-
Access-Control-Allow-Credentials

+### Access-Control-Allow-Credentials
 
-
Indica si la respuesta puede ser expuesta cuando la bandera credentials 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 GET 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.

+Indica si la respuesta puede ser expuesta cuando la bandera `credentials` 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 `GET` 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.
 
-
Access-Control-Allow-Credentials: true | false
-

+```
+Access-Control-Allow-Credentials: true | false
+```
 
-
Las Solicitudes con credenciales son discutidas arriba.

+[Las Solicitudes con credenciales](/En/HTTP_access_control#Requests_with_credentials "En/HTTP access control#Requests with credentials") son discutidas arriba.
 
-
Access-Control-Allow-Methods

+### Access-Control-Allow-Methods
 
-
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.

+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.
 
-
Access-Control-Allow-Methods: <method>[, <method>]*
-

+```
+Access-Control-Allow-Methods: [, ]*
+```
 
-
Un ejemplo de una solicitud verificada se muestra arriba, incluyendo un ejemplo donde se envía este encabezado al explorador.

+Un ejemplo de una [solicitud verificada se muestra arriba](#Preflighted_requests "#Preflight Request"), incluyendo un ejemplo donde se envía este encabezado al explorador.
 
-
Access-Control-Allow-Headers

+### Access-Control-Allow-Headers
 
-
Usado en respuesta a una solicitud verificada para indicar qué encabezado HTTP puede ser usado cuando se realiza la solicitud real.

+Usado en respuesta a una [solicitud verificada](#Preflighted_requests "#Preflighted Request") para indicar qué encabezado HTTP puede ser usado cuando se realiza la solicitud real.
 
-
Access-Control-Allow-Headers: <field-name>[, <field-name>]*
-

+```
+Access-Control-Allow-Headers: [, ]*
+```
 
-
Los encabezados HTTP de solicitud

+## Los encabezados HTTP de solicitud
 
-
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 XMLHttpRequest para no tener que establecer ninguna solicitud de intercambio de origen cruzado programada.

+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 [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "En/XMLHttpRequest") para no tener que establecer ninguna solicitud de intercambio de origen cruzado programada.
 
-
Origin

+### Origin
 
-
Indica el origen de las solicitudes de acceso a sitios cruzados o solicitudes verificadas.

+Indica el origen de las solicitudes de acceso a sitios cruzados o solicitudes verificadas.
 
-
Origin: <origin>
-

+```
+Origin: 
+```
 
-
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. 

+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.
 
-
Nota: El origin puede ser un string vacío; esto es útil, por ejemplo, si el recurso es un data URL.

+> **Nota:** El `origin` puede ser un string vacío; esto es útil, por ejemplo, si el recurso es un `data` URL.
 
-
Observe que en cualquier solicitud de acceso de control, la cabecera ORIGIN siempre se envía.

+Observe que en cualquier solicitud de acceso de control, la cabecera `ORIGIN` **siempre** se envía.
 
-
Access-Control-Request-Method

+### Access-Control-Request-Method
 
-
Se usa cuando se emite una solicitud verificada, para indicarle al servidor qué método HTTP será usado cuando se haga la solicitud real.

+Se usa cuando se emite una solicitud verificada, para indicarle al servidor qué método HTTP será usado cuando se haga la solicitud real.
 
-
Access-Control-Request-Method: <method>
-

+```
+Access-Control-Request-Method: 
+```
 
-
Ejemplos de esta utilización pueden ser encontrados arriba.

+Ejemplos de esta utilización pueden ser encontrados [arriba.](#Preflighted_requests "Preflighted requests")
 
-
Access-Control-Request-Headers

+### Access-Control-Request-Headers
 
-
Usada cuando se emite una solicitud verificada para indicarle al servidor qué cabecera HTTP será usada cuando se haga la solicitud real.

+Usada cuando se emite una solicitud verificada para indicarle al servidor qué cabecera HTTP será usada cuando se haga la solicitud real.
 
-
Access-Control-Request-Headers: <field-name>[, <field-name>]*
-

+```
+Access-Control-Request-Headers: [, ]*
+```
 
-
Ejemplos de esta utilización pueden ser encontrados arriba.

+Ejemplos de esta utilización pueden ser encontrados [arriba](/En/HTTP_access_control#Preflighted_requests "En/HTTP access control#Preflighted requests").
 
-
Especificaciones

+## Especificaciones
 
-
- 
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
- 
-
EspecificaciónEstadoComentario
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}{{Spec2('Fetch')}}Nueva definición; tiene como objetivo suplantar la especificación CORS.
{{SpecName('CORS')}}{{Spec2('CORS')}}Definición inicial.

+| Especificación                                                   | Estado                   | Comentario                                                              |
+| ---------------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------- |
+| {{SpecName('Fetch', '#cors-protocol', 'CORS')}} | {{Spec2('Fetch')}} | Nueva definición; tiene como objetivo suplantar la especificación CORS. |
+| {{SpecName('CORS')}}                                     | {{Spec2('CORS')}} | Definición inicial.                                                     |
 
-
Compatibilidad con Exploradores

+## Compatibilidad con Exploradores
 
 {{Compat("http.headers.Access-Control-Allow-Origin")}}
 
-
Vea también

+## Vea también
 
-
+- [Muestras de Código mostrando `XMLHttpRequest` e Intercambio de Recursos de Origen Cruzado](http://arunranga.com/examples/access-control/)
+- [Intercambio de Recursos de Origen Cruzado desde una perspectiva de Servidor (PHP, etc.)](/es/docs/Web/HTTP/Server-Side_Access_Control)
+- [Especificación del Intercambio de Recursos de Origen Cruzado](http://www.w3.org/TR/cors/)
+- [`XMLHttpRequest`](/en/DOM/XMLHttpRequest "en/XMLHttpRequest")
+- [Discusión adicional sobre el encabezado Origin](http://crypto.stanford.edu/websec/specs/origin-header/)
+- [Usando CORS con todos los exploradores (modernos).](http://www.kendoui.com/blogs/teamblog/posts/11-10-03/using_cors_with_all_modern_browsers.aspx)
+- [Usando CORS - HTML5 Rocks](http://www.html5rocks.com/en/tutorials/cors/)
 
-
{{ languages( { "ja": "ja/HTTP_access_control" } ) }}

+{{ languages( { "ja": "ja/HTTP\_access\_control" } ) }}
diff --git a/files/es/web/http/csp/index.md b/files/es/web/http/csp/index.md
index 05a8a8948978fc..dba3c549c63c0f 100644
--- a/files/es/web/http/csp/index.md
+++ b/files/es/web/http/csp/index.md
@@ -5,162 +5,177 @@ tags:
   - Política de Seguridad del Contenido
 translation_of: Web/HTTP/CSP
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
Política de Seguridad del Contenido o ( {{Glossary("CSP")}} ) - del inglés Content Security Policy - 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 .

+**Política de Seguridad del Contenido** o\*\* **( {{Glossary("CSP")}} ) - del inglés \_**Content Security Policy\*\*\_ - 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 .
 
-
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 aquí 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 mismo-origen.

+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 [aquí](https://www.w3.org/TR/CSP2) 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 [mismo-origen](/es/docs/Web/Security/Same-origin_policy "En/Same origin policy for JavaScript").
 
-
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 X-Content-Security-Policy, pero se trata de una versión antigua y no necesitas especificarla más).

+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 `X-Content-Security-Policy`, pero se trata de una versión antigua y no necesitas especificarla más).
 
-
Alternativamente, el elemento {{HTMLElement("meta")}} puede ser usado para configurar una política, por ejemplo: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

+Alternativamente, el elemento {{HTMLElement("meta")}} puede ser usado para configurar una política, por ejemplo: ``
 
-
Amenazas

+## Amenazas
 
-
Mitigando el cross site scripting

+### Mitigando el cross site scripting
 
-
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.

+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.
 
-
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).

+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).
 
-
Como medida extrema de protección, los sitios que nunca requieran ejecutar scripts, pueden optar por rechazar globalmente la ejecución de scripts.

+Como medida extrema de protección, los sitios que nunca requieran ejecutar scripts, pueden optar por rechazar globalmente la ejecución de scripts.
 
-
Mitigando los ataques de análisis de paquetes (packet sniffing attacks)

+### Mitigando los ataques de análisis de paquetes _(packet sniffing attacks)_
 
-
Además de restringir los dominios desde los cuales se puede cargar el contenido, el servidor puede especificar qué protocolos se pueden usar; por ejemplo (e idealmente, desde un punto de vista de seguridad), un servidor puede especificar que todo el contenido debe cargarse utilizando HTTPS. 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. 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.

+Además de restringir los dominios desde los cuales se puede cargar el contenido, el servidor puede especificar qué protocolos se pueden usar; por ejemplo (e idealmente, desde un punto de vista de seguridad), un servidor puede especificar que todo el contenido debe cargarse utilizando HTTPS. 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. 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.
 
-
Utilizando CSP

+## Utilizando CSP
 
-
La configuración de la Política de Seguridad del Contenido (CSP), consiste en agregar a una página web la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}}, y darle valores para controlar los recursos que el agente de usuario puede cargar para esa página. 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. Una Política de Seguridad de Contenido adecuadamente diseñada ayuda a proteger una página contra un ataque de scripts entre sitios. Este artículo explica cómo construir dichas cabeceras correctamente y proporciona ejemplos.

+La configuración de la Política de Seguridad del Contenido (CSP), consiste en agregar a una página web la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}}, y darle valores para controlar los recursos que el agente de usuario puede cargar para esa página. 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. Una Política de Seguridad de Contenido adecuadamente diseñada ayuda a proteger una página contra un ataque de scripts entre sitios. Este artículo explica cómo construir dichas cabeceras correctamente y proporciona ejemplos.
 
-
Especificando una política

+### Especificando una política
 
-
Para especificar una política, se puede utilizar la cabecera HTTP      {{HTTPHeader("Content-Security-Policy")}}  de la siguiente manera:

+Para especificar una política, se puede utilizar la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}} de la siguiente manera:
 
-
Content-Security-Policy: política

+```
+Content-Security-Policy: política
+```
 
-
La política es una cadena de caracteres que contiene las directivas que describen una determinada Política de Seguridad de Contenido.

+La _política_ es una cadena de caracteres que contiene las directivas que describen una determinada Política de Seguridad de Contenido.
 
-
Describiendo una política

+### Describiendo una política
 
-
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. 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 {{CSP("default-src")}} ). 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 eval(). 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")}}} o un atributo style.

+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. 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 {{CSP("default-src")}} ). 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 `eval()`. 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")}}} o un atributo `style`.
 
-
Ejemplos: Casos de usos frecuentes

+## Ejemplos: Casos de usos frecuentes
 
-
Esta sección proporciona ejemplos de algunos escenarios frecuentes de políticas de seguridad.

+Esta sección proporciona ejemplos de algunos escenarios frecuentes de políticas de seguridad.
 
-
Ejemplo 1

+### Ejemplo 1
 
-
Un administrador del sitio web desea que todo el contenido provenga del mismo origen que el del sitio (esto excluye subdominios).

+Un administrador del sitio web desea que todo el contenido provenga del mismo origen que el del sitio (esto excluye subdominios).
 
-
Content-Security-Policy: default-src 'self'

+```
+Content-Security-Policy: default-src 'self'
+```
 
-
Ejemplo 2

+### Ejemplo 2
 
-
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).

+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).
 
-
Content-Security-Policy: default-src 'self' *.trusted.com

+```
+Content-Security-Policy: default-src 'self' *.trusted.com
+```
 
-
Ejemplo 3

+### Ejemplo 3
 
-
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.

+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.
 
-
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

+```
+Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
+```
 
-
Aquí, de forma predeterminada, el contenido solo se permite desde el origen del documento, con las siguientes excepciones:

+Aquí, de forma predeterminada, el contenido solo se permite desde el origen del documento, con las siguientes excepciones:
 
-
    
- 
  • Las imágenes pueden cargarse desde cualquier lugar (tenga en cuenta el comodín "*").
    • 
- 
  • Los archivos de medios solo están permitidos desde media1.com y media2.com (y no desde los subdominios de esos sitios).     
    • 
- 
  • El script ejecutable solo está permitido desde userscripts.example.com.
    • 
-

+- Las imágenes pueden cargarse desde cualquier lugar (tenga en cuenta el comodín "\*").
+- Los archivos de medios solo están permitidos desde media1.com y media2.com (y no desde los subdominios de esos sitios).
+- El script ejecutable solo está permitido desde userscripts.example.com.
 
-
Ejemplo 4

+### Ejemplo 4
 
-
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.

+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.
 
-
Content-Security-Policy: default-src https://onlinebanking.jumbobank.com

+```
+Content-Security-Policy: default-src https://onlinebanking.jumbobank.com
+```
 
-
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.

+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.
 
-
Ejemplo 5

+### Ejemplo 5
 
-
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.

+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.
 
-
Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *

+```
+Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *
+```
 
-
Tenga en cuenta que este ejemplo no especifica un {{CSP ("script-src")}} ; 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.

+Tenga en cuenta que este ejemplo no especifica un {{CSP ("script-src")}} ; 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.
 
-
Comprobando una política

+## Comprobando una política
 
-
Para facilitar la implementación, CSP se puede implementar en modo de solo informe. La política no se aplica, pero cualquier violación se informa a un URI proporcionado. Además, se puede usar una cabecera de solo informe para probar una futura revisión de una política sin implementarla realmente.

- 

- Se puede usar la cabecera HTTP {{HTTPHeader ("Content-Security-Policy-Report-Only")}} para especificar una política de la siguiente manera:

+Para facilitar la implementación, CSP se puede implementar en modo de solo informe. La política no se aplica, pero cualquier violación se informa a un URI proporcionado. Además, se puede usar una cabecera de solo informe para probar una futura revisión de una política sin implementarla realmente.
 
-
Content-Security-Policy-Report-Only: policy 

+Se puede usar la cabecera HTTP {{HTTPHeader ("Content-Security-Policy-Report-Only")}} para especificar una política de la siguiente manera:
 
-
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. La política especificada en la cabecera Content-Security-Policy se aplica, mientras que la política Content-Security-Policy-Report-Only genera informes pero no se aplica.

+```
+Content-Security-Policy-Report-Only: policy
+```
 
-
Habilitación de informes

+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. La política especificada en la cabecera `Content-Security-Policy` se aplica, mientras que la política `Content-Security-Policy-Report-Only` genera informes pero no se aplica.
 
-
Por defecto, los informes de violación no son enviados. 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:

+## Habilitación de informes
 
-
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

+Por defecto, los informes de violación no son enviados. 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:
 
-
Luego se debe configurar el servidor para recibir los informes; se pueden almacenar o procesar de la manera que considere apropiada.

+```
+Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
+```
 
-
Sintáxis del informe de violación

+Luego se debe configurar el servidor para recibir los informes; se pueden almacenar o procesar de la manera que considere apropiada.
 
-
El informe es un objeto JSON que contiene los datos siguientes:

+## Sintáxis del informe de violación
 
-

- 
blocked-uri

- 
El URI del recurso bloqueado por la Política de Seguridad de Contenido. Si el URI bloqueado es de un origen diferente al del document-uri, el URI bloqueado se trunca para contener solo el esquema, el host y el puerto.

-

+El informe es un objeto JSON que contiene los datos siguientes:
 
-

- 
disposition

- 
Toma el valor "enforce" o "reporting" dependiendo de si se utiliza la cabecera {{HTTPHeader("Content-Security-Policy-Report-Only")}} o Content-Security-Policy.

- 
document-uri

- 
El URI del documento donde ocurrió la violación.

- 
effective-directive

- 
La directiva cuya aplicación causó la violación.

- 
original-policy

- 
La política original especificada por la cabecera HTTP Content-Security-Policy.

- 
referrer

- 
El referente del documento en el que ocurrió la violación.

- 
script-sample

- 
Los primeros 40 caracteres del script inline, el controlador de eventos o el estilo que causó la violación.

- 
status-code

- 
El código de estado HTTP del recurso en el que se creó una instancia del objeto global.

- 
violated-directive

- 
El nombre de la sección de política que fue violada.

-

+- `blocked-uri`
+  - : El URI del recurso bloqueado por la Política de Seguridad de Contenido. Si el URI bloqueado es de un origen diferente al del **document-uri**, el URI bloqueado se trunca para contener solo el esquema, el host y el puerto.
 
-
Ejemplo de informe de violación

+
 
-
Consideremos una página ubicada en http://example.com/signup.html que tiene las siguiente política: rechazar todo, excepto las hojas de estilo provenientes de cdn.example.com.

+- `disposition`
+  - : Toma el valor `"enforce"` o `"reporting"` dependiendo de si se utiliza la cabecera {{HTTPHeader("Content-Security-Policy-Report-Only")}} o `Content-Security-Policy`.
+- `document-uri`
+  - : El URI del documento donde ocurrió la violación.
+- `effective-directive`
+  - : La directiva cuya aplicación causó la violación.
+- `original-policy`
+  - : La política original especificada por la cabecera HTTP `Content-Security-Policy`.
+- `referrer`
+  - : El referente del documento en el que ocurrió la violación.
+- `script-sample`
+  - : Los primeros 40 caracteres del script inline, el controlador de eventos o el estilo que causó la violación.
+- `status-code`
+  - : El código de estado HTTP del recurso en el que se creó una instancia del objeto global.
+- `violated-directive`
+  - : El nombre de la sección de política que fue violada.
 
-

-
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports

-

+## Ejemplo de informe de violación
 
-
El código HTML de signup.html es el siguiente:

+Consideremos una página ubicada en [`http://example.com/signup.html`](http://example.com/signup.html) que tiene las siguiente política: rechazar todo, excepto las hojas de estilo provenientes de `cdn.example.com`.
 
-
<!DOCTYPE html>
-<html>
-  <head>
-    <title>Sign Up</title>
-    <link rel="stylesheet" href="css/style.css">
-  </head>
-  <body>
+```
+Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+```
+
+El código HTML de `signup.html` es el siguiente:
+
+```html
+
+
+  
+    Sign Up
+    
+  
+  
     ... Content ...
-  </body>
-</html>

+  
+
+```
 
-
¿Puedes ver el error? Las hojas de estilo solo se pueden cargar desde cdn.example.com, pero el sitio web intenta cargar una desde su propio origen (http://example.com). Un navegador capaz de aplicar el CSP enviará el siguiente informe de violación mediante una solicitud POST a http://example.com/_/csp-reports, cuando se visite el documento:

+¿Puedes ver el error? Las hojas de estilo solo se pueden cargar desde `cdn.example.com`, pero el sitio web intenta cargar una desde su propio origen (`http://example.com`). Un navegador capaz de aplicar el CSP enviará el siguiente informe de violación mediante una solicitud POST a [`http://example.com/_/csp-reports`](http://example.com/_/csp-reports), cuando se visite el documento:
 
-
{
+```
+{
   "csp-report": {
     "document-uri": "http://example.com/signup.html",
     "referrer": "",
@@ -168,25 +183,20 @@ translation_of: Web/HTTP/CSP
     "violated-directive": "style-src cdn.example.com",
     "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
   }
-}

-
-
Como se puede ver, el informe incluye la ruta completa al recurso infractor en blocked-uri. Este no es siempre el caso. Por ejemplo, cuando signup.html intente cargar el CSS desde http://anothercdn.example.com/stylesheet.css, el navegador no incluiría la ruta completa, sino solo el origen (http://anothercdn.example.com ). La especificación CSP da una explicación de este extraño comportamiento. En resumen, esto se hace para evitar la pérdida de información confidencial sobre recursos de origen cruzado.

-
-
Compatibilidad del navegador

+}
+```
 
+Como se puede ver, el informe incluye la ruta completa al recurso infractor en `blocked-uri`. Este no es siempre el caso. Por ejemplo, cuando `signup.html` intente cargar el CSS desde [`http://anothercdn.example.com/stylesheet.css`](http://anothercdn.example.com/stylesheet.css), el navegador no incluiría la ruta completa, sino solo el origen (`http://anothercdn.example.com` ). La especificación CSP da una explicación de este extraño comportamiento. En resumen, esto se hace para evitar la pérdida de información confidencial sobre recursos de origen cruzado.
 
+## Compatibilidad del navegador
 
-
{{Compat("http.headers.csp")}}

+{{Compat("http.headers.csp")}}
 
-
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 debido a que la Política de Seguridad del Contenido no permite el contenido.

+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 debido a que la Política de Seguridad del Contenido no permite el contenido.
 
-
Vea también

+## Vea también
 
-
+- {{HTTPHeader("Content-Security-Policy")}}
+- {{HTTPHeader("Content-Security-Policy-Report-Only")}}
+- [Content Security in WebExtensions](/es/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy)
+- [Display security and privacy policies In Firefox Developer Tools](/es/docs/Tools/GCLI/Display_security_and_privacy_policies)
diff --git a/files/es/web/http/headers/accept/index.md b/files/es/web/http/headers/accept/index.md
index 8dabe830bcbd5d..aea674a11c63f9 100644
--- a/files/es/web/http/headers/accept/index.md
+++ b/files/es/web/http/headers/accept/index.md
@@ -8,92 +8,82 @@ tags:
   - Referencia
 translation_of: Web/HTTP/Headers/Accept
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
La cabecera de pedido Accept anuncia que tipo de contenido el cliente puede procesar, expresado como un tipo MIME. Usando negociación de contenido, 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")}} .

+`La cabecera de pedido Accept` anuncia que tipo de contenido el cliente puede procesar, expresado como un tipo [MIME](/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types). Usando [negociación de contenido](/es/docs/Web/HTTP/Content_negotiation), 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")}} .
 
-
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.

+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.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
Tipo de Cabecera{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple header", "CORS-safelisted request-header")}}si
Tipo de Cabecera{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no

+        {{Glossary("Simple header", "CORS-safelisted request-header")}}
+      si

 

 
-
Sintaxis

+## Sintaxis
 
-
Accept: <MIME_type>/<MIME_subtype>
-Accept: <MIME_type>/*
+```
+Accept: /
+Accept: /*
 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

-
-
Directivas

-
-

- 
<MIME_type>/<MIME_subtype>

- 
Un único y preciso tipo MIME, como text/html.

- 
<MIME_type>/*

- 
Un tipo MIME, pero con cualquier subtipo.
- Por ejmplo, image/* comincide con:
- 
    
-  
  • image/png
    • 
-  
  • image/svg
    • 
-  
  • image/gif 
    • 
- 

- 

- 
*/*

- 
Culaquier tipo MIME

- 
;q= (donde q es la importancia o peso)

- 
Culaquier valor es colocado en orden de preferencia, expresada usando un valor de calidad llamado weight (peso en español).

-

-
-
Ejemplos

-
-
Accept: text/html
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+```
+
+## Directivas
+
+- `/`
+  - : Un único y preciso tipo [MIME](/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types), como `text/html`.
+- `/*`
+
+  - : Un tipo MIME, pero con cualquier subtipo.
+    Por ejmplo, image/\* comincide con:
+
+    - image/png
+    - image/svg
+    - image/gif
+
+- `*/*`
+  - : Culaquier tipo MIME
+- `;q=` (donde _q_ es la importancia o peso)
+  - : Culaquier valor es colocado en orden de preferencia, expresada usando un [valor de calidad](/es/docs/Glossary/Quality_values) llamado _weight_ (_peso_ en español).
+
+## Ejemplos
+
+```
+Accept: text/html
 
 Accept: image/*
 
 Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
-

-
-
Especificaciones

-
-
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
-
EspecificaciónTitulo
{{RFC("7231", "Accept", "5.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context

+```
 
-
Compatibilidad con Navegadores

+## Especificaciones
 
+| Especificación                               | Titulo                                                        |
+| -------------------------------------------- | ------------------------------------------------------------- |
+| {{RFC("7231", "Accept", "5.3.2")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |
 
+## Compatibilidad con Navegadores
 
-
{{Compat("http.headers.Accept")}}

+{{Compat("http.headers.Accept")}}
 
-
Tambien Ver

+## Tambien Ver
 
-
    
- 
  • Negociación de Contenido HTTP
    • 
- 
  • Cabecera con el resultado de la negociación de contenido: {{HTTPHeader("Content-Type")}}
    • 
- 
  • Otras cabeceras similares: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}
    • 
-

+- [Negociación de Contenido HTTP](/es/docs/Web/HTTP/Content_negotiation)
+- Cabecera con el resultado de la negociación de contenido: {{HTTPHeader("Content-Type")}}
+- Otras cabeceras similares: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}
diff --git a/files/es/web/http/headers/access-control-allow-origin/index.md b/files/es/web/http/headers/access-control-allow-origin/index.md
index cf065a4d196b4a..4bbce6d7422bd3 100644
--- a/files/es/web/http/headers/access-control-allow-origin/index.md
+++ b/files/es/web/http/headers/access-control-allow-origin/index.md
@@ -14,85 +14,79 @@ tags:
   - error cross-origin
 translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-
El encabezado de respuesta Access-Control-Allow-Origin indica si los recursos de la respuesta pueden ser compartidos con el {{glossary("origin", "origen")}} dado.

+El encabezado de respuesta **`Access-Control-Allow-Origin`** indica si los recursos de la respuesta pueden ser compartidos con el {{glossary("origin", "origen")}} dado.
 
 
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
Tipo de encabezado{{Glossary("Response header", "Encabezado de respuesta")}}
{{Glossary("Forbidden header name", "Nombre de encabezado prohibido")}}no
Tipo de encabezado
+        {{Glossary("Response header", "Encabezado de respuesta")}}
+      

+        {{Glossary("Forbidden header name", "Nombre de encabezado prohibido")}}
+      no

 

 
-
Sintaxis

+## Sintaxis
 
-
Access-Control-Allow-Origin: *
-Access-Control-Allow-Origin: <origen>
+```
+Access-Control-Allow-Origin: *
+Access-Control-Allow-Origin: 
 Access-Control-Allow-Origin: null
-

+```
 
-
Directivas

+## Directivas
 
-

- 
*

- 
Para las peticiones sin credenciales, 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 "anonymous". Intentar usar el comodín con credenciales resultará en un error.

- 
<origen>

- 
Especifica que origen puede acceder al recurso. Sólo se puede especificar un origen.

-

+- `*`
+  - : Para las peticiones _sin credenciales_, 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 `"anonymous"`. Intentar usar el comodín con credenciales [resultará en un error](/es/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials).
+- ``
+  - : Especifica que origen puede acceder al recurso. Sólo se puede especificar un origen.
 
-
Ejemplos

+## Ejemplos
 
-
Para permitir a cualquier origen el acceso a tus recursos, puedes especificar:

+Para permitir a cualquier origen el acceso a tus recursos, puedes especificar:
 
-
Access-Control-Allow-Origin: *

+```
+Access-Control-Allow-Origin: *
+```
 
-
Una respuesta que le dice al navegador que permita la petición de código del origen https://developer.mozilla.org para acceder a los recursos que incluyan lo siguiente:

+Una respuesta que le dice al navegador que permita la petición de código del origen `https://developer.mozilla.org` para acceder a los recursos que incluyan lo siguiente:
 
-
Access-Control-Allow-Origin: https://developer.mozilla.org

+```
+Access-Control-Allow-Origin: https://developer.mozilla.org
+```
 
-
Limitando los posibles valores Access-Control-Allow-Origin 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 Access-Control-Allow-Origin al mismo valor que {{HTTPHeader("Origin")}}.

+Limitando los posibles valores `Access-Control-Allow-Origin` 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 `Access-Control-Allow-Origin` al mismo valor que {{HTTPHeader("Origin")}}.
 
-
CORS y caché

+### CORS y caché
 
-
Si el servidor envía una respuesta con un valor Access-Control-Allow-Origin que es un origen explícito (en lugar del comodín "*"), entonces a respuesta debería incluir también el encabezado de respuesta {{HTTPHeader("Vary")}} con el valor origin - para indicar a los navegadores que las respuestas del servidor pueden diferir basadas en el valor del encabezado de respueta Origin.

+Si el servidor envía una respuesta con un valor `Access-Control-Allow-Origin` que es un origen explícito (en lugar del comodín "`*`"), entonces a respuesta debería incluir también el encabezado de respuesta {{HTTPHeader("Vary")}} con el valor `origin` - para indicar a los navegadores que las respuestas del servidor pueden diferir basadas en el valor del encabezado de respueta `Origin`.
 
-
Access-Control-Allow-Origin: https://developer.mozilla.org
-Vary: Origin

+```
+Access-Control-Allow-Origin: https://developer.mozilla.org
+Vary: Origin
+```
 
-
Especificaciones

-
-
- 
-  
-   
-   
-   
-  
-  
-   
-   
-   
-  
- 
-
EspecificaciónEstadoComentario
{{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}}{{Spec2("Fetch")}}Definición Inicial.

-
-
Compatibilidad del Navegador

+## Especificaciones
 
+| Especificación                                                                                                       | Estado                   | Comentario          |
+| -------------------------------------------------------------------------------------------------------------------- | ------------------------ | ------------------- |
+| {{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}} | {{Spec2("Fetch")}} | Definición Inicial. |
 
+## Compatibilidad del Navegador
 
-
{{Compat("http.headers.Access-Control-Allow-Origin")}}

+{{Compat("http.headers.Access-Control-Allow-Origin")}}
 
-
Veáse también

+## Veáse también
 
-
+- {{HTTPHeader("Origin")}}
+- {{HTTPHeader("Vary")}}
+- [Cross-Origin Resource Sharing (CORS)](/es/docs/Web/HTTP/CORS)
diff --git a/files/es/web/http/headers/content-security-policy/index.md b/files/es/web/http/headers/content-security-policy/index.md
index 3c06a8770524ad..77f28e578cb72e 100644
--- a/files/es/web/http/headers/content-security-policy/index.md
+++ b/files/es/web/http/headers/content-security-policy/index.md
@@ -8,239 +8,199 @@ tags:
   - header
 translation_of: Web/HTTP/Headers/Content-Security-Policy
 ---
-
{{HTTPSidebar}}

+{{HTTPSidebar}}
 
-

+La cabecera HTTP **`Content-Security-Policy `**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")}}).
 
-


- La cabecera HTTP Content-Security-Policy  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")}}).

+Para mas información, ve también este articulo en [Content Security Policy (CSP)](/es/docs/Web/HTTP/CSP).
 
-
Para mas información, ve también este articulo en Content Security Policy (CSP).

+
+  
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
Tipo de cabecera{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no

 
+## Sintaxis
 
+```
+Content-Security-Policy: ; 
+```
 
-
- 
-  
-   
-   
-  
-  
-   
-   
-  
- 
-
Tipo de cabecera{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no

+## Directivas
+
+### {{Glossary("Fetch directive", "Fetch directives")}}
+
+"Fetch directives" controla la ubicación o ubicaciones desde la cual se pueden cargar ciertos tipos de recursos
+
+#### Lista de Content Security Policy Fetch directives
+
+- {{CSP("child-src")}}
+
+  - : Define los origenes válidos para [web workers](/es/docs/Web/API/Web_Workers_API) y contextos de navegación anidados cargados usando elementos como {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}.
+
+    > **Advertencia:** En lugar de **`child-src`**, 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.
+
+- {{CSP("connect-src")}}
+  - : Restringe las URLs que pueden ser cargados usando scripts.
+- {{CSP("default-src")}}
+  - : Serves as a fallback for the other {{Glossary("Fetch directive", "fetch directives")}}.
+- {{CSP("font-src")}}
+  - : Especifica origenes válidos para las fuentes cargadas usando {{cssxref("@font-face")}}.
+- {{CSP("frame-src")}}
+  - : Especifica origenes válidos para contextos de navageción anidada cargados usando elementos como {{HTMLElement("frame")}} y {{HTMLElement("iframe")}}.
+- {{CSP("img-src")}}
+  - : Especifica origenes válidos de imágenes y favicons.
+- {{CSP("manifest-src")}}
+  - : Especifica origenes válidos de archivos de manifiesto de una aplicación.
+- {{CSP("media-src")}}
+  - : Especifica origenes válidos para carga de archivos usando elementos como {{HTMLElement("audio")}} , {{HTMLElement("video")}} y {{HTMLElement("track")}}.
+- {{CSP("object-src")}}
+  - : Specifies valid sources for the {{HTMLElement("object")}}, {{HTMLElement("embed")}}, and {{HTMLElement("applet")}} elements.
+    Elements controlled by `object-src` are perhaps coincidentally considered legacy HTML elements and aren't recieving new standardized features (such as the security attributes `sandbox` or `allow` for `