From a55b575e8089ee6cab7c5c262a7e6db55d0e34d6 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:46:50 +0100 Subject: unslug es: move --- files/es/web/http/access_control_cors/index.html | 491 --------------------- .../web/http/basics_of_http/data_uris/index.html | 168 +++++++ .../web/http/basics_of_http/datos_uris/index.html | 168 ------- .../index.html" | 169 ------- .../identifying_resources_on_the_web/index.html | 169 +++++++ files/es/web/http/conditional_requests/index.html | 148 +++++++ .../connection_management_in_http_1.x/index.html | 86 ++++ files/es/web/http/cors/index.html | 491 +++++++++++++++++++++ .../gestion_de_la_conexion_en_http_1.x/index.html | 86 ---- files/es/web/http/headers/digest/index.html | 142 ++++++ .../web/http/headers/user-agent/firefox/index.html | 55 +++ .../mecanismo_actualizacion_protocolo/index.html | 246 ----------- .../web/http/peticiones_condicionales/index.html | 148 ------- .../web/http/protocol_upgrade_mechanism/index.html | 246 +++++++++++ .../http/recursos_y_especificaciones/index.html | 262 ----------- .../http/resources_and_specifications/index.html | 262 +++++++++++ "files/es/web/http/sesi\303\263n/index.html" | 158 ------- files/es/web/http/session/index.html | 158 +++++++ files/es/web/http/status/413/index.html | 34 ++ files/es/web/http/status/8080/index.html | 34 -- 20 files changed, 1959 insertions(+), 1762 deletions(-) delete mode 100644 files/es/web/http/access_control_cors/index.html create mode 100644 files/es/web/http/basics_of_http/data_uris/index.html delete mode 100644 files/es/web/http/basics_of_http/datos_uris/index.html delete 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/identifying_resources_on_the_web/index.html create mode 100644 files/es/web/http/conditional_requests/index.html create mode 100644 files/es/web/http/connection_management_in_http_1.x/index.html create mode 100644 files/es/web/http/cors/index.html delete mode 100644 files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html create mode 100644 files/es/web/http/headers/digest/index.html create mode 100644 files/es/web/http/headers/user-agent/firefox/index.html delete mode 100644 files/es/web/http/mecanismo_actualizacion_protocolo/index.html delete mode 100644 files/es/web/http/peticiones_condicionales/index.html create mode 100644 files/es/web/http/protocol_upgrade_mechanism/index.html delete mode 100644 files/es/web/http/recursos_y_especificaciones/index.html create mode 100644 files/es/web/http/resources_and_specifications/index.html delete mode 100644 "files/es/web/http/sesi\303\263n/index.html" create mode 100644 files/es/web/http/session/index.html create mode 100644 files/es/web/http/status/413/index.html delete mode 100644 files/es/web/http/status/8080/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 deleted file mode 100644 index efd60a179a..0000000000 --- a/files/es/web/http/access_control_cors/index.html +++ /dev/null @@ -1,491 +0,0 @@ ---- -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/basics_of_http/data_uris/index.html b/files/es/web/http/basics_of_http/data_uris/index.html new file mode 100644 index 0000000000..6fa23a5ba3 --- /dev/null +++ b/files/es/web/http/basics_of_http/data_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/datos_uris/index.html b/files/es/web/http/basics_of_http/datos_uris/index.html deleted file mode 100644 index 6fa23a5ba3..0000000000 --- a/files/es/web/http/basics_of_http/datos_uris/index.html +++ /dev/null @@ -1,168 +0,0 @@ ---- -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/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" deleted file mode 100644 index f666c9240f..0000000000 --- "a/files/es/web/http/basics_of_http/identificaci\303\263n_recursos_en_la_web/index.html" +++ /dev/null @@ -1,169 +0,0 @@ ---- -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/identifying_resources_on_the_web/index.html b/files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.html new file mode 100644 index 0000000000..f666c9240f --- /dev/null +++ b/files/es/web/http/basics_of_http/identifying_resources_on_the_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/conditional_requests/index.html b/files/es/web/http/conditional_requests/index.html new file mode 100644 index 0000000000..c480c68ee2 --- /dev/null +++ b/files/es/web/http/conditional_requests/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/connection_management_in_http_1.x/index.html b/files/es/web/http/connection_management_in_http_1.x/index.html new file mode 100644 index 0000000000..5e9fff8fa9 --- /dev/null +++ b/files/es/web/http/connection_management_in_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/cors/index.html b/files/es/web/http/cors/index.html new file mode 100644 index 0000000000..efd60a179a --- /dev/null +++ b/files/es/web/http/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/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 deleted file mode 100644 index 5e9fff8fa9..0000000000 --- a/files/es/web/http/gestion_de_la_conexion_en_http_1.x/index.html +++ /dev/null @@ -1,86 +0,0 @@ ---- -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/digest/index.html b/files/es/web/http/headers/digest/index.html new file mode 100644 index 0000000000..8f35030d35 --- /dev/null +++ b/files/es/web/http/headers/digest/index.html @@ -0,0 +1,142 @@ +--- +title: SubtleCrypto.digest() +slug: Web/API/SubtleCrypto/encrypt +tags: + - API + - Encriptación + - Referencia + - SubtleCrypto + - Web Crypto API + - encrypt +translation_of: Web/HTTP/Headers/Digest +--- +
{{APIRef("Web Crypto API")}}
+ +

El método digest() de la interfaz {{domxref("SubtleCrypto")}} genera un digest de los datos proveidos. Un {{domxref("digest")}} es un valor corto de longitud fija derivado de alguna entrada de longitud variable. Los digest criptográficos deben mostrar resistencia a colisiones, lo que significa que es difícil encontrar dos entradas diferentes que tengan el mismo valor de digest.

+ +

Toma como argumento un identificador para el algoritmo digest a utilizar y los datos a codificar. Devuelve un Promise que se completará con el digest.

+ +

Sintaxis

+ +
const digest = crypto.subtle.digest(algorithm, data);
+
+ +

Parámetros

+ + + +

Valor de retorno

+ + + +

Algoritmos soportados

+ +

Los argoritmos digest, también conocidos como funciones criptográficas hash, transforman un bloque de datos arbitrariamente grande en una salida de tamaño fijo, normalmente mucho más corta que la entrada. Tienen una variedad de aplicaciones en criptografía.

+ +

SHA-1

+ +

Este algoritmo se especifica en FIPS 180-4, sección 6.1, y produce una salida de 160 bits de largo.

+ +
+

Advertencia: Este algoritmo se considera ahora vulnerable y no debe utilizarse para aplicaciones criptográficas.

+
+ +

SHA-256

+ +

Este algoritmo se especifica en FIPS 180-4, sección 6.2, y produce una salida de 256 bits de largo.

+ +

SHA-384

+ +

Este algoritmo se especifica en FIPS 180-4, sección 6.5, y produce una salida de 384 bits de largo.

+ +

SHA-512

+ +

Este algoritmo se especifica en FIPS 180-4, sección 6.4, y produce una salida de 512 bits de largo.

+ +
+

Sugerencia: Si estás buscando aquí cómo crear un código de autenticación de mensajes "keyed-hash" (HMAC), necesitas usar SubtleCrypto.sign() en su lugar.

+
+ +

Ejemplos

+ +

Ejemplo básico

+ +

Este ejemplo codifica un mensaje, luego calcula su digest SHA-256 y muestra la longitud del mismo:

+ +
const text = 'An obscure body in the S-K System, your majesty. The inhabitants refer to it as the planet Earth.';
+
+async function digestMessage(message) {
+  const encoder = new TextEncoder();
+  const data = encoder.encode(message);
+  const hash = await crypto.subtle.digest('SHA-256', data);
+  return hash;
+}
+
+const digestBuffer = await digestMessage(text);
+console.log(digestBuffer.byteLength);
+
+ +

Convirtiendo un digest a una cadena hexadecimal

+ +

El resumen se devuelve como un ArrayBuffer, pero para la comparación y visualización los digests se representan a menudo como cadenas hexadecimales. Este ejemplo calcula un digest, y luego convierte el ArrayBuffer a un string hexadecimal:

+ +
const text = 'An obscure body in the S-K System, your majesty. The inhabitants refer to it as the planet Earth.';
+
+async function digestMessage(message) {
+  const msgUint8 = new TextEncoder().encode(message);                           // encode as (utf-8) Uint8Array
+  const hashBuffer = await crypto.subtle.digest('SHA-256', msgUint8);           // hash the message
+  const hashArray = Array.from(new Uint8Array(hashBuffer));                     // convert buffer to byte array
+  const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join(''); // convert bytes to hex string
+  return hashHex;
+}
+
+const digestHex = await digestMessage(text);
+console.log(digestHex);
+
+ +

Especificaciones

+ + + + + + + + + + + + + + +
EspecificaciónEstadoComentario
{{SpecName('Web Crypto API', '#dfn-SubtleCrypto-method-digest', 'SubtleCrypto.digest()')}}{{Spec2('Web Crypto API')}}Definición inicial.
+ +

Compatibilidad del navegador

+ + + +

{{Compat("api.SubtleCrypto.digest")}}

+ +
+

En Chrome 60, se añadió una característica que deshabilita crypto.subtle para conexiones no TLS.

+
+ +

Ver también

+ + diff --git a/files/es/web/http/headers/user-agent/firefox/index.html b/files/es/web/http/headers/user-agent/firefox/index.html new file mode 100644 index 0000000000..4dbd1908cf --- /dev/null +++ b/files/es/web/http/headers/user-agent/firefox/index.html @@ -0,0 +1,55 @@ +--- +title: Cadenas del User Agent de Gecko +slug: Cadenas_del_User_Agent_de_Gecko +tags: + - Desarrollo_Web + - Todas_las_Categorías +translation_of: Web/HTTP/Headers/User-Agent/Firefox +--- +

Uso Apropiado

+

No se recomienda el uso de las cadenas del User Agent como su principal opción para la detección del navegador. Vea Deteccion Cross browser y Soporte Cross Browser para una ojeada mas en profundo a varias técnicas sobre detección de navegadores con recomendaciones.

+

En particular, recomendamos usar la detección de la cadena del User Agent para detección del navegador del lado del servidor. Si su actual código del lado cliente usa detección de la cadena del User Agent, simplemente puede hacer una búsqueda por la cadena "Gecko" en el User Agent para detectar cualquier navegador basado en Gecko.

+

Para todos los detalles que lidian con detecciones con Gecko los cuales lidian con bugs especificos o los cuales requieran conocimiento de strings especificos o fechas de la compilación, use el objeto navigator.

+

Lista de user agents liberados por Netscape y AOL basados en Gecko

+

Vea mozilla.org's user-agent strings reference para Plataforma específico, + + Seguridad + , + + Sistema Operativo + o + + CPU + y valores de + + localización + .

+ +


+ Para una información más detallada sobre liberaciones de Netscape y Mozilla, por favor vea el mozilla.org cvstags reference.

+

 

+
+

Informacion Del documento Original

+ +
+

 

diff --git a/files/es/web/http/mecanismo_actualizacion_protocolo/index.html b/files/es/web/http/mecanismo_actualizacion_protocolo/index.html deleted file mode 100644 index 74ef3b57f7..0000000000 --- a/files/es/web/http/mecanismo_actualizacion_protocolo/index.html +++ /dev/null @@ -1,246 +0,0 @@ ---- -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/peticiones_condicionales/index.html b/files/es/web/http/peticiones_condicionales/index.html deleted file mode 100644 index c480c68ee2..0000000000 --- a/files/es/web/http/peticiones_condicionales/index.html +++ /dev/null @@ -1,148 +0,0 @@ ---- -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/protocol_upgrade_mechanism/index.html b/files/es/web/http/protocol_upgrade_mechanism/index.html new file mode 100644 index 0000000000..74ef3b57f7 --- /dev/null +++ b/files/es/web/http/protocol_upgrade_mechanism/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/recursos_y_especificaciones/index.html b/files/es/web/http/recursos_y_especificaciones/index.html deleted file mode 100644 index 0c36d6e3e6..0000000000 --- a/files/es/web/http/recursos_y_especificaciones/index.html +++ /dev/null @@ -1,262 +0,0 @@ ---- -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/resources_and_specifications/index.html b/files/es/web/http/resources_and_specifications/index.html new file mode 100644 index 0000000000..0c36d6e3e6 --- /dev/null +++ b/files/es/web/http/resources_and_specifications/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" deleted file mode 100644 index 3d6e2d938b..0000000000 --- "a/files/es/web/http/sesi\303\263n/index.html" +++ /dev/null @@ -1,158 +0,0 @@ ---- -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/session/index.html b/files/es/web/http/session/index.html new file mode 100644 index 0000000000..3d6e2d938b --- /dev/null +++ b/files/es/web/http/session/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/413/index.html b/files/es/web/http/status/413/index.html new file mode 100644 index 0000000000..10ad4ac7b2 --- /dev/null +++ b/files/es/web/http/status/413/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/8080/index.html b/files/es/web/http/status/8080/index.html deleted file mode 100644 index 10ad4ac7b2..0000000000 --- a/files/es/web/http/status/8080/index.html +++ /dev/null @@ -1,34 +0,0 @@ ---- -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

- - -- cgit v1.2.3-54-g00ecf