From 1109132f09d75da9a28b649c7677bb6ce07c40c0 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:41:45 -0500 Subject: initial commit --- .../index.html | 71 +++++ .../web/http/basics_of_http/datos_uris/index.html | 168 +++++++++++ .../basics_of_http/evolution_of_http/index.html | 197 +++++++++++++ .../index.html" | 169 +++++++++++ files/es/web/http/basics_of_http/index.html | 51 ++++ .../mime_types/common_types/index.html | 321 +++++++++++++++++++++ .../web/http/basics_of_http/mime_types/index.html | 321 +++++++++++++++++++++ 7 files changed, 1298 insertions(+) create mode 100644 files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html create mode 100644 files/es/web/http/basics_of_http/datos_uris/index.html create mode 100644 files/es/web/http/basics_of_http/evolution_of_http/index.html create mode 100644 "files/es/web/http/basics_of_http/identificaci\303\263n_recursos_en_la_web/index.html" create mode 100644 files/es/web/http/basics_of_http/index.html create mode 100644 files/es/web/http/basics_of_http/mime_types/common_types/index.html create mode 100644 files/es/web/http/basics_of_http/mime_types/index.html (limited to 'files/es/web/http/basics_of_http') diff --git a/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html new file mode 100644 index 0000000000..53d2270e03 --- /dev/null +++ b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html @@ -0,0 +1,71 @@ +--- +title: Elección entre www y no-www URLs +slug: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +tags: + - Guía + - HTTP + - URL + - WWW + - no www +translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +--- +
{{HTTPSidebar}}
+ +

Una cuestión recurrente entre los dueños de sitios web consiste en elegir entre un no-www y www URLs. Esta página contiene algunos consejos sobre qué es mejor.

+ +

¿Qué son los nombres de dominio?

+ +

En una URL HTTP, la primera subcadena que sigue a la inicial http:// o https:// se llama nombre de dominio. El nombre de dominio está alojado en un servidor donde residen los documentos.

+ +

Un servidor no es necesariamente una máquina física: varios servidores pueden residir en la misma máquina física. O bien, un servidor puede ser manejado por varias máquinas, cooperando para producir la respuesta o equilibrando la carga de las solicitudes entre ellas. El punto clave es que semanticamente un nombre de dominio representa un solo servidor.

+ +

¿Entonces, ¿tengo que elegir uno u otro para mi sitio web?

+ + + +

Por lo tanto, ¡elija uno de sus dominios como su canónico! Hay dos técnicas a continuación para permitir que el dominio no canónico funcione aún.

+ +

Técnicas para las URL canónicas.

+ +

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

+ +

Usando redirecciones HTTP 301 

+ +

En este caso, necesitas configurar el servidor que recibe las peticiones HTTP  (que probablemente sea el mismo para las URL www y no www) para responder con una respuesta HTTP adecuada {{HTTPStatus (301)}} a cualquier solicitud al dominio no-canónico. Esto redirigirá el navegador que intenta acceder a las URL no canónicas a su equivalente canónico. Por ejemplo, si ha elegido usar URL que no sean de www como tipo canónico, debe redirigir todas las URL de www a su URL equivalente sin el www.

+ +

Ejemplo:

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

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

+ + + +

Es posible añadir un elemento especial HTML {{HTMLElement("link")}} a una página para indicar cual es la dirección canónica de la página. Esto no tendrá ningún impacto en la lectura humana, pero le dirá a rastreadores de los motores de búsqueda donde vive actualmente la página. De esta manera, los motores de búsqueda no indexan la misma página varias veces, lo que podría hacer que se considere contenido duplicado o correo no deseado, e incluso eliminar o bajar su página de las páginas de resultados del motor de búsqueda.

+ +

Al agregar una etiqueta de este tipo, sirve el mismo contenido para ambos dominios, indicando a los motores de búsqueda qué URL es canónica. En el ejemplo anterior, http://www.example.org/whaddup serviría el mismo contenido que  http://example.org/whaddup, pero con un elemento {{htmlelement("link")}} adicional en la cabecera:

+ +

<link href="http://example.org/whaddup" rel="canonical">

+ +

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

+ +

Hacer que tu página funcione para ambas

+ +

Con estas técnicas, puedes configurar tu servidor para responder correctamente a ambos dominios, www y no www. Es un buen consejo hacer esto, ya que no puede predecir qué URL escribirán los usuarios en la barra de URL de su navegador. Es una cuestión de elegir qué tipo desea usar como su ubicación canónica, y luego redirigir el otro tipo a él.

+ +

Decidir el caso

+ +

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

+ +

Ver también

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

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

+ +

Sintaxis

+ +

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

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

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

+ +

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

+ +

Algunos ejemplos:

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

Codificación de datos en formato base64

+ +

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

+ +
uuencode -m infile remotename
+
+ +

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

+ +

La salida será similar a esto:

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

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

+ +

En la pagina Web, usando JavaScript

+ +

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

+ +

Problemas comunes

+ +

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

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

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

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

Esto representa un recurso HTML cuyo contenido es:

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

Especificaciones

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

Compatibilidad del navegador

+ +

{{CompatibilityTable}}

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

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

+ +

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

+ +

Ver también

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

{{HTTPSidebar}}

+ +

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

+ +

Invención de la World Wide Web

+ +

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

+ + + +

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

+ +

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

+ +

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

+ +

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

+ +
GET /miPaginaWeb.html
+ +

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

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

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

+ +

HTTP/1.0 – Desarrollando expansibilidad

+ +

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

+ + + +

Una petición normal, sigue la estructura: 

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

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

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

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

+ +

HTTP/1.1 – El protocolo estándar.

+ +

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

+ +

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

+ + + +

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

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

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

+ +

Más de 15 años de expansiones

+ +

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

+ +

El uso de HTTP para transmisiones seguras

+ +

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

+ +

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

+ +

Uso de HTTP para aplicaciones complejas

+ +

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

+ +

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

+ +

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

+ + + +

Relajación del modelo de seguridad de la Web

+ +

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

+ +

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

+ +

HTTP/2 – Un protocolo para un mayor rendimiento

+ +

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

+ +

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

+ +

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

+ + + +

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

+ +

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

+ +

Post-evolución del HTTP/2

+ +

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

+ + + +

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

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

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

+ +

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

+ +

URLs and URNs

+ +

URLs

+ +

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

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

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

+ +

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

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

URNs

+ +

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

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

Las dos URNs corresponden a

+ + + +

Sintaxis de Identificador Uniforme de Recursos (URIs)

+ +

 

+ +

Esquema o protocolo

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

Autoridad

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

Puerto

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

Ruta de Acceso

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

Consulta

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

Fragmento

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

Ejemplos

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

Especificaciones

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

Ver también

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

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

+ +

Artículos

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

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

+ +

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

+ + + +

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

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

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

+ +

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

+ +

Sintaxis

+ +

Estructura general

+ +
tipo/subtipo
+ +

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

+ +

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

+ +

Tipos discretos

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

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

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

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

+ +

Tipos multiparte

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

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

+ +

Tipos MIME importantes para desarrolladores Web

+ +

application/octet-stream

+ +

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

+ +

text/plain

+ +

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

+ +
+

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

+
+ +

text/css

+ +

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

+ +

text/html

+ +

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

+ +

Tipos de imágenes

+ +

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

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

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

+ +

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

+ + + +

Tipos de audio y video

+ +

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

+ +

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

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

multipart/form-data

+ +

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

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

El siguiente formulario:

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

enviará este mensaje:

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

multipart/byteranges

+ +

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

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

Importancia de establecer el tipo MIME correcto

+ +

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

+ + + +

Olfateo MIME (sniffing)

+ +

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

+ +

Otros métodos de transporte de tipo de documento

+ +

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

+ + + + + +

Ver también

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