diff options
| author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:45 -0500 |
|---|---|---|
| committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:45 -0500 |
| commit | 1109132f09d75da9a28b649c7677bb6ce07c40c0 (patch) | |
| tree | 0dd8b084480983cf9f9680e8aedb92782a921b13 /files/es/web/http/basics_of_http | |
| parent | 4b1a9203c547c019fc5398082ae19a3f3d4c3efe (diff) | |
| download | translated-content-1109132f09d75da9a28b649c7677bb6ce07c40c0.tar.gz translated-content-1109132f09d75da9a28b649c7677bb6ce07c40c0.tar.bz2 translated-content-1109132f09d75da9a28b649c7677bb6ce07c40c0.zip | |
initial commit
Diffstat (limited to 'files/es/web/http/basics_of_http')
7 files changed, 1298 insertions, 0 deletions
diff --git a/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html 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 +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">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.</p> + +<h2 id="¿Qué_son_los_nombres_de_dominio">¿Qué son los nombres de dominio?</h2> + +<p>En una URL HTTP, la primera subcadena que sigue a la inicial <code>http://</code> o <code>https://</code> se llama nombre de dominio. El nombre de dominio está alojado en un servidor donde residen los documentos.</p> + +<p>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.</p> + +<h2 id="¿Entonces_¿tengo_que_elegir_uno_u_otro_para_mi_sitio_web">¿Entonces, ¿tengo que elegir uno u otro para mi sitio web?</h2> + +<ul> + <li><u>Sí</u>, tienes que elegir uno y seguir con él. La elección de cual tener como ubicación canónica es tuya, pero si eliges una, síguela. Esto hará tu sitio web parezca más consistente para tus usuarios y para los motores de búsqueda. Esto incluye siempre vincular al dominio elegido (lo que no debería ser difícil si está utilizando URLs relativas en su sitio web) y siempre compartir enlaces (por correo electrónico / redes sociales, etc.) al mismo dominio.</li> + <li><u>No</u>, puedes tener dos. Lo que es importante es que seas coherente y consistente con cuál es el dominio oficial. <strong>A este dominio oficial se le llama nombre <em>canónico</em>. </strong>Todos tus enlaces absolutos deben usarlo. Pero, aun así, puedes seguir teniendo el otro dominio funcionando: HTTP permite dos técnicas para que esté claro para sus usuarios, o motores de búsqueda, cuyo dominio es el canónico, mientras permite que el dominio no-canónico funcione para proporcionar las páginas esperadas.</li> +</ul> + +<p>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.</p> + +<h2 id="Técnicas_para_las_URL_canónicas.">Técnicas para las URL canónicas.</h2> + +<p>Hay diferentes maneras de elegir qué sitio web es <em>canónico</em>.</p> + +<h3 id="Usando_redirecciones_HTTP_301">Usando redirecciones HTTP 301 </h3> + +<p>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.</p> + +<p>Ejemplo:</p> + +<ol> + <li>Un servidor recibe una petición para <code>http://www.example.org/whaddup</code> (cuando el dominio canónico es example.org)</li> + <li>El servidor responde con un código {{HTTPStatus(301)}} con la cabecera <code>{{HTTPHeader("Location")}}: http://example.org/whaddup</code>.</li> + <li>El cliente emite una solicitud al dominio canónico.: <code>http://example.org/whatddup</code></li> +</ol> + +<p>El <a href="https://github.com/h5bp/html5-boilerplate">HTML5 boilerplate project</a> tiene un ejemplo sobre <a href="https://github.com/h5bp/html5-boilerplate/blob/7a22a33d4041c479d0962499e853501073811887/.htaccess#L219-L258">cómo configurar un servidor Apache para redirigir un dominio a otro</a>.</p> + +<h3 id="Usando_<link_relcanonical>"><code><font face="x-locale-heading-primary, zillaslab, Palatino, Palatino Linotype, x-locale-heading-secondary, serif"><span style="background-color: #333333;">Usando </span></font><em><</em>link<em> rel</em><em>="canonical"></em></code></h3> + +<p>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.</p> + +<p>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, <code>http://www.example.org/whaddup</code> serviría el mismo contenido que <code>http://example.org/whaddup</code>, pero con un elemento {{htmlelement("link")}} adicional en la cabecera:</p> + +<p><code><link href="http://example.org/whaddup" rel="canonical"></code></p> + +<p>A diferencia del caso anterior, el historial del navegador considerará las direcciones URL no www y www como entradas independientes.</p> + +<h2 id="Hacer_que_tu_página_funcione_para_ambas">Hacer que tu página funcione para ambas</h2> + +<p>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.</p> + +<h2 id="Decidir_el_caso">Decidir el caso</h2> + +<p class="entry-title">Este es un tema muy subjetivo que podría considerarse un problema de <a href="http://bikeshed.com/">bikeshedding</a>. Si desea leer más a fondo, lea algunos de los <a href="http://www.themezilla.com/should-you-use-www-in-your-url-or-not/">muchos artículos</a> de este tema.</p> + +<h2 id="Ver_también">Ver también</h2> + +<ul> + <li><a href="https://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/">Estadísticas sobre lo que la gente escribe en la barra de URL</a> (2011)</li> +</ul> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>Datos URIs</strong>, URLs prefijados con los datos<code>:</code> esquema, permiten a los creadores de contenido incorporar pequeños archivos en linea en los documentos.</p> + +<h2 id="Sintaxis">Sintaxis</h2> + +<p>Los datos URIs se componen de cuatro partes a: un prefijo (<code>data:</code>), un tipo MIME que indica el tipo de datos, un token <code>base64</code> opcional no textual, y los datos en si:</p> + +<pre class="syntaxbox">data:[<mediatype>][;base64],<data> +</pre> + +<p>El <code>mediatype</code> es una cadena de tipo MIME, por ejemplo <code>'image/jpeg'</code> para un archivo de imagen JPEG. si se omite, será por defecto <code>text/plain;charset=US-ASCII</code></p> + +<p>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.</p> + +<p>Algunos ejemplos:</p> + +<dl> + <dt><code>data:,Hello%2C%20World!</code></dt> + <dd>Datos simples text/plain</dd> + <dt><code>data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D</code></dt> + <dd>versión codificada en base64-encoded de las anteriores</dd> + <dt><code>data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E</code></dt> + <dd>Un documento HTML con <code><h1>Hello, World!</h1></code></dd> + <dt><code>data:text/html,<script>alert('hi');</script></code></dt> + <dd>Un documento HTML que ejecuta una alerta Javascript. Tenga en cuenta que se requiere la etiqueta script de cierre.</dd> +</dl> + +<h2 id="Codificación_de_datos_en_formato_base64">Codificación de datos en formato base64</h2> + +<p>Esto se puede hacer fácilmente desde la línea de comandos usando <code>uuencode, </code>una utilidad disponible en sistemas Linux y Mac OS X:</p> + +<pre>uuencode -m infile remotename +</pre> + +<p>El parámetro <code>infile</code> es el nombre para el archivo que desees decodificar en formato base64, y <code>remotename</code> es el nombre remoto para el archivo, que no se utilizará realmente en los datos de las URLs.</p> + +<p>La salida será similar a esto:</p> + +<pre>xbegin-base64 664 test +YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK +==== +</pre> + +<p>El URI de datos utilizará los datos codificados después de la cabezera inicial.</p> + +<h3 id="En_la_pagina_Web_usando_JavaScript">En la pagina Web, usando JavaScript</h3> + +<p>Las Web tiene APIs primitivas para codificar o decodificar en base64: <a href="/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding">codificación y decodificación Base64</a>.</p> + +<h2 id="Problemas_comunes">Problemas comunes</h2> + +<p>Esta sección describe los problemas que comunmente ocurren cuando se crean o se usan los datos URIs.</p> + +<dl> + <dt>Sintaxis</dt> + <dd>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.</dd> + <dt>Formateando en HTML</dt> + <dd>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 (<span class="short_text" id="result_box" lang="es"><span>avance de línea</span><span>,</span> <span>pestaña</span><span>, o espacios</span></span>), pero hay cuestiones prácticas que se plantean <a class="external" href="http://bugzilla.mozilla.org/show_bug.cgi?id=73026#c12">cuando se usa codificación base64</a>.</dd> + <dt>Limitaciones de longitud</dt> + <dd>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<code> los </code>65000 caracteres.</dd> + <dt>Falta de control de errores</dt> + <dd>Los parametros no válidos en los medios de comunicación, o errores ortográficos cuando se especifiquen<code> 'base64'</code>, se ignoran, pero no se proporciona ningún error.</dd> + <dt>No hay soporte para consulta de cadenas, etc.</dt> + <dd> + <p>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<code> <url>?parameter-data</code>) con un URIs de datos que se acaba de incluir la cadena de consulta en los datos de la URI que representa. Por ejemplo:</p> + + <pre>data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val +</pre> + + <p>Esto representa un recurso HTML cuyo contenido es:</p> + + <pre class="eval">lots of text...<p><a name="bottom">bottom</a>?arg=val +</pre> + </dd> +</dl> + +<h2 id="Especificaciones">Especificaciones</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Especificación</th> + <th scope="col">Título</th> + </tr> + <tr> + <td>{{RFC("2397")}}</td> + <td>The "data" URL scheme"</td> + </tr> + </tbody> +</table> + +<h2 id="Compatibilidad_del_navegador">Compatibilidad del navegador</h2> + +<p>{{CompatibilityTable}}</p> + +<div id="compat-desktop"> +<table class="compat-table" style="height: 64px; width: 812px;"> + <tbody> + <tr> + <th>Característica</th> + <th>Chrome</th> + <th>Firefox (Gecko)</th> + <th>Edge</th> + <th>Internet Explorer</th> + <th>Opera</th> + <th>Safari</th> + </tr> + <tr> + <td>Soporte Básico</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>12<sup>[2]</sup></td> + <td>{{CompatIE(8)}}<sup>[1][2]</sup></td> + <td>7.20</td> + <td>{{CompatVersionUnknown}}</td> + </tr> + </tbody> +</table> +</div> + +<div id="compat-mobile"> +<table class="compat-table"> + <tbody> + <tr> + <th>Característica</th> + <th>Android</th> + <th>Firefox Mobile (Gecko)</th> + <th>IE Mobile</th> + <th>Opera Mobile</th> + <th>Safari Mobile</th> + </tr> + <tr> + <td>Soporte Básico</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + </tr> + </tbody> +</table> +</div> + +<p>[1] IE8 solo soporta datos URIs en archivos CSS, con un tamaño máximo de 32kB.</p> + +<p>[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.</p> + +<h2 id="Ver_también">Ver también</h2> + +<ul> + <li><a href="/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding">Base64 codificación y decodificación</a></li> + <li>{{domxref("WindowBase64.atob","atob()")}}</li> + <li>{{domxref("WindowBase64.btoa","btoa()")}}</li> + <li><a href="/en-US/docs/Web/CSS/uri">CSS <code>url()</code></a></li> + <li><a href="/en-US/docs/URI">URI</a></li> +</ul> 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 +--- +<p>{{HTTPSidebar}}</p> + +<p><strong>HTTP</strong> 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.</p> + +<h2 id="Invención_de_la_World_Wide_Web">Invención de la World Wide Web</h2> + +<p>En 1989, mientras trabajaba en el CERN, Tim Berners-Lee escribió una propuesta para desarrollar un sistema de hipertexto sobre Internet. Inicialmente lo llamó: '<em>Mesh' </em>(malla, en inglés), y posteriormente se renombró como<em> World Wide Web </em>(red mundial), durante su implementación en 1990. Desarrollado sobre los protocolos existentes TCP e IP, está basado en cuatro bloques:</p> + +<ul> + <li>Un formato de texto para representar documentos de hiper-texto: <em><a href="/en-US/docs/Web/HTML">HyperText Markup Language</a></em> (HTML).</li> + <li>Un protocolo sencillo para el intercambio de esos documentos, del inglés: <em>HypertText Transfer Protocol </em>(HTTP) : protocolo de transferencia de hiper-texto.</li> + <li>Un cliente que muestre (e incluso pueda editar) esos documentos. El primer navegador Web, llamado: <em>WorldWideWeb</em>.</li> + <li>Un servidor para dar acceso a los documentos, una versión temprana: <em>httpd (http daemon)</em></li> +</ul> + +<p>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 <a href="https://groups.google.com/forum/#!msg/alt.hypertext/eCTkkOoWTAY/urNMgHnS2gYJ">post</a> de Tim Berners-Lee, se considera actualmente como el inicio oficial de la Web como proyecto público. </p> + +<p>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.</p> + +<h2 id="HTTP0.9_–_El_protocolo_de_una_sola_línea">HTTP/0.9 – El protocolo de una sola línea</h2> + +<p>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).</p> + +<pre>GET /miPaginaWeb.html</pre> + +<p>La respuesta también es muy sencilla: solamente consiste el archivo pedido.</p> + +<pre><HTML> +Una pagina web muy sencilla +</HTML></pre> + +<p>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.</p> + +<h2 id="HTTP1.0_–_Desarrollando_expansibilidad">HTTP/1.0 – Desarrollando expansibilidad</h2> + +<p>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.</p> + +<ul> + <li>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.</li> + <li>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).</li> + <li>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. </li> + <li>Con el uso de las cabeceras de HTTP, se pudieron transmitir otros documentos además de HTML, mediante la cabecera {{HTTPHeader("Content-Type")}}.</li> +</ul> + +<p>Una petición normal, sigue la estructura: </p> + +<pre>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></pre> + +<p>Continua con una segunda conexión y la petición de una imagen:</p> + +<pre>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 +<em>(image content)</em></pre> + +<p>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. </p> + +<h2 id="HTTP1.1_–_El_protocolo_estándar.">HTTP/1.1 – El protocolo estándar.</h2> + +<p>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 </p> + +<p>HTTP/1.1 aclaró ambigüedades y añadió numerosas mejoras: </p> + +<ul> + <li>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.</li> + <li>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.</li> + <li>Se permitió que las respuestas a peticiones, podían ser divididas en sub-partes.</li> + <li>Se añadieron controles adicionales a los mecanismos de gestión de la cache. </li> + <li>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. </li> + <li>Gracias a la cabecera, {{HTTPHeader("Host")}}, pudo ser posible alojar varios dominios en la misma dirección IP. </li> +</ul> + +<p>El flujo normal de una serie de peticiones y respuestas, bajo una única conexión, se expone a continuación:</p> + +<pre>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 + +<em>(...contenido...)</em> + + +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 + +<em>(image content of 3077 bytes)</em></pre> + +<p>HTTP/1.1 fue publicado inicialmente como {{rfc(2068)}} en Enero de 1997.</p> + +<h2 id="Más_de_15_años_de_expansiones">Más de 15 años de expansiones</h2> + +<p>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.</p> + +<h3 id="El_uso_de_HTTP_para_transmisiones_seguras">El uso de HTTP para transmisiones seguras</h3> + +<p>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.</p> + +<p>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.</p> + +<h3 id="Uso_de_HTTP_para_aplicaciones_complejas">Uso de HTTP para aplicaciones complejas</h3> + +<p>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. </p> + +<p>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.</p> + +<p>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: </p> + +<ul> + <li><a href="/en-US/docs/Web/API/Server-sent_events">Eventos enviados por el servidor</a>: El servidor es el que ocasionalmente inicia los mensajes hacia el navegador. </li> + <li><a href="/en-US/docs/Web/API/WebSocket_API">WebSocket</a>, un nuevo protocolo que puede establecerse actualizando una conexión HTTP existente.</li> +</ul> + +<h3 id="Relajación_del_modelo_de_seguridad_de_la_Web">Relajación del modelo de seguridad de la Web</h3> + +<p>El protocolo HTTP es independiente del modelo de seguridad de la Web: la <a href="/en-US/docs/Web/Security/Same-origin_policy">política del mismo origen</a>. 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 <a href="/en-US/docs/Glossary/CORS">Cross-Origin Resource Sharing</a>, que viene a significar: recursos compartidos de orígenes cruzados) y el CSP (del inglés: <a href="/en-US/docs/Web/Security/CSP">Content Security Policy</a> , que traducido es: política de seguridad de contenidos).</p> + +<p>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')}}.</p> + +<h2 id="HTTP2_–_Un_protocolo_para_un_mayor_rendimiento">HTTP/2 – Un protocolo para un mayor rendimiento</h2> + +<p>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. </p> + +<p>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 <em>'speedy'</em>). 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. </p> + +<p>El protocolo HTTP/2, tiene notables diferencias fundamentales respecto a la versión anterior HTTP/1.1</p> + +<ul> + <li>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. </li> + <li>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</li> + <li>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. </li> + <li>Esto permite al servidor almacenar datos en la caché del cliente, previamente a que estos sean pedidos, mediante un mecanismo denominado '<em>server push</em>'.</li> +</ul> + +<p>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<sup><a href="https://w3techs.com/technologies/details/ce-http2/all/all">[1]</a></sup> estaban usandolo ya, representando más del 68% de todo su tráfico<sup><a href="https://www.keycdn.com/blog/http2-statistics/">[2]</a></sup>. 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.</p> + +<p>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.</p> + +<h2 id="Post-evolución_del_HTTP2">Post-evolución del HTTP/2</h2> + +<p>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: </p> + +<ul> + <li>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")}}.</li> + <li>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.</li> + <li>La introducción de prefijos de seguridad en la cabecera {{HTTPHeader("Cookie")}}, esto ayuda a garantizar que una cookie, no ha sido alterada.</li> +</ul> + +<p>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.</p> diff --git a/files/es/web/http/basics_of_http/identificación_recursos_en_la_web/index.html b/files/es/web/http/basics_of_http/identificación_recursos_en_la_web/index.html new file mode 100644 index 0000000000..f666c9240f --- /dev/null +++ b/files/es/web/http/basics_of_http/identificación_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 +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">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.</p> + +<p>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.</p> + +<h2 id="URLs_and_URNs">URLs and URNs</h2> + +<h3 id="URLs">URLs</h3> + +<p>La forma más común de URI es la ({{Glossary("URL")}}) (de las siglas en ingles: "<em>Uniform Resource Locator</em>", que podría traducirse como: Localizador Uniforme de Recursos), <em>que se conoce como la dirección web.</em></p> + +<pre>https://developer.mozilla.org +https://developer.mozilla.org/en-US/docs/Learn/ +https://developer.mozilla.org/en-US/search?q=URL</pre> + +<p>Cualquiera de estas URLs se pueden escribir en la barra de direcciones de su navegador para decirle que cargue la pagina asociada (recurso).</p> + +<p>Una URL esta compuesta de diferentes partes, algunas obligatorias y otras son opcionales. Un ejemplo más complejo podría tener este aspecto:</p> + +<pre>http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument</pre> + +<h3 id="URNs">URNs</h3> + +<p><span id="result_box" lang="es"><span>Un</span> <span>URN</span> <span>es</span> <span>una URI que</span> <span>identifica un recurso</span> <span>por su nombre en</span> <span>un espacio de nombres</span> <span>particular.</span></span></p> + +<pre>urn:isbn:9780141036144 +urn:ietf:rfc:7230 +</pre> + +<p>Las dos URNs corresponden a</p> + +<ul> + <li>El libro "1984" por George Orwell,</li> + <li>La especificación IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Sintaxis de Mensajes y Enrutamiento.</li> +</ul> + +<h2 id="Sintaxis_de_Identificador_Uniforme_de_Recursos_(URIs)">Sintaxis de Identificador Uniforme de Recursos (URIs)</h2> + +<h3 id="sect1"> </h3> + +<h3 id="Esquema_o_protocolo">Esquema o protocolo</h3> + +<dl> + <dt><img alt="Protocol" src="https://mdn.mozillademos.org/files/8013/mdn-url-protocol@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>http://</code> 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 <code>mailto:</code> (para abrir un cliente de correo) o <code>ftp:</code> para manejar la transferencia de archivos, por lo que no se sorprenda si usted ve este tipo de protocolos. Los esquemas comunes son:</dd> +</dl> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Esquema</th> + <th scope="col">Descripción</th> + </tr> + </thead> + <tbody> + <tr> + <td>data</td> + <td><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Datos URIs</a></td> + </tr> + <tr> + <td>file</td> + <td>Host-nombre de archivo específicos</td> + </tr> + <tr> + <td>ftp</td> + <td><a href="/en-US/docs/Glossary/FTP">Protocolo de Transferencia de Archivos</a></td> + </tr> + <tr> + <td>http/https</td> + <td><a href="/en-US/docs/Glossary/HTTP">Protocolo de transferencia de Hipertexto (Seguro)</a></td> + </tr> + <tr> + <td>mailto</td> + <td>Dirección de correo electrónico</td> + </tr> + <tr> + <td>ssh</td> + <td>shell seguro</td> + </tr> + <tr> + <td>tel</td> + <td>teléfono</td> + </tr> + <tr> + <td>urn</td> + <td>Nombres Uniformes de Recursos</td> + </tr> + <tr> + <td>view-source</td> + <td>Código fuente del recurso</td> + </tr> + <tr> + <td>ws/wss</td> + <td>(Encriptado) conexiones <a href="/en-US/docs/Web/API/WebSockets_API">WebSocket</a></td> + </tr> + </tbody> +</table> + +<h3 id="Autoridad">Autoridad</h3> + +<dl> + <dt><img alt="Domaine Name" src="https://mdn.mozillademos.org/files/8015/mdn-url-domain@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>www.example.com</code> 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.</dd> +</dl> + +<h3 id="Puerto">Puerto</h3> + +<dl> + <dt><img alt="Port" src="https://mdn.mozillademos.org/files/8017/mdn-url-port@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>:80</code> 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.</dd> +</dl> + +<h3 id="Ruta_de_Acceso">Ruta de Acceso</h3> + +<dl> + <dt><img alt="Path to the file" src="https://mdn.mozillademos.org/files/8019/mdn-url-path@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>/path/to/myfile.html</code> 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.</dd> +</dl> + +<h3 id="Consulta">Consulta</h3> + +<dl> + <dt><img alt="Parameters" src="https://mdn.mozillademos.org/files/8021/mdn-url-parameters@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>?key1=value1&key2=value2</code> 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.</dd> +</dl> + +<h3 id="Fragmento">Fragmento</h3> + +<dl> + <dt><img alt="Anchor" src="https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>#SomewhereInTheDocument</code> 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.</dd> +</dl> + +<h2 id="Ejemplos">Ejemplos</h2> + +<pre>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 +</pre> + +<h2 id="Especificaciones">Especificaciones</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Especificación</th> + <th scope="col">Título</th> + </tr> + <tr> + <td>{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="Ver_también">Ver también</h2> + +<ul> + <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_URL">Qué es una URL?</a></li> + <li><a href="http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">Lista de esquemas URI IANA </a></li> +</ul> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">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.</p> + +<h2 id="Artículos">Artículos</h2> + +<dl> + <dt><a href="/es/docs/Web/HTTP/Overview">Generalidades del HTTP</a></dt> + <dd>Descripción de qué es el protocolo HTTP y su función en la arquitectura de la Web. </dd> + <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evolución del HTTP</a> </dt> + <dd>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.</dd> + <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Negotiating_an_HTTP_version">Negociación de la versión de HTTP </a></dt> + <dd>Se explica como un cliente y un servidor pueden negociar una versión específica de HTTP y eventualmente actualizar la version usada.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Resources_and_URIs">Recursos y URIs</a></dt> + <dd>Una breve descripción sobre qué son los recursos, identificadores y localidades en la Web. </dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identificación de recursos en la Web</a> </dt> + <dd>Descripción de como se referencian recursos en la Web, como son referenciados y como localizarlos. </dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">URIs de datos</a> </dt> + <dd>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. </dd> + <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Resource_URLs">URLs de recursos</a></dt> + <dd>Los recursos URL, prefijados con <code>resource:</code> en vez de <code>http </code>son usados por Firefox y algunas extensiones del navegador para cargar recursos internamente, <span class="tlid-translation translation" lang="es"><span title="">pero parte de la información también está disponible para los sitios a los que se conecta el navegador.</span></span><br> + </dd> + <dt>Separación de la identidad y la localización de un recurso: la cabecera Alt-Svc</dt> + <dd>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")}}.</dd> + <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types">Tipos MIME </a></dt> + <dd>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. </dd> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">Elección de URLs: www y no-www</a></dt> + <dd>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. </dd> + <dt><a href="/es/docs/Web/HTTP/Basics_of_HTTP/Resource_URLs">Flujo de comunicación en una sesión HTTP</a></dt> + <dd>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.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Messages">Mensajes HTTP</a></dt> + <dd>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. </dd> + <dt><a href="/es/docs/Web/HTTP/Frame%20and%20message%20structure%20in%20HTTP_2">Tramas y estructura de los mensajes en HTTP/2</a></dt> + <dd>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. </dd> + <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Proceso de conexión en HTTP/1.x</a></dt> + <dd>HTTP/1.1 fue la primera versión de HTTP que soportó las conexiones persistentes y el <em>pipelining</em>. En este artículo se explican estos dos conceptos.</dd> + <dt><a href="/es/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Proceso de conexión en HTTP/2 </a></dt> + <dd>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. </dd> + <dt><a href="/en-US/docs/Web/HTTP/Content_negotiation">Negociación de contenidos</a></dt> + <dd>HTTP presenta una serie de cabeceras que comienzan con <code>Accept-</code> 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.</dd> +</dl> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="short_text" id="result_box" lang="es"><span>Aquí está una lista completa de</span></span> tipos de MIME, asociados por tipo de documentos y ordenados por su extensión común.</p> + +<p>Dos tipos primarios de MIME son importantes para el rol de tipos por defecto:</p> + +<ul> + <li><code>text/plain</code> es el valor por defecto para los archivos textuales. Un archivo textual debe ser legible y no puede contener datos binarios.</li> + <li><code>application/octet-stream</code> 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.</li> +</ul> + +<p>IANA es el registro oficial de los tipos de media MIME y mantiene una <a href="http://www.iana.org/assignments/media-types/media-types.xhtml">lista oficial de todos los tipos de MIME</a>. Esta tabla, lista algunos de los tipos de MIME importantes para la web:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Extensión</th> + <th scope="col">Tipo de documento</th> + <th scope="col">Tipo de MIME</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>.aac</code></td> + <td>Archivo de audio AAC</td> + <td><code>audio/aac</code></td> + </tr> + <tr> + <td><code>.abw</code></td> + <td>Documento <a href="https://en.wikipedia.org/wiki/AbiWord">AbiWord</a></td> + <td><code>application/x-abiword</code></td> + </tr> + <tr> + <td><code>.arc</code></td> + <td>Documento de Archivo (múltiples archivos incrustados)</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.avi</code></td> + <td>AVI: Audio Video Intercalado</td> + <td><code>video/x-msvideo</code></td> + </tr> + <tr> + <td><code>.azw</code></td> + <td>Formato eBook Amazon Kindle </td> + <td><code>application/vnd.amazon.ebook</code></td> + </tr> + <tr> + <td><code>.bin</code></td> + <td>Cualquier tipo de datos binarios</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.bz</code></td> + <td>Archivo BZip</td> + <td><code>application/x-bzip</code></td> + </tr> + <tr> + <td><code>.bz2</code></td> + <td>Archivo BZip2</td> + <td><code>application/x-bzip2</code></td> + </tr> + <tr> + <td><code>.csh</code></td> + <td>Script C-Shell</td> + <td><code>application/x-csh</code></td> + </tr> + <tr> + <td><code>.css</code></td> + <td>Hojas de estilo (CSS)</td> + <td><code>text/css</code></td> + </tr> + <tr> + <td><code>.csv</code></td> + <td>Valores separados por coma (CSV)</td> + <td><code>text/csv</code></td> + </tr> + <tr> + <td><code>.doc</code></td> + <td>Microsoft Word</td> + <td><code>application/msword</code></td> + </tr> + <tr> + <td><code>.epub</code></td> + <td>Publicación Electrónica (EPUB)</td> + <td><code>application/epub+zip</code></td> + </tr> + <tr> + <td><code>.gif</code></td> + <td>Graphics Interchange Format (GIF)</td> + <td><code>image/gif</code></td> + </tr> + <tr> + <td><code>.htm<br> + .html</code></td> + <td>Hipertexto (HTML)</td> + <td><code>text/html</code></td> + </tr> + <tr> + <td><code>.ico</code></td> + <td>Formato Icon</td> + <td><code>image/x-icon</code></td> + </tr> + <tr> + <td><code>.ics</code></td> + <td>Formato iCalendar</td> + <td><code>text/calendar</code></td> + </tr> + <tr> + <td><code>.jar</code></td> + <td>Archivo Java (JAR)</td> + <td><code>application/java-archive</code></td> + </tr> + <tr> + <td><code>.jpeg</code><br> + <code>.jpg</code></td> + <td>Imágenes JPEG</td> + <td><code>image/jpeg</code></td> + </tr> + <tr> + <td><code>.js</code></td> + <td>JavaScript (ECMAScript)</td> + <td><code>application/javascript</code></td> + </tr> + <tr> + <td><code>.json</code></td> + <td>Formato JSON</td> + <td><code>application/json</code></td> + </tr> + <tr> + <td><code>.mid</code><br> + <code>.midi</code></td> + <td>Interfaz Digital de Instrumentos Musicales (MIDI)</td> + <td><code>audio/midi</code></td> + </tr> + <tr> + <td><code>.mpeg</code></td> + <td>Video MPEG</td> + <td><code>video/mpeg</code></td> + </tr> + <tr> + <td><code>.mpkg</code></td> + <td>Paquete de instalación de Apple</td> + <td><code>application/vnd.apple.installer+xml</code></td> + </tr> + <tr> + <td><code>.odp</code></td> + <td>Documento de presentación de OpenDocument</td> + <td><code>application/vnd.oasis.opendocument.presentation</code></td> + </tr> + <tr> + <td><code>.ods</code></td> + <td>Hoja de Cálculo OpenDocument</td> + <td><code>application/vnd.oasis.opendocument.spreadsheet</code></td> + </tr> + <tr> + <td><code>.odt</code></td> + <td>Documento de texto OpenDocument</td> + <td><code>application/vnd.oasis.opendocument.text</code></td> + </tr> + <tr> + <td><code>.oga</code></td> + <td>Audio OGG</td> + <td><code>audio/ogg</code></td> + </tr> + <tr> + <td><code>.ogv</code></td> + <td>Video OGG</td> + <td><code>video/ogg</code></td> + </tr> + <tr> + <td><code>.ogx</code></td> + <td>OGG</td> + <td><code>application/ogg</code></td> + </tr> + <tr> + <td><code>.pdf</code></td> + <td>Adobe <a href="https://acrobat.adobe.com/us/en/why-adobe/about-adobe-pdf.html">Portable Document Format</a> (PDF)</td> + <td><code>application/pdf</code></td> + </tr> + <tr> + <td><code>.ppt</code></td> + <td>Microsoft PowerPoint</td> + <td><code>application/vnd.ms-powerpoint</code></td> + </tr> + <tr> + <td><code>.rar</code></td> + <td>Archivo RAR</td> + <td><code>application/x-rar-compressed</code></td> + </tr> + <tr> + <td><code>.rtf</code></td> + <td>Formato de Texto Enriquecido (RTF)</td> + <td><code>application/rtf</code></td> + </tr> + <tr> + <td><code>.sh</code></td> + <td>Script Bourne shell</td> + <td><code>application/x-sh</code></td> + </tr> + <tr> + <td><code>.svg</code></td> + <td>Gráficos Vectoriales (SVG)</td> + <td><code>image/svg+xml</code></td> + </tr> + <tr> + <td><code>.swf</code></td> + <td><a href="https://en.wikipedia.org/wiki/SWF">Small web format</a> (SWF) o Documento Adobe Flash</td> + <td><code>application/x-shockwave-flash</code></td> + </tr> + <tr> + <td><code>.tar</code></td> + <td>Aerchivo Tape (TAR)</td> + <td><code>application/x-tar</code></td> + </tr> + <tr> + <td><code>.tif<br> + .tiff</code></td> + <td>Formato de archivo de imagen etiquetado (TIFF)</td> + <td><code>image/tiff</code></td> + </tr> + <tr> + <td><code>.ttf</code></td> + <td>Fuente TrueType</td> + <td><code>font/ttf</code></td> + </tr> + <tr> + <td><code>.vsd</code></td> + <td>Microsft Visio</td> + <td><code>application/vnd.visio</code></td> + </tr> + <tr> + <td><code>.wav</code></td> + <td>Formato de audio de forma de onda (WAV)</td> + <td><code>audio/x-wav</code></td> + </tr> + <tr> + <td><code>.weba</code></td> + <td>Audio WEBM</td> + <td><code>audio/webm</code></td> + </tr> + <tr> + <td><code>.webm</code></td> + <td>Video WEBM</td> + <td><code>video/webm</code></td> + </tr> + <tr> + <td><code>.webp</code></td> + <td>Imágenes WEBP</td> + <td><code>image/webp</code></td> + </tr> + <tr> + <td><code>.woff</code></td> + <td>Formato de fuente abierta web (WOFF)</td> + <td><code>font/woff</code></td> + </tr> + <tr> + <td><code>.woff2</code></td> + <td>Formato de fuente abierta web (WOFF)</td> + <td><code>font/woff2</code></td> + </tr> + <tr> + <td><code>.xhtml</code></td> + <td>XHTML</td> + <td><code>application/xhtml+xml</code></td> + </tr> + <tr> + <td><code>.xls</code></td> + <td>Microsoft Excel</td> + <td><code>application/vnd.ms-excel</code></td> + </tr> + <tr> + <td><code>.xml</code></td> + <td><code>XML</code></td> + <td><code>application/xml</code></td> + </tr> + <tr> + <td><code>.xul</code></td> + <td>XUL</td> + <td><code>application/vnd.mozilla.xul+xml</code></td> + </tr> + <tr> + <td><code>.zip</code></td> + <td>Archivo ZIP</td> + <td><code>application/zip</code></td> + </tr> + <tr> + <td><code>.3gp</code></td> + <td>Contenedor de audio/video <a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP</a></td> + <td><code>video/3gpp</code><br> + <code>audio/3gpp</code> if it doesn't contain video</td> + </tr> + <tr> + <td><code>.3g2</code></td> + <td>Contenedor de audio/video <a href="https://en.wikipedia.org/wiki/3GP_and_3G2">3GPP2</a></td> + <td><code>video/3gpp2</code><br> + <code>audio/3gpp2</code> if it doesn't contain video</td> + </tr> + <tr> + <td><code>.7z</code></td> + <td>Archivo <a href="https://en.wikipedia.org/wiki/7-Zip">7-zip</a></td> + <td><code>application/x-7z-compressed</code></td> + </tr> + </tbody> +</table> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p>El <strong>tipo Extensiones multipropósito de Correo de Internet (MIME)</strong> es una forma estandarizada de indicar la naturaleza y el formato de un documento, archivo o conjunto de datos. Está definido y estandarizado en <a href="https://tools.ietf.org/html/rfc6838">IETF RFC 6838</a>. La <a href="https://www.iana.org/">Autoridad de Números Asignados de Internet (IANA)</a> 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 <a href="https://www.iana.org/assignments/media-types/media-types.xhtml">tipos de medios (Media Types)</a>.</p> + +<p>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.</p> + +<h2 id="Sintaxis">Sintaxis</h2> + +<h3 id="Estructura_general">Estructura general</h3> + +<pre class="syntaxbox">tipo/subtipo</pre> + +<p>La estructura de un tipo MIME es muy simple; consiste en un tipo y un subtipo, dos cadenas, separadas por un <code>'/'</code>. No se permite espacio. El <em>tipo </em>representa la categoría y puede ser de tipo <em>discreto </em>o <em>multiparte</em>. El <em>subtipo </em>es específico para cada tipo.</p> + +<p>Un tipo MIME no distingue entre mayúsculas y minúsculas, pero tradicionalmente se escribe todo en minúsculas.</p> + +<h3 id="Tipos_discretos">Tipos discretos</h3> + +<pre class="syntaxbox">text/plain +text/html +image/jpeg +image/png +audio/mpeg +audio/ogg +audio/* +video/mp4 +application/octet-stream +…</pre> + +<p>Los tipos <em>discretos </em>indican la categoría del documento, puede ser uno de los siguientes:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Tipo</th> + <th scope="col">Descripción</th> + <th scope="col">Ejemplo de subtipos típicos</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>text</code></td> + <td>Representa cualquier documento que contenga texto y es teóricamente legible por humanos</td> + <td><code>text/plain</code>, <code>text/html</code>, <code>text/css, text/javascript</code></td> + </tr> + <tr> + <td><code>image</code></td> + <td>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.</td> + <td><code>image/gif</code>, <code>image/png</code>, <code>image/jpeg</code>, <code>image/bmp</code>, <code>image/webp</code></td> + </tr> + <tr> + <td><code>audio</code></td> + <td>Representa cualquier tipo de archivos de audio</td> + <td><code>audio/midi</code>, <code>audio/mpeg, audio/webm, audio/ogg, audio/wav</code></td> + </tr> + <tr> + <td><code>video</code></td> + <td>Representa cualquier tipo de archivos de video</td> + <td><code>video/webm</code>, <code>video/ogg</code></td> + </tr> + <tr> + <td><code>application</code></td> + <td>Representa cualquier tipo de datos binarios.</td> + <td><code>application/octet-stream</code>, <code>application/pkcs12</code>, <code>application/vnd.mspowerpoint</code>, <code>application/xhtml+xml</code>, <code>application/xml</code>, <code>application/pdf</code></td> + </tr> + </tbody> +</table> + +<p>Para documentos de texto sin subtipo específico, se debe usar <code>text/plain</code>. De forma similar, para los documentos binarios sin subtipo específico o conocido, se debe usar <code>application/octet-stream</code>.</p> + +<h3 id="Tipos_multiparte">Tipos multiparte</h3> + +<pre class="syntaxbox">multipart/form-data +multipart/byteranges</pre> + +<p id="sect1">Los tipos de <em>partes múltiples </em>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 <code>multipart/form-data</code>, que se utilizan en relación con <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms">formularios HTML</a> y el método {{HTTPMethod("POST")}}, y <code>multipart/byteranges</code>, que se utilizan junto con el mensaje de estado de <code>Contenido Parcial</code> {{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.)</p> + +<h2 id="Tipos_MIME_importantes_para_desarrolladores_Web">Tipos MIME importantes para desarrolladores Web</h2> + +<h3 id="applicationoctet-stream"><code>application/octet-stream</code></h3> + +<p>Este es el valor predeterminado para un archivo binario. Como realmente significa un <em>archivo binario desconocido</em>, 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 <code>attachment</code> y proponen un archivo 'Guardar como'.</p> + +<h3 id="textplain"><code>text/plain</code></h3> + +<p>Este es el valor predeterminado para los archivos de texto. Incluso si realmente significa un archivo textual desconocido, los navegadores asumen que pueden mostrarlo.</p> + +<div class="note"> +<p>Tenga en cuenta que <code>text/plain</code> no significa <em>cualquier tipo de datos textuales</em>. 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 <code>text/plain</code> de un elemento {{HTMLElement("link")}} que declara archivos CSS, no lo reconocerán como un archivo CSS válido si se presenta con <code>text/plain</code>. Se debe usar el tipo MIME CSS <code>text/css</code>.</p> +</div> + +<h3 id="textcss"><code>text/css</code></h3> + +<p>Todos los archivos CSS que deban interpretarse como tales en una página web <strong>deben </strong>ser de los archivos de <code>text/css</code>. A menudo, los servidores no reconocen los archivos con el sufijo <code>.css</code> como archivos CSS y los envían con tipo MIME <code>text/plain</code> o <code>application/octet-stream</code>: 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.</p> + +<h3 id="texthtml"><code>text/html</code></h3> + +<p>Todo el contenido HTML debe ser servido con este tipo. Los tipos MIME alternativos para XHTML, como <code>application/xml+html</code>, son en su mayoría inútiles hoy en día (HTML5 unificó estos formatos).</p> + +<h3 id="Tipos_de_imágenes">Tipos de imágenes</h3> + +<p>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:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Tipo MIME</th> + <th scope="col">Tipo de imagen</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>image/gif</code></td> + <td>Imágenes GIF (compresión sin pérdida, reemplazada por PNG)</td> + </tr> + <tr> + <td><code>image/jpeg</code></td> + <td>Imágenes JPEG</td> + </tr> + <tr> + <td><code>image/png</code></td> + <td>Imágenes PNG</td> + </tr> + <tr> + <td><code>image/svg+xml</code></td> + <td>Imágenes SVG (imágenes vectoriales)</td> + </tr> + </tbody> +</table> + + + +<p>Existe una discusión para agregar WebP (<code>image/webp</code>) 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.</p> + +<p>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 <code>image/x-icon</code>.</p> + + + +<h3 id="Tipos_de_audio_y_video">Tipos de audio y video</h3> + +<p>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 <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats">formatos de medios compatibles con los elementos de audio y video HTML</a> explican tanto los códecs como los formatos de contenedor que se pueden usar.</p> + +<p>El tipo MIME de dichos archivos representa principalmente los formatos de contenedor y los más comunes en un contexto web son:</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Tipo MIME</th> + <th scope="col">Tipo de audio o video</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>audio/wave</code><br> + <code>audio/wav</code><br> + <code>audio/x-wav</code><br> + <code>audio/x-pn-wav</code></td> + <td>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).</td> + </tr> + <tr> + <td><code>audio/webm</code></td> + <td>Un archivo de audio en formato de contenedor WebM. Vorbis y Opus son los códecs de audio más comunes.</td> + </tr> + <tr> + <td><code>video/webm</code></td> + <td>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.</td> + </tr> + <tr> + <td><code>audio/ogg</code></td> + <td>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.</td> + </tr> + <tr> + <td><code>video/ogg</code></td> + <td>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.</td> + </tr> + <tr> + <td><code>application/ogg</code></td> + <td>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.</td> + </tr> + </tbody> +</table> + +<h3 id="multipartform-data"><code>multipart/form-data</code></h3> + +<p>El tipo de datos <code>multipart/form-data</code> se puede usar al enviar el contenido de un <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms">formulario HTML</a> 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 <code>'--'</code>). 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).</p> + +<pre class="syntaxbox">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-- + +</pre> + +<p>El siguiente formulario:</p> + +<pre class="brush: html"><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></pre> + +<p>enviará este mensaje:</p> + +<pre>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-- + +</pre> + +<h3 id="multipartbyteranges"><code>multipart/byteranges</code></h3> + +<p>El tipo MIME <code>multipart/byteranges</code> se usa en el contexto del envío de respuestas parciales al navegador. Cuando se envía el código de estado de <code>Contenido Parcial</code> {{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 <code>boundary</code> 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.</p> + +<pre><code>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--</code></pre> + +<h2 id="Importancia_de_establecer_el_tipo_MIME_correcto">Importancia de establecer el tipo MIME correcto</h2> + +<p>La mayoría de los servidores web envían recursos de tipo desconocido utilizando el tipo MIME predeterminado <code>application/octet-stream</code>. 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:</p> + +<ul> + <li> + <p>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 <code>application/x-rar-compressed</code>, los usuarios no habrán definido una acción predeterminada útil para ellos.</p> + </li> + <li> + <p>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 <a href="https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements">usar el tipo correcto para audio y video</a>.</p> + </li> + <li> + <p>Tipos de archivos propietarios. Preste especial atención al servir un tipo de archivo propietario. Evite el uso de <code>application/octet-stream</code> 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.</p> + </li> +</ul> + +<h2 id="Olfateo_MIME_sniffing">Olfateo MIME (sniffing)</h2> + +<p>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")}}.</p> + +<h2 id="Otros_métodos_de_transporte_de_tipo_de_documento">Otros métodos de transporte de tipo de documento</h2> + +<p>Los tipos MIME no son la única forma de transmitir la información del tipo de documento:</p> + +<ul> + <li>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.</li> + <li>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.</li> +</ul> + + + +<h2 id="Ver_también">Ver también</h2> + +<ul> + <li><a href="/en-US/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types">Configurar correctamente los tipos MIME del servidor</a></li> + <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats">Formatos de medios compatibles con los elementos de audio y video HTML</a></li> + <li> + <p><a href="https://www.iana.org/assignments/media-types/application/json">https://www.iana.org/assignments/media-types/application/json</a></p> + </li> +</ul> |