En la actualidad, hay situaciones (para guardar una documentación en formato pdf o un documento financiero) donde es posible que desee un hipervínculo que conduzca a un archivo para presentar un cuadro de diálogo de SaveAs en el navegador. Maneras de hacer que existan. Sin embargo, el soporte escaso del navegador hace que su uso sea un paseo por el campo minero. Forzar SaveAs usando javascript en Internet Explorer Mediante javascript puede proporcionar un diálogo para guardar la página que se muestra actualmente (si el usuario está buscando a través de Internet Explorer en su página). Esto se hace a través del siguiente código: Guardar este pagelt / a Sin embargo, por lo general desea guardar otro archivo, el archivo de un hipervínculo lleva a. Para hacer que javascript no es suficiente (al menos no hay tal manera estándar) y algo debe hacerse en el servidor. Forzar SaveAs usando el encabezado HTTP Para obligar al navegador a mostrar el cuadro de diálogo SaveAs al hacer clic en un hipervínculo hay que incluir el siguiente encabezado en la respuesta HTTP del archivo que se va a descargar: Content-Disposition: attachment filenameltfile name. extgt Donde ltfile nombre. Extgt es el nombre de archivo que desea que aparezca en el cuadro de diálogo SaveAs (como finances. xls o mortgage. pdf) - sin símbolos lt y gt. Tienes que tener en cuenta lo siguiente: El nombre de archivo debe estar en US-ASCII charset y no debe contener caracteres especiales: lt gt /. . espacio. El nombre de archivo no debe tener ninguna información de ruta de acceso de directorio especificada. El nombre de archivo debe estar entre comillas dobles, pero la mayoría de los navegadores soportarán nombres de archivo sin comillas dobles. Los antiguos navegadores también requerían lo siguiente (no es necesario hoy en día, pero para una solución a prueba de tonto podría valer la pena hacerlo): El encabezado de Content-Type debe estar antes de Content-Disposition. El encabezado Content-Type debe referirse a un tipo MIME desconocido (al menos hasta que los navegadores antiguos desaparezcan). Uso detallado del soporte de Content-Disposition en Internet Explorer Parece que Internet Explorer tiene el peor historial del soporte de encabezado Content-Disposition. La característica tenía muchas vulnerabilidades de seguridad y como resultado Microsoft cambió el código muchas veces a veces rompiéndolo por completo. La práctica ha demostrado que el código de descarga utiliza un analizador de encabezado HTTP diferente. Y si ese analizador no tiene éxito en el manejo de todas las líneas de encabezado, IE no podrá descargar el archivo en absoluto. Internet Explorer 9.0 En función de la versión de WinInet. dll puede fallar al descargar el archivo con nombre de archivo que contiene los siguientes caracteres especiales: lt gt /. . espacio. Artículos de Microsoft Knowledgebase: 9491974 El campo Content-Type Header El objetivo del campo Content-Type es describir los datos contenidos en el cuerpo lo suficiente como para que el agente de usuario receptor pueda seleccionar un agente o mecanismo apropiado para presentar los datos al usuario, O tratar de otra manera los datos de una manera apropiada. El campo de encabezado Content-Type se utiliza para especificar la naturaleza de los datos en el cuerpo de una entidad, proporcionando identificadores de tipo y subtipo y proporcionando información auxiliar que puede ser necesaria para ciertos tipos. Después de los nombres de tipo y subtipo, el resto del campo de encabezado es simplemente un conjunto de parámetros, especificado en una notación de atributo / valor. El conjunto de parámetros significativos difiere para los diferentes tipos. El ordenamiento de los parámetros no es significativo. Entre los parámetros definidos se encuentra un parámetro charset mediante el cual se puede declarar el juego de caracteres utilizado en el cuerpo. Los comentarios están permitidos de acuerdo con las reglas RFC 822 para los campos de cabecera estructurados. En general, el tipo de contenido de nivel superior se utiliza para declarar el tipo general de datos, mientras que el subtipo especifica un formato específico para ese tipo de datos. Por lo tanto, un Content-Type de imagen / xyz es suficiente para decirle a un agente de usuario que los datos son una imagen, incluso si el agente de usuario no tiene conocimiento del formato de imagen específico xyz. Dicha información puede utilizarse, por ejemplo, para decidir si se mostrarán o no a un usuario los datos sin procesar de un subtipo no reconocido, tal acción podría ser razonable para subtipos de texto no reconocidos, pero no para subtipos no reconocidos de imagen o audio. Por esta razón, los subtipos registrados de audio, imagen, texto y video, no deben contener información incrustada que sea realmente de un tipo diferente. Dichos tipos de compuestos se deben representar usando los tipos de múltiples partes o de aplicación. Los parámetros son modificadores del subtipo de contenido y no afectan fundamentalmente los requisitos del sistema host. Aunque la mayoría de los parámetros tienen sentido sólo con ciertos tipos de contenido, otros son globales en el sentido de que pueden aplicarse a cualquier subtipo. Por ejemplo, el parámetro boundary tiene sentido sólo para el tipo de contenido multipart, pero el parámetro charset puede tener sentido con varios tipos de contenido. En este documento se define un conjunto inicial de siete tipos de contenido. Este conjunto de nombres de nivel superior está destinado a ser sustancialmente completo. Se espera que las adiciones al conjunto más grande de tipos soportados puedan lograrse generalmente mediante la creación de nuevos subtipos de estos tipos iniciales. En el futuro, más tipos de nivel superior sólo se pueden definir mediante una extensión a este estándar. Si se utiliza otro tipo primario por cualquier razón, debe darse un nombre que comience con X - para indicar su estado no estándar y para evitar un posible conflicto con un nombre oficial futuro. En la notación ampliada BNF de RFC 822. un valor de campo de encabezado Content-Type se define como sigue: Tenga en cuenta que la definición de tspecials es la misma que la definición de RFC 822 de especiales con la adición de los tres caracteres /, y. Observe también que una especificación de subtipo es OBLIGATORIA. No hay subtipos predeterminados. Los nombres de tipo, subtipo y parámetro no distinguen entre mayúsculas y minúsculas. Por ejemplo, TEXT, Text y TeXt son todos equivalentes. Los valores de los parámetros son normalmente sensibles a mayúsculas y minúsculas, pero ciertos parámetros se interpretan como insensibles a las mayúsculas y minúsculas, dependiendo del uso que se pretenda utilizar. (Por ejemplo, los límites de varias partes distinguen mayúsculas de minúsculas, pero el tipo de acceso para el mensaje / External-body no distingue entre mayúsculas y minúsculas). Más allá de esta sintaxis, la única restricción en la definición de subtipos es el deseo de que sus usos no conflicto. Es decir, sería indeseable tener dos comunidades diferentes usando Content-Type: application / foobar para significar dos cosas diferentes. El proceso de definición de nuevos subtipos de contenido, entonces, no pretende ser un mecanismo para imponer restricciones, sino simplemente un mecanismo para publicitar los usos. Por lo tanto, existen dos mecanismos aceptables para definir nuevos subtipos de Tipo de Contenido: Los valores privados (que comienzan con X-) pueden definirse bilateralmente entre dos agentes cooperantes sin registro externo o estandarización. Los nuevos valores estándar deben estar documentados, registrados y aprobados por la IANA, como se describe en el Apéndice F. Cuando se destinen al uso público, los formatos a los que se refieren también deben estar definidos por una especificación publicada y posiblemente ofrecidos para la normalización. Los siete tipos de contenido predefinidos iniciales estándar se detallan en la mayor parte de este documento. Son: texto información textual. El subtipo principal, llano, indica texto sin formato (no formateado). No se requiere ningún software especial para obtener el significado completo del texto, aparte de la compatibilidad con el conjunto de caracteres indicado. Los subtipos se utilizarán para el texto enriquecido en formularios en los que el software de aplicación puede mejorar la apariencia del texto, pero dicho software no debe ser necesario para obtener la idea general del contenido. Posibles subtipos incluyen por tanto cualquier formato de procesador de textos legible. Un subtipo muy simple y portátil, richtext, se define en este documento. Datos multipart consistentes en múltiples partes de tipos de datos independientes. Se definen cuatro subtipos iniciales, incluyendo el subtipo primario mixto, alternativo para representar los mismos datos en múltiples formatos, paralelo para partes destinadas a ser vistas simultáneamente, y digerir para entidades multiparte en las que cada parte es de tipo mensaje. Mensaje un mensaje encapsulado. Un cuerpo de mensaje de tipo de contenido es en sí mismo un mensaje conformado RFC 822 totalmente formateado que puede contener su propio campo de encabezado Content-Type diferente. El subtipo principal es rfc822. El subtipo parcial se define para los mensajes parciales, para permitir la transmisión fragmentada de cuerpos que se cree que son demasiado grandes para pasar a través de las instalaciones de transporte de correo. Otro subtipo, Externo-cuerpo, se define para especificar cuerpos grandes por referencia a una fuente de datos externa. Datos de imagen de imagen. La imagen requiere un dispositivo de visualización (como una pantalla gráfica, una impresora o una máquina de fax) para ver la información. Los subtipos iniciales se definen para dos formatos de imagen ampliamente utilizados, jpeg y gif. Datos de audio y audio, con subtipo inicial básico. El audio requiere un dispositivo de salida de audio (como un altavoz o un teléfono) para mostrar el contenido. Datos de vídeo. El video requiere la capacidad de mostrar imágenes en movimiento, incluyendo típicamente hardware y software especializados. El subtipo inicial es mpeg. Aplicación de algún otro tipo de datos, típicamente datos binarios no interpretados o información para ser procesados por una aplicación basada en correo. El subtipo principal, octet-stream, debe utilizarse en el caso de datos binarios no interpretados, en cuyo caso la acción más sencilla recomendada es ofrecer escribir la información en un archivo para el usuario. Se definen dos subtipos adicionales, ODA y PostScript, para el transporte de documentos ODA y PostScript en los cuerpos. Otros usos esperados para la aplicación incluyen hojas de cálculo, datos para sistemas de programación basados en correo electrónico y idiomas para correo electrónico activo (computacional). (Tenga en cuenta que el correo electrónico activo implica varias consideraciones de seguridad, que se tratan más adelante en este documento, en particular en el contexto de la aplicación / PostScript.) Los mensajes predeterminados RFC 822 se escriben en este protocolo como texto sin formato en el conjunto de caracteres US-ASCII. Explícitamente especificado como Content-type: text / plain charsetus-ascii. Si no se especifica Content-Type, ya sea por error o por un agente de usuario anterior, se asume que este valor predeterminado. En presencia de un campo de encabezado MIME-Version, un agente de usuario receptor también puede asumir que el texto US-ASCII simple era la intención de los remitentes. En ausencia de una especificación MIME-Version, el texto US-ASCII debe ser asumido, pero la intención de los remitentes podría haber sido de otra manera. Debe observarse que la lista de valores de Content-Type dada aquí puede ser aumentada en el tiempo, vía Los mecanismos descritos anteriormente, y que se espera que el conjunto de subtipos crezca sustancialmente. Cuando un lector de correo encuentra un correo con un valor de tipo de contenido desconocido, generalmente lo tratará como equivalente a application / octet-stream, como se describe más adelante en este documento.19 Apéndices 19.1 Internet Media Type message / http y application / http Además A la definición del protocolo HTTP / 1.1, este documento sirve como la especificación para el tipo de medios de comunicación de Internet mensaje / http y application / http. El tipo de mensaje / http puede utilizarse para incluir una sola solicitud HTTP o mensaje de respuesta, siempre que obedezca las restricciones MIME para todos los tipos de mensajes con respecto a la longitud de línea y las codificaciones. El tipo application / http puede usarse para incluir una tubería de uno o más mensajes de solicitud o respuesta HTTP (no entremezclados). Lo siguiente debe ser registrado con IANA 17. 19.2 Internet Media Type multipart / byteranges Cuando un mensaje de respuesta HTTP 206 (Contenido parcial) incluye el contenido de múltiples rangos (una respuesta a una solicitud de múltiples intervalos que no se superponen), éstos se transmiten Como un cuerpo de mensaje de partes múltiples. El tipo de medio para este propósito se denomina multipart / byteranges. El tipo de material multipart / byteranges incluye dos o más partes, cada una con sus propios campos Content-Type y Content-Range. El parámetro de límite requerido especifica la cadena de límite utilizada para separar cada parte del cuerpo. HTTP / 1.1 206 Contenido parcial Fecha: Wed, 15 Nov 1995 06:25:24 GMT Última modificación: Mié, 15 Nov 1995 04:58:08 GMT Tipo de contenido: multipart / byteranges boundaryTHISSTRINGSEPARATES --THISSTRINGSEPARATES Tipo de contenido: application / Pdf Contenido-gama: bytes 500-999 / 8000 el primer rango. --THISSTRINGSEPARATES 19.3 Aplicaciones Tolerantes Aunque este documento especifica los requisitos para la generación de mensajes HTTP / 1.1, no todas las aplicaciones Correcta en su aplicación. Por lo tanto, recomendamos que las aplicaciones operacionales sean tolerantes a las desviaciones siempre que dichas desviaciones puedan interpretarse sin ambigüedades. Los clientes DEBEN ser tolerantes en el análisis de la línea de estado y los servidores tolerantes al analizar la línea de solicitud. En particular, deben aceptar cualquier cantidad de caracteres SP o HT entre campos, a pesar de que sólo un único SP es necesario. El terminador de línea para los campos de encabezado de mensaje es la secuencia CRLF. Sin embargo, recomendamos que las aplicaciones, al analizar dichos encabezados, reconozcan un solo LF como un terminador de línea e ignoren el CR principal. El conjunto de caracteres de un cuerpo de entidad DEBE ser etiquetado como el denominador común más bajo de los códigos de caracteres utilizados dentro de ese cuerpo, con la excepción de que no etiquetar a la entidad es preferible etiquetar a la entidad con las etiquetas US-ASCII o ISO-8859- 1. Véase la sección 3.7.1 y 3.4.1. 19.4 Diferencias entre las entidades HTTP y las entidades RFC 2045 HTTP / 1.1 utiliza muchas de las construcciones definidas para Internet Mail (RFC 822 9) y el Multipurpose Internet Mail Extensiones (MIME 7) para permitir que las entidades sean transmitidas en una variedad abierta de representaciones y con mecanismos extensibles. Sin embargo, RFC 2045 discute el correo, y HTTP tiene algunas características que son diferentes de los descritos en RFC 2045. Estas diferencias fueron cuidadosamente elegidos para optimizar el rendimiento sobre conexiones binarias, para permitir una mayor libertad en el uso de nuevos tipos de medios, para hacer la fecha Comparaciones más fáciles y reconocer la práctica de algunos servidores y clientes HTTP tempranos. Este apéndice describe áreas específicas en las que HTTP difiere del RFC 2045. Proxies y gateways a entornos MIME estrictos DEBEN ser conscientes de estas diferencias y proporcionar las conversiones apropiadas cuando sea necesario. Proxies y gateways de entornos MIME a HTTP también necesitan estar conscientes de las diferencias, ya que algunas conversiones pueden ser necesarias. 19.4.1 MIME-Version HTTP no es un protocolo compatible con MIME. Sin embargo, los mensajes HTTP / 1.1 PUEDEN incluir un solo campo de encabezado general MIME-Version para indicar qué versión del protocolo MIME se utilizó para construir el mensaje. El uso del campo de encabezado MIME-Version indica que el mensaje está en total conformidad con el protocolo MIME (como se define en RFC 20457). Proxies / gateways son responsables de asegurar el cumplimiento total (cuando sea posible) al exportar mensajes HTTP a entornos MIME estrictos. MIME versión 1.0 es el valor predeterminado para su uso en HTTP / 1.1. Sin embargo, el documento y la semántica de mensajes HTTP / 1.1 se definen en este documento y no en la especificación MIME. 19.4.2 Conversión a la Forma Canónica RFC 2045 7 requiere que una entidad de correo de Internet se convierta a forma canónica antes de ser transferido, como se describe en la sección 4 del RFC 2049 48. La Sección 3.7.1 de este documento describe los formularios permitidos para los subtipos de El tipo de medio de texto cuando se transmite a través de HTTP. RFC 2046 requiere que el contenido con un tipo de texto representan los saltos de línea como CRLF y prohíbe el uso de CR o LF fuera de las secuencias de salto de línea. HTTP permite CRLF, CR desnudo y LF desnudo para indicar un salto de línea dentro del contenido de texto cuando un mensaje se transmite a través de HTTP. Donde es posible, un proxy o puerta de enlace de HTTP a un entorno MIME estricto DEBE traducir todas las saltos de línea dentro de los tipos de medios de texto descritos en la sección 3.7.1 de este documento a la forma canónica RFC 2049 de CRLF. Tenga en cuenta, sin embargo, que esto puede ser complicado por la presencia de una Content-Encoding y por el hecho de que HTTP permite el uso de algunos conjuntos de caracteres que no utilizan octetos 13 y 10 para representar CR y LF, como es el caso de algunos Conjuntos de caracteres de varios bytes. Los implementadores deben tener en cuenta que la conversión romperá cualquier suma de comprobación criptográfica aplicada al contenido original a menos que el contenido original ya esté en forma canónica. Por lo tanto, la forma canónica se recomienda para cualquier contenido que utiliza dichas sumas de comprobación en HTTP. 19.4.3 Conversión de formatos de fecha HTTP / 1.1 utiliza un conjunto restringido de formatos de fecha (sección 3.3.1) para simplificar el proceso de comparación de fechas. Proxies y gateways de otros protocolos DEBERÁ asegurarse de que cualquier campo de encabezado de fecha presente en un mensaje se ajuste a uno de los formatos HTTP / 1.1 y reescribir la fecha si es necesario. 19.4.4 Introducción de la codificación de contenido La RFC 2045 no incluye ningún concepto equivalente al campo de encabezado Content-Encoding de HTTP / 1.1s. Dado que esto actúa como un modificador en el tipo de medio, proxies y pasarelas de HTTP a MIME-compliant protocolos DEBE cambiar el valor del campo de encabezado Content-Type o decodificar el cuerpo de la entidad antes de reenviar el mensaje. (Algunas aplicaciones experimentales de Content-Type para el correo de Internet han utilizado un parámetro de tipo de medios de conversionsltcontent-coding para realizar una función equivalente a Content-Encoding.) Sin embargo, este parámetro no forma parte del RFC 2045. 19.4.5 No Content - HTTP de transferencia de codificación no utiliza el campo Content-Transfer-Encoding (CTE) del RFC 2045. Proxies y gateways de protocolos compatibles con MIME a HTTP DEBEN eliminar cualquier codificación CTE (citado-imprimible o base64) sin identidad antes de entregar el Respuesta a un cliente HTTP. Proxies y pasarelas de HTTP a protocolos compatibles con MIME son responsables de asegurar que el mensaje esté en el formato y codificación correctos para un transporte seguro en ese protocolo, donde el transporte seguro es definido por las limitaciones del protocolo que se está utilizando. Este proxy o puerta de enlace DEBE etiquetar los datos con un adecuado Content-Transfer-Encoding si hacerlo mejorará la probabilidad de transporte seguro sobre el protocolo de destino. 19.4.6 Introducción de Transfer-Encoding HTTP / 1.1 introduce el campo de encabezado Transfer-Encoding (sección 14.41). Proxies / gateways DEBE eliminar cualquier transferencia de codificación antes de reenviar un mensaje a través de un MIME-compatible con el protocolo. Un proceso para decodificar la codificación de transferencia fragmentada (sección 3.6) puede representarse en pseudocódigo como: 19.4.7 MHTML y Limitaciones de Longitud de Línea Las implementaciones HTTP que comparten código con implementaciones MHTML 45 necesitan estar conscientes de las limitaciones de longitud de línea MIME. Dado que HTTP no tiene esta limitación, HTTP no dobla líneas largas. Los mensajes MHTML que son transportados por HTTP siguen todas las convenciones de MHTML, incluyendo limitaciones de longitud de línea y plegado, canonicalización, etc., ya que HTTP transporta todos los cuerpos de mensaje como carga útil (ver sección 3.7.2) y no interpreta el contenido ni ninguna línea de encabezado MIME Que podría estar contenido en el mismo. 19.5 Características adicionales Los elementos de protocolo de documento RFC 1945 y RFC 2068 utilizados por algunas implementaciones de HTTP existentes, pero no de forma coherente y correcta en la mayoría de las aplicaciones HTTP / 1.1. Se recomienda a los implementadores que conozcan estas características, pero no pueden confiar en su presencia o interoperabilidad con otras aplicaciones HTTP / 1.1. Algunos de estos describen las características experimentales propuestas, y algunos describen las características que el despliegue experimental encontró falta que ahora se abordan en la especificación básica de HTTP / 1.1. Un número de otros encabezados, como Content-Disposition and Title, de SMTP y MIME también se implementan a menudo (ver RFC 2076 37). 19.5.1 Disposición de contenido El campo de encabezado de respuesta Disposición de contenido se ha propuesto como medio para que el servidor de origen sugiera un nombre de archivo predeterminado si el usuario solicita que el contenido se guarde en un archivo. Este uso se deriva de la definición de Contenido-Disposición en RFC 1806 35. El agente de usuario de recepción NO DEBE respetar ninguna información de ruta de directorio presente en el parámetro filename-parm, que es el único parámetro que se cree que se aplican a implementaciones HTTP en este momento. El nombre de archivo DEBE ser tratado como un componente terminal solamente. Si se utiliza este encabezado en una respuesta con el tipo de contenido application / octet-stream, la sugerencia implícita es que el agente de usuario no debe mostrar la respuesta, sino que introduce directamente una respuesta de guardado como. diálogo. Consulte la sección 15.5 para los problemas de seguridad Content-Disposition. 19.6 Compatibilidad con versiones anteriores Está fuera del alcance de una especificación de protocolo exigir el cumplimiento de las versiones anteriores. HTTP / 1.1 fue deliberadamente diseñado, sin embargo, para facilitar el soporte de versiones anteriores. Cabe señalar que, al momento de redactar esta especificación (1996), esperamos que los servidores comerciales HTTP / 1.1: Y esperamos que los clientes HTTP / 1.1: Para la mayoría de las implementaciones de HTTP / 1.0, cada conexión se establece por El cliente antes de la solicitud y cerrado por el servidor después de enviar la respuesta. Algunas implementaciones implementan la versión Keep-Alive de conexiones persistentes descritas en la sección 19.7.1 del RFC 2068 33. 19.6.1 Cambios desde HTTP / 1.0 Esta sección resume las principales diferencias entre las versiones HTTP / 1.0 y HTTP / 1.1. 19.6.1.1 Cambios en la simplificación de los servidores Web multihomed y la conservación de la IP Los requisitos que los clientes y los servidores soportan en la cabecera de la solicitud del Host, reportan un error si falta la solicitud de Host (sección 14.23) de una solicitud HTTP / 1.1 y Aceptar URIs absolutos (sección 5.1.2) están entre los cambios más importantes definidos por esta especificación. Los clientes HTTP / 1.0 antiguos asumían una relación uno a uno de direcciones IP y servidores, no existía otro mecanismo establecido para distinguir el servidor de una solicitud que la dirección IP a la que se dirigía esa solicitud. Los cambios descritos anteriormente permitirán a Internet, una vez que los clientes HTTP antiguos ya no son comunes, soportar múltiples sitios Web desde una sola dirección IP, simplificando en gran medida los grandes servidores Web operativos, donde la asignación de muchas direcciones IP a un único host ha creado serios problemas . Internet también podrá recuperar las direcciones IP que se han asignado con el único propósito de permitir que los nombres de dominio de propósito especial se utilicen en URL HTTP de nivel raíz. Dada la tasa de crecimiento de la Web y el número de servidores ya implementados, es extremadamente importante que todas las implementaciones de HTTP (incluyendo las actualizaciones de las aplicaciones HTTP / 1.0 existentes) implementen correctamente estos requisitos: 19.6.2 Compatibilidad con HTTP / 1.0 Persistente Conexiones Algunos clientes y servidores tal vez deseen ser compatibles con algunas implementaciones anteriores de conexiones persistentes en clientes y servidores HTTP / 1.0. Las conexiones persistentes en HTTP / 1.0 se negocian explícitamente ya que no son el comportamiento predeterminado. Las implementaciones experimentales HTTP / 1.0 de conexiones persistentes son defectuosas y las nuevas instalaciones en HTTP / 1.1 están diseñadas para solucionar estos problemas. El problema era que algunos clientes 1.0 existentes podrían estar enviando Keep-Alive a un servidor proxy que no entiende la conexión, que entonces lo enviaría erróneamente al siguiente servidor entrante, lo que establecería la conexión Keep-Alive y resultaría en un enlace HTTP / Proxy 1.0 esperando el cierre de la respuesta. El resultado es que los clientes HTTP / 1.0 deben evitar utilizar Keep-Alive cuando hablan con proxies. Sin embargo, hablar con proxies es el uso más importante de las conexiones persistentes, por lo que la prohibición es claramente inaceptable. Por lo tanto, necesitamos algún otro mecanismo para indicar que se desea una conexión persistente, que es seguro de usar incluso cuando se habla con un proxy antiguo que ignora la conexión. Las conexiones persistentes son el valor predeterminado para los mensajes HTTP / 1.1 que introducimos una nueva palabra clave (Connection: close) para declarar la falta de persistencia. Véase la sección 14.10. La forma original HTTP / 1.0 de conexiones persistentes (el encabezado Connection: Keep-Alive y Keep-Alive) está documentada en RFC 2068. 33 19.6.3 Cambios de RFC 2068 Esta especificación ha sido cuidadosamente auditada para corregir y desambiguar el uso de palabras clave RFC 2068 tenía muchos problemas con respecto a las convenciones establecidas en el RFC 2119 34. Se aclaró qué código de error se debe utilizar para los fallos de los servidores entrantes (por ejemplo, los fallos del DNS). (Sección 10.5.5). CREATE tenía una carrera que requería un Etag ser enviado cuando se creó un recurso por primera vez. (Sección 10.2.2). Content-Base fue eliminado de la especificación: no se implementó ampliamente, y no existe una forma sencilla y segura de introducirlo sin un mecanismo de extensión robusto. Además, se utiliza de una manera similar, pero no de forma idéntica en MHTML 45. Transferencia de codificación y la longitud de los mensajes todos interactúan de maneras que requieren la fijación exacta cuando se utiliza la codificación en trozos (para permitir la codificación de transferencia que no puede auto delimitar) Era importante aclarar exactamente cómo se calculan las longitudes de los mensajes. (Secciones 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) Se introdujo un código de contenido de identidad para resolver problemas descubiertos en el almacenamiento en caché. (Sección 3.5) Los valores de calidad de cero deben indicar que no quiero algo que permita a los clientes rechazar una representación. (Sección 3.9) El uso y la interpretación de los números de versión HTTP ha sido aclarado por RFC 2145. Exigir proxies para actualizar las solicitudes a la versión de protocolo más alto que soportan para hacer frente a los problemas descubiertos en las implementaciones HTTP / 1.0 (Sección 3.1) Charset wildcarding se introduce para evitar Explosión de nombres de conjunto de caracteres en aceptar encabezados. (Sección 14.2) Se perdió un caso en el modelo Cache-Control de HTTP / 1.1 s-maxage se introdujo para agregar este caso faltante. (Secciones 13.4, 14.8, 14.9, 14.9.3) La directiva Cache-Control: max-age no se definió correctamente para las respuestas. (Sección 14.9.3) Hay situaciones en las que un servidor (especialmente un proxy) no conoce toda la longitud de una respuesta, pero es capaz de atender una petición de byterange. Por lo tanto, necesitamos un mecanismo para permitir byteranges con un rango de contenido que no indica la longitud total del mensaje. (Sección 14.16) Las respuestas de solicitud de rango se volverían muy detalladas si todos los metadatos fueran siempre devueltos permitiendo que el servidor sólo envíe encabezados necesarios en una respuesta 206, este problema se puede evitar. (Sección 10.2.7, 13.5.3 y 14.27) Solucionar el problema con las solicitudes de rango insatisfechas hay dos casos: problemas sintácticos, y el rango no existe en el documento. El código de estado 416 era necesario para resolver esta ambigüedad necesaria para indicar un error para una solicitud de rango de bytes que cae fuera del contenido real de un documento. (Sección 10.4.17) 14.16) Reescriba los requisitos de transmisión de mensajes para que sea mucho más difícil para los implementadores que se equivoquen, ya que las consecuencias de los errores aquí pueden tener un impacto significativo en Internet, y para hacer frente a los siguientes problemas: El encabezado Expect y el código de estado 417. Las correcciones de requisitos de transmisión de mensajes se encuentran en las secciones 8.2, 10.4.18, 8.1.2.2. 13.11. Y 14.20. Los proxies deben ser capaces de agregar Content-Length cuando sea apropiado. (Sección 13.5.2) Limpiar la confusión entre 403 y 404 respuestas. (Sección 10.4.4, 10.4.5 y 10.4.11) Las advertencias podrían almacenarse en caché incorrectamente o no actualizarse adecuadamente. (Sección 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3 y 14.46). Advertencia también necesitaba ser un encabezado general, ya que PUT u otros métodos pueden necesitarlo en las solicitudes. Transferencia de la codificación tenía problemas significativos, en particular con las interacciones con la codificación en trozos. La solución es que las codificaciones de transferencia lleguen a ser tan completas como las codificaciones de contenido. Esto implica agregar un registro IANA para codificaciones de transferencia (separadas de las codificaciones de contenido), un nuevo campo de cabecera (TE) y habilitar los encabezados de los remolques en el futuro. La codificación de transferencia es un beneficio de rendimiento importante, por lo que valió la pena fijar 39. TE también resuelve otro problema oscuro, interoperabilidad descendente que podría haber ocurrido debido a las interacciones entre los remolques de autenticación, la codificación de chunked y los clientes HTTP / 1.0. 1. y 14.39) Los métodos PATCH, LINK, UNLINK se definieron pero no se implementaron comúnmente en las versiones anteriores de esta especificación. Véase RFC 2068 33. Los campos de cabecera Alternates, Content-Version, Derived-From, Link, URI, Public y Content-Base se definieron en versiones anteriores de esta especificación, pero no se implementan comúnmente. Véase RFC 2068 33.
No comments:
Post a Comment