<a href="../es/howto/http2.html" title="Español"> es </a> |
<a href="../fr/howto/http2.html" hreflang="fr" rel="alternate" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Esta traducción podría estar
- obsoleta. Consulte la versión en inglés de la
- documentación para comprobar si se han producido cambios
- recientemente.</div>
-
- <p>Esta es la guía para configurar HTTP/2 en Apache httpd. Ésta
- característica está <em>lista en produción</em> así que es de esperar que las
- interfaces y las directivas se mantengan consistentes en cada verión.
+
+ <p>
+ Esta es la guía para configurar HTTP/2 en Apache httpd. Ésta característica
+ está <em>lista en produción</em> así que es de esperar que las interfaces
+ y las directivas se mantengan consistentes en cada verión.
</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#protocol">El protocolo HTTP/2</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#clients">Clientes</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#tools">Herramientas útiles para depurar HTTP/2</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#push">Server Push</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#earlyhints">"Early Hints"</a></li>
</ul><h3>Consulte también</h3><ul class="seealso"><li><code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code></li><li><a href="#comments_section">Comentarios</a></li></ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<p>HTTP/2 es la evolución del protocolo de la capa de aplicación con más
- éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red. No cambia la característica fundamental de HTTP, la semántica. Todavía hay solicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.</p>
+ éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red.
+ No cambia la característica fundamental de HTTP, la semántica. Todavía hay
+ olicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así
+ que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.</p>
<p>Se ha escrito mucho sobre HTTP/2 y de cómo funciona. La norma más
estándar es, por supuesto, su
<a href="https://tools.ietf.org/html/rfc7540">RFC 7540</a>
(<a href="http://httpwg.org/specs/rfc7540.html"> también disponible en un
- formato más legible, YMMV</a>). Así que, ahí encontrará toda la especificación del protocolo.</p>
+ formato más legible, YMMV</a>). Así que, ahí encontrará toda la especificación
+ del protocolo.</p>
<p>Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor
entender primero <em>qué</em> se quiere hacer y después leer el RFC sobre
<p>Si le parece demasiado largo, o no lo ha leido, hay algunos términos
y elementos a tener en cuenta cuando lea este documento:</p>
<ul>
- <li>HTTP/2 es un <strong>protocolo binario</strong>, al contrario que HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea legible (por ejemplo capturando el tráfico de red) mientras que para HTTP/2 no. Más información en el FAQ oficial <a href="https://http2.github.io/faq/#why-is-http2-binary">¿Por qué es binario HTTP/2?</a></li>
+ <li>HTTP/2 es un <strong>protocolo binario</strong>, al contrario que
+ HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea
+ legible (por ejemplo capturando el tráfico de red) mientras que para
+ HTTP/2 no. Más información en el FAQ oficial
+ <a href="https://http2.github.io/faq/#why-is-http2-binary">¿Por qué es
+ binario HTTP/2?</a></li>
- <li><strong>h2</strong> es HTTP/2 sobre TLS (negociación de protocolo a través de ALPN).</li>
+ <li><strong>h2</strong> es HTTP/2 sobre TLS (negociación de protocolo a
+ través de ALPN).</li>
<li><strong>h2c</strong> es HTTP/2 sobre TCP.</li>
- <li>Un <strong>frame</strong> es la unidad más pequeña de comunicación dentro de una conexión HTTP/2, que consiste en una cabecera y una secuencia de octetos de longitud variable estructurada de acuerdo con el tipo de frame. Más información en la documentación oficial <a href="http://httpwg.org/specs/rfc7540.html#FramingLayer">Sección de Capa de Frame</a>.</li>
-
- <li>Un <strong>stream</strong> es un flujo bidireccional de frames dentro de una conexión HTTP/2. El concepto correspondiente en HTTP 1.1 es un intercambio de mensajes de solicitud/respuesta. Más información en la documentación oficial <a href="http://httpwg.org/specs/rfc7540.html#StreamsLayer">Sección Capa de Stream</a>.</li>
-
- <li>HTTP/2 es capaz de llevar <strong>múltiples streams</strong> de datos sobre la misma conexión TCP, evitando la clásica solicitud lenta "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones TCP para cada solicitud/respuesta (KeepAlive parcheó el problema en HTTP 1.1 pero no lo resolvió completamente).</li>
+ <li>Un <strong>frame</strong> es la unidad más pequeña de comunicación
+ dentro de una conexión HTTP/2, que consiste en una cabecera y una secuencia
+ de octetos de longitud variable estructurada de acuerdo con el tipo de
+ frame. Más información en la documentación oficial
+ <a href="http://httpwg.org/specs/rfc7540.html#FramingLayer">Sección de
+ Capa de Frame</a>.</li>
+
+ <li>Un <strong>stream</strong> es un flujo bidireccional de frames dentro
+ de una conexión HTTP/2. El concepto correspondiente en HTTP 1.1 es un
+ intercambio de mensajes de solicitud/respuesta. Más información en la
+ documentación oficial
+ <a href="http://httpwg.org/specs/rfc7540.html#StreamsLayer">Sección Capa
+ de Stream</a>.</li>
+
+ <li>
+ HTTP/2 es capaz de llevar <strong>múltiples streams</strong> de datos
+ sobre la misma conexión TCP, evitando la clásica solicitud lenta
+ "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones
+ TCP para cada solicitud/respuesta (KeepAlive parcheó el problema en
+ HTTP 1.1 pero no lo resolvió completamente).
+ </li>
</ul>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="implementation" id="implementation">HTTP/2 en Apache httpd</a><a title="Enlace permanente" href="#implementation" class="permalink">¶</a></h2>
- <p>El protocolo HTTP/2 se implementa con su propio módulo httpd, llamado acertadamente <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code>. Incluye el set completo de características descritas por el RFC 7540 y soporta HTTP/2 sobre texto plano (http:), así como conexiones seguras (https:). La variante de texto plano se llama '<code>h2c</code>', la segura '<code>h2</code>'. Para <code>h2c</code> permite el modo <em>direct</em>
- y el <code>Upgrade:</code> a través de una solicitud inicial HTTP/1.</p>
+
+ <p>
+ El protocolo HTTP/2 se implementa con su propio módulo httpd, llamado
+ acertadamente <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code>. Incluye el set completo de
+ características descritas por el RFC 7540 y soporta HTTP/2 sobre texto
+ plano (http:), así como conexiones seguras (https:). La variante de texto
+ plano se llama '<code>h2c</code>', la segura '<code>h2</code>'. Para
+ <code>h2c</code> permite el modo <em>direct</em>
+ y el <code>Upgrade:</code> a través de una solicitud inicial HTTP/1.
+ </p>
- <p>Una característica de HTTP/2 que ofrece capacidades nuevas para desarrolladores de web es <a href="#push">Server Push</a>. Vea esa sección para saber como su aplicación web puede hacer uso de ella.</p>
+ <p>
+ Una característica de HTTP/2 que ofrece capacidades nuevas para
+ desarrolladores de web es <a href="#push">Server Push</a>. Vea esa sección
+ para saber como su aplicación web puede hacer uso de ella.
+ </p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="building" id="building">Compilar httpd con soporte HTTP/2</a><a title="Enlace permanente" href="#building" class="permalink">¶</a></h2>
- <p><code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> usa la librería <a href="https://nghttp2.org">nghttp2</a>
- como su implementación base. Para compilar <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> necesita al menos la versión 1.2.1 de <code>libnghttp2</code> instalada en su sistema.</p>
- <p>Cuando usted ejecuta <code>./configure</code> en el código fuente de Apache HTTPD, necesita indicarle '<code>--enable-http2</code>' como una opción adicional para activar la compilación de este módulo. Si su <code>libnghttp2</code> está ubicado en una ruta no habitual (cualquiera que sea en su sistema operativo), puede indicar su ubicación con '<code>--with-nghttp2=<path></code>' para <code>./configure</code>.</p>
+ <p>
+ <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> usa la librería <a href="https://nghttp2.org">
+ nghttp2</a>como su implementación base. Para compilar
+ <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> necesita al menos la versión 1.2.1 de
+ <code>libnghttp2</code> instalada en su sistema.
+ </p>
+
+ <p>
+ Cuando usted ejecuta <code>./configure</code> en el código fuente de
+ Apache HTTPD, necesita indicarle '<code>--enable-http2</code>' como una
+ opción adicional para activar la compilación de este módulo. Si su
+ <code>libnghttp2</code> está ubicado en una ruta no habitual (cualquiera que
+ sea en su sistema operativo), puede indicar su ubicación con
+ '<code>--with-nghttp2=<path></code>' para <code>./configure</code>.
+ </p>
<p>Aunque puede que eso sirva para la mayoría, habrá quien prefiera un <code>nghttp2</code> compilado estáticamente para este módulo. Para ellos existe la opción <code>--enable-nghttp2-staticlib-deps</code>. Funciona de manera muy similar a como uno debe enlazar openssl estáticamente para <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>.</p>
<pre class="prettyprint lang-config">Link </xxx.css>;rel=preload, </xxx.js>; rel=preload</pre>
- <p>Si la conexión soporta PUSH, estos dos recursos se enviarán al cliente. Como desarrollador web, puede configurar estas cabeceras o bien directamente en la respuesta de su aplicación o configurar su servidor con:</p>
+ <p>
+ Si la conexión soporta PUSH, estos dos recursos se enviarán al cliente.
+ Como desarrollador web, puede configurar estas cabeceras o bien
+ directamente en la respuesta de su aplicación o configurar su servidor con:
+ </p>
<pre class="prettyprint lang-config"><Location /xxx.html>
Header add Link "</xxx.css>;rel=preload"
</Location></pre>
- <p>Si quiere usar enlaces con <code>preload</code> sin activar un PUSH, puede usar el parámetro <code>nopush</code>, como en:</p>
+ <p>Si quiere usar enlaces con <code>preload</code> sin activar un PUSH, puede
+ usar el parámetro <code>nopush</code>, como en:</p>
<pre class="prettyprint lang-config">Link </xxx.css>;rel=preload;nopush</pre>
<p>Y hay más:</p>
- <p>El módulo mantiene un registro de lo que se ha enviado con PUSH para cada conexión (hashes de URLs, básicamente) y no hará PUSH del mismo recurso dos veces. Cuando la conexión se cierra, la información es descartada.</p>
+ <p>
+ El módulo mantiene un registro de lo que se ha enviado con PUSH para cada
+ conexión (hashes de URLs, básicamente) y no hará PUSH del mismo recurso dos
+ veces. Cuando la conexión se cierra, la información es descartada.
+ </p>
- <p>Hay gente pensando cómo un cliente puede decirle al servidor lo que ya tiene, para evitar los PUSH de esos elementos, pero eso algo muy experimental ahora mismo.</p>
+ <p>
+ Hay gente pensando cómo un cliente puede decirle al servidor lo que ya
+ tiene, para evitar los PUSH de esos elementos, pero eso algo muy
+ experimental ahora mismo.
+ </p>
<p>Otro borrador experimental que ha sido implementado en
<code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> es el <a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00"> Campo de Cabecera
- Accept-Push-Policy</a> en la que un cliente puede, para cada solicitud, definir qué tipo de PUSH acepta.</p>
+ Accept-Push-Policy</a> en la que un cliente puede, para cada solicitud, definir
+ qué tipo de PUSH acepta.</p>
+
+ <p>
+ Puede que PUSH no siempre lance la peticion/respuesta/funcionamiento que
+ uno espera. Hay varios estudios sobre este tema en internet, que explican
+ el beneficio y las debilidades de como diferentes funcionalidades del
+ cliente y de la red influyen en el resultado.
+ Por Ejemplo, que un servidor haga "PUSH" de recursos, no significa que el
+ navegador vaya a usar dichos datos.
+ </p>
+ <p>
+ Lo más importante que influye en la respuesta que se envía, es la solicitud
+ que se simuló. La url de solicitud de un PUSH es dada por la aplicación,
+ pero ¿de donde vienen las cabeceras de la petición? por ejemplo si el PUSH
+ pide una cabecera <code>accept-language</code> y si es así, ¿con qué valor?
+ </p>
+ <p>Httpd mirará la petición original (la que originó el PUSH) y copiará las
+ siguientes cabeceras a las peticiones PUSH:
+ <code>user-agent</code>, <code>accept</code>, <code>accept-encoding</code>,
+ <code>accept-language</code>, <code>cache-control</code>.
+ </p>
+ <p>
+ Todas las otras cabeceras son ignorados. Las cookies tampoco serán copiadas.
+ Impulsar los recursos que requieren una cookie para estar presente no
+ funcionará. Esto puede ser una cuestión de debate. Pero a menos que esto se
+ discuta más claramente con el navegador, evitemos el exceso de precaución y
+ no expongamos las cookies donde podrían o no ser visibles.
+ </p>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="earlyhints" id="earlyhints">"Early Hints"</a><a title="Enlace permanente" href="#earlyhints" class="permalink">¶</a></h2>
+
+
+ <p>Una alternativa de "Pushear" recursos es mandar una cabecera
+ <code>Link</code> al cliente antes que la respuesta esté lista. Esto usa
+ una caracteristica de HTTP que se llama "Early Hints" y está descrita en
+ la <a href="https://tools.ietf.org/html/rfc8297">RFC 8297</a>.</p>
+ <p>Para poder usar esto, necesita habilitarlo explicitamente en el servidor
+ via</p>
+
+ <pre class="prettyprint lang-config">H2EarlyHints on</pre>
+
+
+ <p>(No está habilitado por defecto ya q ue algunos navegadores más antiguos
+ se caen con dichas respuestas.)
+ </p>
+
+ <p>si esta funcionalidad esta activada, puede usar la directiva
+ <code class="directive"><a href="../mod/mod_http2.html#h2pushresource">H2PushResource</a></code> para que lance
+ "Early hints" y recursos mediante push:
+ </p>
+ <pre class="prettyprint lang-config"><Location /xxx.html>
+ H2PushResource /xxx.css
+ H2PushResource /xxx.js
+</Location></pre>
+
+ <p>
+ Esto lanzará una respuesta <code>"103 Early Hints"</code> a un cliente
+ tan pronto como el servidor <em>comience</em> a procesar la solicitud.
+ Esto puede ser mucho antes que en el momento en que se determinaron los
+ primeros encabezados de respuesta, dependiendo de su aplicación web.
+ </p>
+
+ <p>
+ Si la directiva <code class="directive"><a href="../mod/mod_http2.html#h2push">H2Push</a></code> está
+ habilitada, esto comenzará el PUSH justo después de la respuesta 103.
+ Sin embargo, si la directiva <code class="directive"><a href="../mod/mod_http2.html#h2push">H2Push</a></code> está dehabilitada, la respuesta 103 se le enviará al cliente.
+ </p>
</div></div>
<div class="bottomlang">
<p><span>Idiomas disponibles: </span><a href="../en/howto/http2.html" hreflang="en" rel="alternate" title="English"> en </a> |
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.es.xsl"?>
-<!-- English Revision: 1779744:1834263 (outdated) -->
+<!-- English Revision: 1834263 -->
<!-- Spanish translation : Daniel Ferradal -->
<!-- Reviewed & updated by Luis Gil de Bernabé Pfeiffer lgilbernabe[AT]apache.org -->
-
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
See the License for the specific language governing permissions and
limitations under the License.
-->
-
<manualpage metafile="http2.xml.meta">
<parentdocument href="./">How-To / Tutoriales</parentdocument>
<title>Guía HTTP/2</title>
<summary>
- <p>Esta es la guía para configurar HTTP/2 en Apache httpd. Ésta
- característica está <em>lista en produción</em> así que es de esperar que las
- interfaces y las directivas se mantengan consistentes en cada verión.
+ <p>
+ Esta es la guía para configurar HTTP/2 en Apache httpd. Ésta característica
+ está <em>lista en produción</em> así que es de esperar que las interfaces
+ y las directivas se mantengan consistentes en cada verión.
</p>
</summary>
<seealso><module>mod_http2</module></seealso>
<title>El protocolo HTTP/2</title>
<p>HTTP/2 es la evolución del protocolo de la capa de aplicación con más
- éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red. No cambia la característica fundamental de HTTP, la semántica. Todavía hay solicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.</p>
+ éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red.
+ No cambia la característica fundamental de HTTP, la semántica. Todavía hay
+ olicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así
+ que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.</p>
<p>Se ha escrito mucho sobre HTTP/2 y de cómo funciona. La norma más
estándar es, por supuesto, su
<a href="https://tools.ietf.org/html/rfc7540">RFC 7540</a>
(<a href="http://httpwg.org/specs/rfc7540.html"> también disponible en un
- formato más legible, YMMV</a>). Así que, ahí encontrará toda la especificación del protocolo.</p>
+ formato más legible, YMMV</a>). Así que, ahí encontrará toda la especificación
+ del protocolo.</p>
<p>Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor
entender primero <em>qué</em> se quiere hacer y después leer el RFC sobre
<p>Si le parece demasiado largo, o no lo ha leido, hay algunos términos
y elementos a tener en cuenta cuando lea este documento:</p>
<ul>
- <li>HTTP/2 es un <strong>protocolo binario</strong>, al contrario que HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea legible (por ejemplo capturando el tráfico de red) mientras que para HTTP/2 no. Más información en el FAQ oficial <a href="https://http2.github.io/faq/#why-is-http2-binary">¿Por qué es binario HTTP/2?</a></li>
+ <li>HTTP/2 es un <strong>protocolo binario</strong>, al contrario que
+ HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea
+ legible (por ejemplo capturando el tráfico de red) mientras que para
+ HTTP/2 no. Más información en el FAQ oficial
+ <a href="https://http2.github.io/faq/#why-is-http2-binary">¿Por qué es
+ binario HTTP/2?</a></li>
- <li><strong>h2</strong> es HTTP/2 sobre TLS (negociación de protocolo a través de ALPN).</li>
+ <li><strong>h2</strong> es HTTP/2 sobre TLS (negociación de protocolo a
+ través de ALPN).</li>
<li><strong>h2c</strong> es HTTP/2 sobre TCP.</li>
- <li>Un <strong>frame</strong> es la unidad más pequeña de comunicación dentro de una conexión HTTP/2, que consiste en una cabecera y una secuencia de octetos de longitud variable estructurada de acuerdo con el tipo de frame. Más información en la documentación oficial <a href="http://httpwg.org/specs/rfc7540.html#FramingLayer">Sección de Capa de Frame</a>.</li>
-
- <li>Un <strong>stream</strong> es un flujo bidireccional de frames dentro de una conexión HTTP/2. El concepto correspondiente en HTTP 1.1 es un intercambio de mensajes de solicitud/respuesta. Más información en la documentación oficial <a href="http://httpwg.org/specs/rfc7540.html#StreamsLayer">Sección Capa de Stream</a>.</li>
-
- <li>HTTP/2 es capaz de llevar <strong>múltiples streams</strong> de datos sobre la misma conexión TCP, evitando la clásica solicitud lenta "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones TCP para cada solicitud/respuesta (KeepAlive parcheó el problema en HTTP 1.1 pero no lo resolvió completamente).</li>
+ <li>Un <strong>frame</strong> es la unidad más pequeña de comunicación
+ dentro de una conexión HTTP/2, que consiste en una cabecera y una secuencia
+ de octetos de longitud variable estructurada de acuerdo con el tipo de
+ frame. Más información en la documentación oficial
+ <a href="http://httpwg.org/specs/rfc7540.html#FramingLayer">Sección de
+ Capa de Frame</a>.</li>
+
+ <li>Un <strong>stream</strong> es un flujo bidireccional de frames dentro
+ de una conexión HTTP/2. El concepto correspondiente en HTTP 1.1 es un
+ intercambio de mensajes de solicitud/respuesta. Más información en la
+ documentación oficial
+ <a href="http://httpwg.org/specs/rfc7540.html#StreamsLayer">Sección Capa
+ de Stream</a>.</li>
+
+ <li>
+ HTTP/2 es capaz de llevar <strong>múltiples streams</strong> de datos
+ sobre la misma conexión TCP, evitando la clásica solicitud lenta
+ "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones
+ TCP para cada solicitud/respuesta (KeepAlive parcheó el problema en
+ HTTP 1.1 pero no lo resolvió completamente).
+ </li>
</ul>
</section>
<section id="implementation">
<title>HTTP/2 en Apache httpd</title>
- <p>El protocolo HTTP/2 se implementa con su propio módulo httpd, llamado acertadamente <module>mod_http2</module>. Incluye el set completo de características descritas por el RFC 7540 y soporta HTTP/2 sobre texto plano (http:), así como conexiones seguras (https:). La variante de texto plano se llama '<code>h2c</code>', la segura '<code>h2</code>'. Para <code>h2c</code> permite el modo <em>direct</em>
- y el <code>Upgrade:</code> a través de una solicitud inicial HTTP/1.</p>
+
+ <p>
+ El protocolo HTTP/2 se implementa con su propio módulo httpd, llamado
+ acertadamente <module>mod_http2</module>. Incluye el set completo de
+ características descritas por el RFC 7540 y soporta HTTP/2 sobre texto
+ plano (http:), así como conexiones seguras (https:). La variante de texto
+ plano se llama '<code>h2c</code>', la segura '<code>h2</code>'. Para
+ <code>h2c</code> permite el modo <em>direct</em>
+ y el <code>Upgrade:</code> a través de una solicitud inicial HTTP/1.
+ </p>
- <p>Una característica de HTTP/2 que ofrece capacidades nuevas para desarrolladores de web es <a href="#push">Server Push</a>. Vea esa sección para saber como su aplicación web puede hacer uso de ella.</p>
+ <p>
+ Una característica de HTTP/2 que ofrece capacidades nuevas para
+ desarrolladores de web es <a href="#push">Server Push</a>. Vea esa sección
+ para saber como su aplicación web puede hacer uso de ella.
+ </p>
</section>
<section id="building">
<title>Compilar httpd con soporte HTTP/2</title>
- <p><module>mod_http2</module> usa la librería <a href="https://nghttp2.org">nghttp2</a>
- como su implementación base. Para compilar <module>mod_http2</module> necesita al menos la versión 1.2.1 de <code>libnghttp2</code> instalada en su sistema.</p>
- <p>Cuando usted ejecuta <code>./configure</code> en el código fuente de Apache HTTPD, necesita indicarle '<code>--enable-http2</code>' como una opción adicional para activar la compilación de este módulo. Si su <code>libnghttp2</code> está ubicado en una ruta no habitual (cualquiera que sea en su sistema operativo), puede indicar su ubicación con '<code>--with-nghttp2=<path></code>' para <code>./configure</code>.</p>
+ <p>
+ <module>mod_http2</module> usa la librería <a href="https://nghttp2.org">
+ nghttp2</a>como su implementación base. Para compilar
+ <module>mod_http2</module> necesita al menos la versión 1.2.1 de
+ <code>libnghttp2</code> instalada en su sistema.
+ </p>
+
+ <p>
+ Cuando usted ejecuta <code>./configure</code> en el código fuente de
+ Apache HTTPD, necesita indicarle '<code>--enable-http2</code>' como una
+ opción adicional para activar la compilación de este módulo. Si su
+ <code>libnghttp2</code> está ubicado en una ruta no habitual (cualquiera que
+ sea en su sistema operativo), puede indicar su ubicación con
+ '<code>--with-nghttp2=<path></code>' para <code>./configure</code>.
+ </p>
<p>Aunque puede que eso sirva para la mayoría, habrá quien prefiera un <code>nghttp2</code> compilado estáticamente para este módulo. Para ellos existe la opción <code>--enable-nghttp2-staticlib-deps</code>. Funciona de manera muy similar a como uno debe enlazar openssl estáticamente para <module>mod_ssl</module>.</p>
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
</highlight>
- <p>Si la conexión soporta PUSH, estos dos recursos se enviarán al cliente. Como desarrollador web, puede configurar estas cabeceras o bien directamente en la respuesta de su aplicación o configurar su servidor con:</p>
+ <p>
+ Si la conexión soporta PUSH, estos dos recursos se enviarán al cliente.
+ Como desarrollador web, puede configurar estas cabeceras o bien
+ directamente en la respuesta de su aplicación o configurar su servidor con:
+ </p>
<highlight language="config">
<Location /xxx.html>
</Location>
</highlight>
- <p>Si quiere usar enlaces con <code>preload</code> sin activar un PUSH, puede usar el parámetro <code>nopush</code>, como en:</p>
+ <p>Si quiere usar enlaces con <code>preload</code> sin activar un PUSH, puede
+ usar el parámetro <code>nopush</code>, como en:</p>
<highlight language="config">
-Link </xxx.css>;rel=preload;nopush
+ Link </xxx.css>;rel=preload;nopush
</highlight>
<p>o puede desactivar PUSH para su servidor por completo con la directiva </p>
<p>Y hay más:</p>
- <p>El módulo mantiene un registro de lo que se ha enviado con PUSH para cada conexión (hashes de URLs, básicamente) y no hará PUSH del mismo recurso dos veces. Cuando la conexión se cierra, la información es descartada.</p>
+ <p>
+ El módulo mantiene un registro de lo que se ha enviado con PUSH para cada
+ conexión (hashes de URLs, básicamente) y no hará PUSH del mismo recurso dos
+ veces. Cuando la conexión se cierra, la información es descartada.
+ </p>
- <p>Hay gente pensando cómo un cliente puede decirle al servidor lo que ya tiene, para evitar los PUSH de esos elementos, pero eso algo muy experimental ahora mismo.</p>
+ <p>
+ Hay gente pensando cómo un cliente puede decirle al servidor lo que ya
+ tiene, para evitar los PUSH de esos elementos, pero eso algo muy
+ experimental ahora mismo.
+ </p>
<p>Otro borrador experimental que ha sido implementado en
<module>mod_http2</module> es el <a href="https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00"> Campo de Cabecera
- Accept-Push-Policy</a> en la que un cliente puede, para cada solicitud, definir qué tipo de PUSH acepta.</p>
+ Accept-Push-Policy</a> en la que un cliente puede, para cada solicitud, definir
+ qué tipo de PUSH acepta.</p>
+
+ <p>
+ Puede que PUSH no siempre lance la peticion/respuesta/funcionamiento que
+ uno espera. Hay varios estudios sobre este tema en internet, que explican
+ el beneficio y las debilidades de como diferentes funcionalidades del
+ cliente y de la red influyen en el resultado.
+ Por Ejemplo, que un servidor haga "PUSH" de recursos, no significa que el
+ navegador vaya a usar dichos datos.
+ </p>
+ <p>
+ Lo más importante que influye en la respuesta que se envía, es la solicitud
+ que se simuló. La url de solicitud de un PUSH es dada por la aplicación,
+ pero ¿de donde vienen las cabeceras de la petición? por ejemplo si el PUSH
+ pide una cabecera <code>accept-language</code> y si es así, ¿con qué valor?
+ </p>
+ <p>Httpd mirará la petición original (la que originó el PUSH) y copiará las
+ siguientes cabeceras a las peticiones PUSH:
+ <code>user-agent</code>, <code>accept</code>, <code>accept-encoding</code>,
+ <code>accept-language</code>, <code>cache-control</code>.
+ </p>
+ <p>
+ Todas las otras cabeceras son ignorados. Las cookies tampoco serán copiadas.
+ Impulsar los recursos que requieren una cookie para estar presente no
+ funcionará. Esto puede ser una cuestión de debate. Pero a menos que esto se
+ discuta más claramente con el navegador, evitemos el exceso de precaución y
+ no expongamos las cookies donde podrían o no ser visibles.
+ </p>
+
+</section>
+<section id="earlyhints">
+ <title>"Early Hints"</title>
+
+ <p>Una alternativa de "Pushear" recursos es mandar una cabecera
+ <code>Link</code> al cliente antes que la respuesta esté lista. Esto usa
+ una caracteristica de HTTP que se llama "Early Hints" y está descrita en
+ la <a href="https://tools.ietf.org/html/rfc8297">RFC 8297</a>.</p>
+ <p>Para poder usar esto, necesita habilitarlo explicitamente en el servidor
+ via</p>
+
+ <highlight language="config">
+H2EarlyHints on
+ </highlight>
+
+ <p>(No está habilitado por defecto ya q ue algunos navegadores más antiguos
+ se caen con dichas respuestas.)
+ </p>
+
+ <p>si esta funcionalidad esta activada, puede usar la directiva
+ <directive module="mod_http2">H2PushResource</directive> para que lance
+ "Early hints" y recursos mediante push:
+ </p>
+ <highlight language="config">
+<Location /xxx.html>
+ H2PushResource /xxx.css
+ H2PushResource /xxx.js
+</Location>
+ </highlight>
+ <p>
+ Esto lanzará una respuesta <code>"103 Early Hints"</code> a un cliente
+ tan pronto como el servidor <em>comience</em> a procesar la solicitud.
+ Esto puede ser mucho antes que en el momento en que se determinaron los
+ primeros encabezados de respuesta, dependiendo de su aplicación web.
+ </p>
+
+ <p>
+ Si la directiva <directive module="mod_http2">H2Push</directive> está
+ habilitada, esto comenzará el PUSH justo después de la respuesta 103.
+ Sin embargo, si la directiva <directive module="mod_http2">H2Push</directive> está dehabilitada, la respuesta 103 se le enviará al cliente.
+ </p>
</section>
projects / apache / commitdiff