Typo fix in life-of-a-url-request.md

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
 stack, but are largely unfamiliar with other components. It starts by walking
 through how a basic request issued by another process works its way through the
 network stack, and then moves on to discuss how various components plug in.
 
 If you notice any inaccuracies in this document, or feel that things could be
 better explained, please do not hesitate to submit patches.
 
 # Anatomy of the Network Stack
 
-The top-level network stack object is the URLRequextContext. The context has
+The top-level network stack object is the URLRequestContext. The context has
 non-owning pointers to everything needed to create and issue a URLRequest. The
 context must outlive all requests that use it. Creating a context is a rather
 complicated process, and it's recommended that most consumers use
 URLRequestContextBuilder to do this.
 
 Chrome has a number of different URLRequestContexts, as there is often a need to
 keep cookies, caches, and socket pools separate for different types of requests.
 Here are the ones that the network team owns:
 
 * The proxy URLRequestContext, owned by the IOThread and used to get PAC
@@ skipping 472 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).