Update the Life of a URL request document to not reference IPCResourceLoaderBridge.

net/docs/life-of-a-url-request.md

 # Life of a URLRequest
 
 This document is intended as an overview of the core layers of the network
 stack, their basic responsibilities, how they fit together, and where some of
 the pain points are, without going into too much detail. Though it touches a
 bit on child processes and the content/loader stack, the focus is on net/
 itself.
 
 It's particularly targeted at people new to the Chrome network stack, but
 should also be useful for team members who may be experts at some parts of the
@@ skipping 85 matching lines @@
 request, the response is uncompressed, no matching entry in the cache, and there
 are no idle sockets connected to the server in the socket pool.
 
 Continuing with a "simple" URLRequest, here's a bit more detail on how things
 work.
 
 ### Request starts in a child process
 
 Summary:
 
-* ResourceDispatcher creates an IPCResourceLoaderBridge.
-* The IPCResourceLoaderBridge asks ResourceDispatcher to start the request.
-* ResourceDispatcher sends an IPC to the ResourceDispatcherHost in the
-browser process.
+* Network consumers in child processes interact with ResourceDispatcher to
+start/cancel/read/write network requests.
+* ResourceDispatcher acts as a proxy to the browser process (where the
+networking is actually carried out).
 
 Chrome has a single browser process, which handles network requests and tab
 management, among other things, and multiple child processes, which are
 generally sandboxed so can't send out network requests directly. There are
 multiple types of child processes (renderer, GPU, plugin, etc). The renderer
 processes are the ones that layout webpages and run HTML.
 
 Each child process has at most one ResourceDispatcher, which is responsible for
 all URL request-related communication with the browser process. When something
 in another process needs to issue a resource request, it calls into the
-ResourceDispatcher, which returns an IPCResourceLoaderBridge to the caller.
-The caller uses the bridge to start a request. When started, the
+ResourceDispatcher to start either a synchronous or asynchronous request.
+
 ResourceDispatcher assigns the request a per-renderer ID, and then sends the
 ID, along with all information needed to issue the request, to the
 ResourceDispatcherHost in the browser process.
 
+When starting asynchronous requests, callers provide a RequestPeer which acts
+much like a URLRequest::Delegate does in the browser process (receives
+notifications of progress/completion for the network request).
+
 ### ResourceDispatcherHost sets up the request in the browser process
 
 Summary:
 
 * ResourceDispatcherHost uses the URLRequestContext to create the URLRequest.
 * ResourceDispatcherHost creates a ResourceLoader and a chain of
 ResourceHandlers to manage the URLRequest.
 * ResourceLoader starts the URLRequest.
 
 The ResourceDispatcherHost (RDH), along with most of the network stack, lives
@@ skipping 98 matching lines @@
 
 The HttpStreamParser waits to receive the response and then parses the HTTP/1.x
 response headers, and then passes them up through both the
 HttpNetworkTransaction and HttpCache::Transaction to the URLRequestHttpJob. The
 URLRequestHttpJob saves any cookies, if needed, and then passes the headers up
 to the URLRequest and on to the ResourceLoader.
 
 The ResourceLoader passes them through the chain of ResourceHandlers, and then
 they make their way to the AsyncResourceHandler. The AsyncResourceHandler uses
 the renderer process ID ("child ID") to figure out which process the request
-was associated with, and then sends the headers along with the request ID to
-that process's ResourceDispatcher. The ResourceDispatcher uses the ID to
-figure out which IPCResourceLoaderBridge the headers should be sent to, which
-sends them on to whatever created the IPCResourceLoaderBridge in the first
-place.
+originated from, and then sends the headers along with the request ID to
+that process's ResourceDispatcher. The ResourceDispatcher then forwards the
+response to the RequestPeer that was attached to the request.
 
 ### Response body is read
 
 Summary:
 
 * AsyncResourceHandler allocates a 512k ring buffer of shared memory to read
 the body of the request.
 * AsyncResourceHandler tells the ResourceLoader to read the response body to
 the buffer, 32kB at a time.
 * AsyncResourceHandler informs the ResourceDispatcher of each read using
@@ skipping 244 matching lines @@
 connection is established, the first usable connection goes to the highest
 priority socket request.
 
 ## Non-HTTP Schemes
 
 The URLRequestJobFactory has a ProtocolHander for each supported scheme.
 Non-HTTP URLRequests have their own ProtocolHandlers. Some are implemented in
 net/, (like FTP, file, and data, though the renderer handles some data URLs
 internally), and others are implemented in content/ or chrome (like blob,
 chrome, and chrome-extension).