Issue metadata
Sign in to add a comment
|
Define Mojo interface for allowing features to participate in loading when it's in a network process |
||||||||||||||||||||||||
Issue descriptionThe parent bug tracks network service code. This will eventually run in a separate process. We need to define mojo interfaces so that the existing code which hooks into loading can do so when it's running in a different process from the network service. This includes: -protocol handlers like blob://, filesystem:// etc... -interceptors: i.e. for supporting appcache, service worker These are currently registered in StoragePartitionImplMap::Get(). We should aim for this API to be performant. i.e. as with network service in general, the goal is no performance regressions. Concretely, this means that: -the network service, once it's in a separate process, must have a configurable API to register these new protocol handler and interceptors -more specifically, the network process must not delay every request while it checks with the browser process if it wants to service the request -once the request is serviced elsewhere, the message pipe for the request should be passed along to avoid the network service acting as a proxy and adding delays
,
May 17 2016
AppCache, ServiceWorker, and Blobs seem to be the most complicated things that subclass URLRequestJobs. DataReductionProxy also injects an URLRequestInterceptor to force requests that failed when they went through the DRP to be retried by trying to connect directly to the destination server. The way a number of these classes work is they attach UserData to the URLRequest, and then retrieve it from their URLRequestInterceptor and/or URLRequestJob subclasses, and only then decide if they want to intercept the request. If we wanted to do the same thing via another API, we may need a way to say "Hey, here's a network request, but use this thing to service it". We can't actually make something else implement the URLRequest API, because a some of these things switch between net and non-net handling as a request is redirected. If we had a nice API that could register things at runtime, we could also use it in tests, in place of URLRequestFilter, which could be handy, as URLRequestFilter is pretty ugly.
,
May 17 2016
What level of abstraction does of "network service" provide? There's probably no firm answer yet but i'm wanting to point out the distinction between... -net::URLRequest -content::ResourceDispatcherHost Which of these two is closer to what the "network service" is slated to provide? I would think the latter, but just checking.
,
Jul 11 2016
,
Mar 27 2017
michaeln: To answer your question (A mere 10 months after you asked it!) is that the network service is going to be based around ResourceDispatcherHost. The renderer will use it to talk to the browser instead of ResourceDispatcher, and existing browser consumers will be switched to use it.
,
Apr 26 2017
Closing this since the current thinking is that these features will hook in before requests make it to the network process. I'll file specific bug for each feature.
,
Nov 7 2017
,
Nov 7 2017
Apologies, applied the wrong component in bulk. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by kinuko@chromium.org
, May 17 2016