Añadida información de Chrome para desarrolladores
diff --git a/docs/chrome/desarrolladores/curso-diagnostico-net-internals.md b/docs/chrome/desarrolladores/curso-diagnostico-net-internals.md
new file mode 100644
index 0000000..a4c52ba
--- /dev/null
+++ b/docs/chrome/desarrolladores/curso-diagnostico-net-internals.md
@@ -0,0 +1,56 @@
+# Un curso rápido sobre diagnóstico de problemas con chrome://net-internals
+
+Este documento es una traducción del siguiente documento: [A Crash Course in Debugging with chrome://net-internals - The Chromium Project (24/03/2020)](https://chromium.googlesource.com/chromium/src/+/71f386b74676de71601fd8d2472a12ca3bfa0ce9/net/docs/crash-course-in-net-internals.md)
+
+La versión más actualizada del documento (en inglés) se puede encontrar [aquí](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/crash-course-in-net-internals.md).
+
+---
+
+Este documento tiene como objetivo ayudar a la gente a empezar a diagnosticar problemas de red con `chrome://net-internals`, con algunos consejos y trucos comunmente útiles. Este documento está encarado más a explicar cómo empezar a usar algunas de las funciones para investigar informes de errores, más que como una vista general de la función.
+
+Probablemente sería útil leer [vida-de-una-url-request.md](vida-de-una-url-request.md) antes de este documento.
+
+## Qué información contiene Net-Internals
+
+`chrome://net-internals` proporciona una vista de la actividad del navegador desde la perspectiva de net/. Por esta razón, le falta información sobre las pestañas, la navegación, los frames, los tipos de recursos, etc.
+
+La columna de la izquierda del todo presenta una lista de vistas. La mayoría del diagnóstico se hace con la vista **Eventos**, que será todo lo cubre este documento.
+
+El objeto de máximo nivel de la pila de red es el `URLRequestContext`. La vista Eventos tiene información sobre todos los `URLRequestContexts` de Chrome que están acoplados a un objeto Netlog único y global. Esto incluye ambos los perfiles de incógnito y no incógnito, a parte de otras cosas. La vista Eventos muestra solo los eventos durante el periodo que net-internals estaba abierto y corriendo. El código intenta añadir un evento arriba del todo para los `URLRequests` que estaban activos cuando la pestaña `chrome://net-internals` fue abierta, para ayudar a diagnosticar peticiones colgadas, pero eso es solo de máximo esfuerzo, y solo incluye peticiones para el perfil actual y el `URLRequestContext` del sistema.
+
+Las otras vistas son todas instantáneas del estado actual de los componentes principales de `URLRequestContext`. Estos mostrarán objetos que fueron creados antes de que `chrome://net-internals` fuera abierto.
+
+## Eventos versus fuentes
+
+La vista Eventos muestra **eventos** registrados por `NetLog`. El modelo de `NetLog` es que los objetos de la pila de red duraderos, llamados **fuentes**, emiten eventos durante su vida. Un objeto `NetLogWithSource` contiene un ID de fuente, un `NetLogSourceType`, y un puntero al `NetLog` al que la fuente emite sus eventos.
+
+La vista Eventos tiene una lista de las fuentes en una columna adyacente a la columna de la lista de vistas. Las fuentes que incluyen un evento con un parámetro `net_error` con valor negativo (esto es, algún tipo de ERR_) se muestran con fondo rojo. Las fuentes cuyos eventos de abertura todavía no hayan acabado se muestran con un fondo blanco. Las otras fuentes tienen fondos verdes. Los términos de búsqueda correspondientes a los dos primeros tipos son `is:error` y `is:active`.
+
+Cuando una o más fuentes están seleccionadas, los eventos correspondientes se muestran en otra columna a la derecha, ordenados por fuente, y por tiempo dentro de cada fuente. Hay dos valores del tiempo: `t` se mide desde algún punto de referencia común a todas las fuentes, y `st` se mide desde el primer evento para cada fuente. El tiempo se muestra en milisegundos.
+
+Como la pila de red es asíncrona, los eventos de las diferentes fuentes suelen estar entremezcladas durante el tiempo, pero la vista Eventos no ofrece la función de mostrar los eventos de diferentes fuentes ordenados por tiempo. Esacios de tiempo grande en la lista de eventos de una sola fuente normalmente significa que el tiempo se está gastando en el contexto de otra fuente.
+
+Algunos eventos vienen en parejas: un evento de inicio y otro de fin, entre los cuales pueden ocurrir otros eventos. Se muestran con los prefijos `+` y `-` respectivamente. El evento de inicio tiene un valor `dt` que muestra la duración. Si el evento de fin fue capturado, entonces la duración se calcula como la diferencia de tiempo entre los eventos de inicio y fin. Si no, se trata del tiempo que ha pasado desde el evento de inicio hasta que se paró la captura de datos (es una cota inferior para la duración real), seguido por un signo `+` (por ejemplo, `dt=120+`).
+
+Si no hay otros eventos entre medio del de inicio y el de fin, y el evento de fin no tiene parámetros, entonces colapsan en una única línea que no tiene signos de prefijo.
+
+Otros eventos solo ocurren en un solo momento en el tiempo, y no tendrán ningún signo de prefijo o un valor de duración `dt`.
+
+Generalmente solo puede ocurrir un evento a la vez para una fuente en un instante de tiempo. Si pueden haber varios eventos haciendo cosas completamente independientes, el código a menudo usará nuevas fuentes para representar el paralelismo.
+
+La mayoría de eventos, pero no todos ellos, corresponden a una fuente. Las excepciones son eventos globales, que no tienen ningúna fuente y se muestran como entradas individuales en la lista de fuentes. Ejemplos de eventos globales incluyen `NETWORK_CHANGED`, `DNS_CONFIG_CHANGED` y `PROXY_CONFIG_CHANGED`.
+
+## Tipos de fuentes comunes
+
+!!! info "Falta la traducción"
+ Esta sección todavía no ha sido traducida, pero se puede consultar en el documento original (en inglés) enlazado al principio de este documento.
+
+## Diagnóstico
+
+!!! info "Falta la traducción"
+ Esta sección todavía no ha sido traducida, pero se puede consultar en el documento original (en inglés) enlazado al principio de este documento.
+
+# Miscelánea
+
+!!! info "Falta la traducción"
+ Esta sección todavía no ha sido traducida, pero se puede consultar en el documento original (en inglés) enlazado al principio de este documento.
diff --git a/docs/chrome/desarrolladores/vida-de-una-url-request.md b/docs/chrome/desarrolladores/vida-de-una-url-request.md
new file mode 100644
index 0000000..c8c6e54
--- /dev/null
+++ b/docs/chrome/desarrolladores/vida-de-una-url-request.md
@@ -0,0 +1,160 @@
+# Vida de un objeto URLRequest
+
+Este documento es una traducción del siguiente documento: [Life of a URLRequest - The Chromium Project (24/03/2020)](https://chromium.googlesource.com/chromium/src/+/71f386b74676de71601fd8d2472a12ca3bfa0ce9/net/docs/life-of-a-url-request.md)
+
+La versión más actualizada del documento (en inglés) se puede encontrar [aquí](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/life-of-a-url-request.md).
+
+---
+
+Este documento tiene como objetivo exponer las capas centrales de la pila de red y el servicio de red de Chrome, sus responsabilidades básicas, y cómo encajan juntas, sin dar mucho detalle. Este documento asume que el servicio de red está activado, aunque el servicio de red no está todavía activado por defecto en todas las plataformas.
+
+Está dirigido principalmente a las personas nuevas a la pila de red de Chrome, pero también debería ser útil para miembros del equipo que sean expertos en algunas partes de la pila, pero que no estén tan familiarizados con otros componentes. Empieza explicando cómo una petición básica que realiza otro proceso se desplaza por la pila de red, y después habla también sobre cómo varios componentes están integrados en ella.
+
+
+## Anatomía de la pila de red
+
+La pila de red está ubicada en `//net/` en el repositorio de Chrome, y usa el espacio de nombres `net`. Cuando no se especifique en qué espacio de nombres está una clase en este documento se puede asumir generalmente que está en `//net/` y en el espacio de nombres `net`.
+
+El objeto de arriba del todo de la pila de red es `URLRequestContext`. El contexto tiene punteros _non-owning_ para todo lo que se necesita para crear y emitir un `URLRequest`. El contexto debe durar más tiempo que todas las peticiones que lo usan. Crear un contexto es un proceso bastante complicado, así que se recomienda que la mayoría de los consumidores usen `URLRequestContextBuilder` para hacer esto.
+
+El uso principal de `URLRequestContext` es crear objetos `URLRequest` usando `URLRequestContext::CreateRequest()`. `URLRequest` es la interfaz principal usada por los consumidores directos de la pila de red. Se usa para conducir peticiones para http, https, ftp, y algunas URLs data. Cada `URLRequest` se encarga de seguir una sola petición a través de todas las redirecciones hasta que ocurre un error, se cancela o se recibe una respuesta final, con un cuerpo (posiblemente vacío).
+
+`HttpNetworkSession` es otro de los objetos de la pila de red más importantes. Es propietario de `HttpStreamFactory`, las piscinas de _sockets_, y las piscinas de sesiones de HTTP/2 y QUIC. También tiene punteros _non-owning_ a los objetos de la pila de red que trabajan más directamente con los _sockets_.
+
+Este documento no menciona mucho ninguno de los dos, pero en capas por encima de `HttpStreamFactory`, los objetos tienden a coger sus dependencias de `URLRequestContext`, mientras que la capa de `HttpStreamFactory` y capas inferiores generalmente cogen sus dependencias de `HttpNetworkSession`.
+
+
+## ¿Cuántos "delegados" hay?
+
+Una `URLRequest` informa al consumidor de eventos importantes de una petición usando dos interfaces principales: la interfaz `URLRequest::Delegate` y la interfaz `NetworkDelegate`.
+
+La interfaz `URLRequest::Delegate` consiste de un pequeño conjunto de _callbacks_ que se necesitan para permitir que el embededor conduzca una petición adelante. `NetworkDelegate` es un objeto apuntado por `URLRequestContext` y compartido por todas las peticiones, e incluye _callbacks_ correspondientes a la mayoría de los _callbacks_ de `URLRequest::Delegate`, además de un surtido de otros métodos.
+
+## El servicio de red y Mojo
+
+El servicio de red, que vive en `//services/network/`, envuelve objetos `//net/` y proporciona APIs de red _cross-process_ y sus implementaciones para el resto de Chrome. El servicio de red usa el espacio de nombres `network` para todas sus clases. Las interfaces Mojo que proporciona están en el espacio de nombres `network::mojom`. Mojo es la capa IPC de Chrome. Generalmente hay un objeto _proxy_ `network::mojom::FooPtr` en el proceso del consumidor que también implementa la interfaz `network::mojom::Foo`. Cuando los métodos del objeto _proxy_ se invocan, pasa la llamada y todos sus argumentos por un canal Mojo IPC a otra implementación de la interfaz `network::mojom::Foo` en el servicio de red (típicamente implementado por una clase llamada `network::Foo`), que puede estár ejecutándose en otro proceso o posiblemente otro subproceso del proceso del consumidor.
+
+El objeto `network::NetworkService` es un _singleton_ que es usado por Chrome para crear todos los otros objetos del servicio de red. Los objetos principales que está habituado a crear son `network::NetworkContexts`, cada uno de los cuales es propietario de su propio `URLRequestContext` independiente. Chrome tiene varios `NetworkContexts` diferentes, ya que a menudo hay la necesidad de mantener cookies, cachés y piscinas de _sockets_ separados para diferentes tipos de petición, dependiendo de qué está haciendo la petición. Aquí hay los `NetworkContexts` más comunes usados por Chrome:
+
+* El sistema `NetworkContext`, creado y propiedad del `SystemNetworkContextManager` de Chrome, se usa para peticiones que no están asociados a un usuario en particular o perfil. No tiene espacio de almacenamiento en disco, así que pierde su estado, como las cookies, después de cada reinicio del navegador. No tiene caché http en memoria tampoco. `SystemNetworkContextManager` también establece preferencias del servicio de red globales.
+* Cada perfil de Chrome, incluyendo los perfiles de incógnito, tienen su propio `NetworkContext`. Exceptuando los perfiles de incógnito e invitado, estos contextos guardan información en su propio espacio de almacenamiento en disco, que incluye cookies y un caché HTTP, a parte de otras cosas. Cada uno de estos `NetworkContexts` pertenece a un objeto `StoragePartition` en el proceso del navegador y es creado por el `ProfileNetworkContextService` del perfil.
+* En las plataformas que soportan las aplicaciones, cada perfil tiene un `NetworkContext` para cada aplicación instalada en ese perfil. Como con el `NetworkContext` principal, estos pueden tener datos en disco, dependiendo del perfil y la aplicación.
+
+
+## Vida de un URLRequest simple
+
+Una petición de información se despacha de algún otro proceso que resulta en la creación de un `network::URLLoader` en el proceso de red. El `URLLoader` entonces crea un `URLRequest` para conducir la petición. Un trabajo (_job_) específico para el protocolo (por ejemplo HTTP, data, file) se adjunta a la petición. En el caso de HTTP, ese trabajo primero comprueba la caché, y luego crea un objeto de conexión de red, de ser necesario, para obtener la información. Ese objeto de conexión interactúa con la piscina de _sockets_ de red para reusar potencialmente _sockets_; la piscina de _sockets_ crea y conecta un _socket_ si no existe un _socket_ apropiado. Una vez ese _socket_ existe, la petición HTTP se despacha, la respuesta se lee y se procesa, y el resultado se devuelve de nuevo a la pila y se envía al proceso hijo.
+
+Por supuesto, esto no es tan sencillo :-}.
+
+Consideremos una petición sencilla creada por algún proceso otro que el proceso del servicio de red. Supongamos que es una petición HTTP, la respuesta no está comprimida, no hay una entrada coincidiente en la caché y no hay _sockets_ libres conectados al servidor en la piscina de _sockets_.
+
+Continuando con la `URLRequest` "simple", aquí hay un poco más de detalle sobre cómo funcionan las cosas:
+
+### La petición empieza en algún proceso (no de red)
+
+Resumen:
+
+* Un consumidor (por ejemplo `content::ResourceDispatcher` para Blink, `content::NavigationURLLoaderImpl` para navegación en frame, o `network::SimpleURLLoader`) pasa un objeto `network::ResourceRequest` y un canal Mojo `network::mojom::URLLoaderClient` a `network::mojom::URLLoaderFactory`, y le dice de crear e iniciar un `network::mojom::URLLoader`.
+* Mojo envía `network::ResourceRequest` por un _pipe_ IPC a un `network::URLLoaderFactory` en el proceso de red.
+
+Chrome tiene un solo proceso del navegador que se encarga de iniciar y configurar otros procesos, la gestión de las pestañas, la navegación, etc., y varios procesos hijos, que generalmente están en una caja de arena y no tienen acceso a la red por ellos mismos, a parte del servicio de red (que o bien se ejecuta en su propio proceso, o potencialmente se ejecuta en el proceso del navegador para conservar RAM). Hay varios tipos de procesos hijos (renderizador, GPU, complementos, red, etc). Los procesos de renderizador son los que maquetan las páginas web y ejecutan el HTML.
+
+El proceso del navegador crea los objetos de nivel superior `network::mojom::NetworkContext` y los usa para crear `network::mojom::URLLoaderFactorie`s, a los cuales les puede activar algunas opciones relacionadas con la seguridad, antes de dárselas a los procesos hijos. Los procesos hijos pueden luego usarlos para hablar directamente con el servicio de red.
+
+Un consumidor que quiere hacer una petición de red obtiene un `URLLoaderFactory` de alguna manera, ensambla unos cuantos parámetros en el objeto grande `ResourceRequest`, crea un canal Mojo `network::mojom::URLLoaderClient` para que `network::mojom::URLLoader` lo use para hablar de vuelta a él, y después los pasa a `URLLoaderFactory`, que devuelve un objeto `URLLoader` que puede usar para gestionar la petición de red.
+
+### network::URLLoaderFactory configura la petición en el servicio de red
+
+Resumen:
+
+* `network::URLLoaderFactory` crea un `network::URLLoader`.
+* `network::URLLoader` usa el `URLRequestContext` de `network::NetworkContext` para crear e inicar una `URLRequest`.
+
+`URLLoaderFactory`, junto a todos los `NetworkContexts` y la mayoría de la pila de red, vive en un solo subproceso en el servicio de red. Obtiene un objeto reconstituido del _pipe_ de Mojo, hace algunas comprobaciones para asegurarse que puede atender la petición y si es así, crea un `URLLoader`, pasando la petición y el `NetworkContext` asociado con el `URLLoaderFactory`.
+
+`URLLoader` entonces llama un `URLRequestContext` para crear la `URLRequest`. `URLRequestContext` tiene punteros a todos los objetos de la pila de red que necesita para realizar la petición en la red, como por ejemplo la caché, el almacenamiento de cookies, y el _host resolver_. `URLLoader` entonces llama a `ResourceScheduler`, que puede retrasar el inicio de la petición basándose en su priodidad y otra actividad. Eventualmente, `ResourceScheduler` inicia la petición.
+
+### Comprobación de la caché, petición de un HttpStream
+
+Resumen:
+
+* `URLRequest` pide a `URLRequestJobFactory` que cree un `URLRequestJob`, en este caso, un `URLRequestHttpJob`.
+* `URLRequestHttpJob` pide a `HttpCache` de crear un `HttpTransaction` (siempre un `HttpCache::Transaction`).
+* `HttpCache::Transaction` ve que no hay una entrada de caché para la petición, y crea un `HttpNetworkTransaction`.
+* `HttpNetworkTransaction` llama a `HttpStreamFactory` para pedir un `HttpStream`.
+
+`URLRequest` entonces llama a `URLRequestJobFactory` para crear un `URLRequestJob` y entonces lo inicia. En el caso de una petición HTTP o HTTPS, ese será un `URLRequestHttpJob`. `URLRequestHttpJob` adjunta las cookies a la petición, si es necesario.
+
+`URLRequestHttpJob` llama a `HttpCache` para crear un `HttpCache::Transaction`. Si no hay una entrada coincidiente en la caché, `HttpCache::Transaction` llamará a `HttpNetworkLayer` para crear un `HttpNetworkTransaction`, y transparentemente lo envolverá. `HttpNetworkTransaction` entonces llama a `HttpStreamFactory` para pedir un `HttpStream` al servidor.
+
+### Creación de un HttpStream
+
+Resumen:
+
+* `HttpStreamFactory` crea un `HttpStreamFactory::Job`.
+* `HttpStreamFactory::Job` llama a `TransportClientSocketPool` para rellenar un `ClientSocketHandle`.
+* `TransportClientSocketPool` no tiene _sockets_ libres, así que crea un `TransportConnectJob` y lo inicia.
+* `TransportConnectJob` crea un `StreamSocket` y establece una conexión.
+* `TransportClientSocketPool` pone el `StreamSocket` en el `ClientSocketHandle`, y llama a `HttpStreamFactory::Job`.
+* `HttpStreamFactory::Job` crea un `HttpBasicStream`, que se convierte en el propietario del `ClientSocketHandle`.
+* Devuelve el `HttpBasicStream` al `HttpNetworkTransaction`.
+
+`HttpStreamFactory::Job` crea un `ClientSocketHandle` para tener el _socket_, una vez conectado, y pasarlo a `ClientSocketPoolManager`. `ClientSocketPoolManager` ensambla el `TransportSocketParams` requerido para establecer la conexión y crea un nombre de grupo ("huésped:puerto") usado para identificar los _sockets_ que se pueden usar intercambiablemente.
+
+`ClientSocketPoolManager` dirige la petición a `TransportClientSocketPool`, ya que no hay ningún _proxy_ y es una petición HTTP. La petición se reenvía al `ClientSocketPoolBaseHelper` de `ClientSocketPoolBase<TransportSocketParams>` de la piscina. Si no hay aún una conexión libre, y hay ranuras de _sockets_ disponibles, `ClientSocketPoolBaseHelper` creará un nuevo `TransportConnectJob` usando el objeto de parámetros anteriormente mencionado. Este trabajo hará la consulta de DNS llamando a `HostResolverImpl`, de ser necesario, y después finalmente establecerá una conexión.
+
+Una vez el _socket_ está conectado, la propiedad del _socket_ se pasa al `ClientSocketHandle`. `HttpStreamFactory::Job` es entonces informado de que el intento de conexión ha sido satisfactorio, y entonces crea un `HttpBasicStream`, que toma la propiedad del `ClientSocketHandle`. Este entonces pasa la propiedad de `HttpBasicStream` de vuelta al `HttpNetworkTransaction`.
+
+### Envía la petición y lee las cabeceras de la respuesta
+
+Resumen:
+
+* `HttpNetworkTransaction` da las cabeceras de la petición al `HttpBasicStream`, y le dice que inicie la petición.
+* `HttpBasicStream` envía la petición, y espera la respuesta.
+* `HttpBasicStream` envía las cabeceras de la respuesta de vuelta a `HttpNetworkTransaction`.
+* Las cabeceras de la respuesta se envían mediante la `URLRequest` al `network::URLLoader`.
+* Se envían después al `network::mojom::URLLoaderClient` mediante Mojo.
+
+El `HttpNetworkTransaction` pasa las cabeceras de la petición al `HttpBasicStream`, que usa un `HttpStreamParser` para (finalmente) formatear las cabeceras de la petición y el cuerpo (si está presente) y enviarlos al servidor.
+
+`HttpStreamParser` espera recibir la respuesta y entonces procesa las cabeceras de respuesta HTTP/1.x, y luego las pasa mediante ambos el `HttpNetworkTransaction` y `HttpCache::Transaction` al `URLRequestHttpJob`. `URLRequestHttpJob` guarda algunas cookies, si es necesario, y entonces pasa las cabeceras arriba a la `URLRequest` y después al `network::URLLoader`, que envía la información por un _pipe_ de Mojo al `network::mojom::URLLoaderClient`, pasado al `URLLoader` cuando fue creado.
+
+### Se lee el cuerpo de la respuesta
+
+Resumen:
+
+* `network::URLLoader` crea un _pipe_ de datos de Mojo _raw_, y pasa un extremo al `network::mojom::URLLoaderClient`.
+* `URLLoader` pide un _buffer_ de memoria compartida del _pipe_ de datos de Mojo.
+* `URLLoader` dice al `URLRequest` de escribir al _buffer_ de memoria, y le dice al _pipe_ cuando la información se ha escrito al buffer.
+* Los últimos dos pasos se repiten hasta que la petición se completa.
+
+Sin esperar a oír de vuelta del `network::mojom::URLLoaderClient`, el `network::URLLoader` asigna un _pipe_ de datos de Mojo _raw_, y pasa al cliente el extremo de lectura del _pipe_. `URLLoader` entonces coge un _buffer_ IPC del _pipe_, y pasa una lectura de 64KB del cuerpo de la respuesta hacia abajo al `URLRequest` hasta abajo del todo, al `HttpStreamParser`. Una vez un poco de información ha sido leída, posiblemente menos de 64KB,
+el número de bytes leídos va de vuelta al `URLLoader`, que entonces le dice al _pipe_ de Mojo que la lectura ha sido completada, y entonces pide otro _buffer_ del _pipe_, que continúa escribiéndole información. El _pipe_ puede aplicar presión hacia atrás, para limitar la cantidad de información no consumida que puede estar en los _buffers_ de memoria compartida a la vez. Este proceso se repite hasta que el cuerpo de la respuesta se lee completamente.
+
+### URLRequest is destroyed
+
+Resumen:
+
+* Cuando se completa, `network::URLLoaderFactory` elimina el `network::URLLoader`, que elimina la `URLRequest`.
+* Durante la destrucción, el `HttpNetworkTransaction` determina si el _socket_ es reutilizable, y en ese caso le dice al `HttpBasicStream` de devolverlo a la piscina de _sockets_.
+
+Cuando el `URLRequest` informa al `network::URLLoader` que la petición se ha completado, el `URLLoader` pasa el mensaje hacia el `network::mojom::URLLoaderClient`, a través de su _pipe_ de Mojo, antes de decirle al `URLLoaderFactory` de destruir el `URLLoader`, lo que resulta en la destrucción del `URLRequest` y el cierrede todos los _pipes_ de Mojo relacionados con la petición.
+
+Cuando el `HttpNetworkTransaction` se está destruyendo, este determina si el _socket_ es reutilizable. Si no, le dice a `HttpBasicStream` de cerrarlo. En cualquier caso, el `ClientSocketHandle` devuelve el _socket_ a la piscina de _sockets_, ya sea para su reutilización o para que la piscina de _sockets_ sepa que tiene otra ranura disponible.
+
+### Relaciones entre objetos y propietarios
+
+Un ejemplo de las relaciones entre objetos involucrados en el proceso de arriba se muestre en el siguiente diagrama:
+
+
+
+Hay dos cosas del diagrama anterior que no se hacen claras visualmente:
+
+* El método que genera la cadena de filtrado que cuelga del `URLRequestJob` está declarado en `URLRequestJob`, pero la única implementación actual de esta está en `URLRequestHttpJob`, así que la generación está mostrada como ocurre desde esa clase.
+* Las `HttpTransactions` de diferentes tipos están en capas. Es decir, una `HttpCache::Transaction` contiene un puntero a una `HttpTransaction`, pero ese `HttpTransaction` que está siendo apuntado es generalmente un `HttpNetworkTransaction`.
+
+## Temas adicionales
+
+!!! info "Falta la traducción"
+ Esta sección no ha sido traducida, pero se puede consultar en el documento original (en inglés) enlazado al principio de este documento.
diff --git a/docs/chrome/error-certificado.md b/docs/chrome/error-certificado.md
index e79945d..8d5e0de 100644
--- a/docs/chrome/error-certificado.md
+++ b/docs/chrome/error-certificado.md
@@ -6,4 +6,4 @@
2. Cuando aparezca el error del certificado, haz clic en el código de error (que será algo del tipo `NET::ERR_CERT_DATE_INVALID`).
3. Justo debajo de ese código de error aparecerá la información adicional.
-
+
diff --git a/docs/chrome/no-carga-paginas-web.md b/docs/chrome/no-carga-paginas-web.md
index 2f2ca93..7402b0c 100644
--- a/docs/chrome/no-carga-paginas-web.md
+++ b/docs/chrome/no-carga-paginas-web.md
@@ -1,2 +1,4 @@
# Chrome no carga páginas web
-Este artículo se moverá en el futuro a esta página. Por el momento, lo puedes consultar [aquí](https://support.google.com/chrome/forum/AAAALHG2ljoIafpyX5abJM/?hl=es).
+
+!!! info "Migración no completada"
+ Este artículo se moverá en el futuro a esta página. Por el momento, lo puedes consultar [aquí](https://support.google.com/chrome/forum/AAAALHG2ljoIafpyX5abJM/?hl=es).
diff --git a/docs/img/chrome_url_request.png b/docs/img/chrome_url_request.png
new file mode 100644
index 0000000..9f2256a
--- /dev/null
+++ b/docs/img/chrome_url_request.png
Binary files differ
diff --git a/mkdocs.yml b/mkdocs.yml
index 32607cb..40aad51 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -20,3 +20,6 @@
- 'Error con certificado': 'chrome/error-certificado.md'
- 'Traducciones':
- 'Descarte y recarga de pestañas': 'chrome/traducciones/descarte-recarga-pestanas.md'
+ - 'Para desarrolladores':
+ - 'Vida de un objeto URLRequest': 'chrome/desarrolladores/vida-de-una-url-request.md'
+ - 'Un curso rápido sobre diagnóstico de problemas con chrome://net-internals': 'chrome/desarrolladores/curso-diagnostico-net-internals.md'
