Update life-of-a-url-request.md: Replace IPCResourceLoaderBridge with RequestPeer

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.
+* A user (e.g. the WebURLLoaderImpl for Blink) asks ResourceDispatcher to start
+the request.
 * ResourceDispatcher sends an IPC to the ResourceDispatcherHost in the
 browser process.
 
 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 a request. A RequestPeer is passed in to receive
+messages related to the request. When started, the
 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.
 
 ### 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
@@ skipping 104 matching lines @@
 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.
+figure out which RequestPeer the headers should be sent to, which
+sends them on to the RequestPeer.
 
 ### 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).