Deduplicating CanReadRequestBody code.

content/browser/loader/DEPS

Index: content/browser/loader/DEPS
diff --git a/content/browser/loader/DEPS b/content/browser/loader/DEPS
index 191c9259b8ec1dcfe99e579e1b19d5e1feee9435..c75601eaa2e462782a32d23540a74bf947fc137f 100644
--- a/content/browser/loader/DEPS
+++ b/content/browser/loader/DEPS
@@ -154,6 +154,7 @@ specific_include_rules = {
     "+content/browser/loader/redirect_to_file_resource_handler.h",
     "+content/browser/loader/upload_data_stream_builder.h",
     "+content/browser/resource_context_impl.h",
+    "+content/browser/resource_request_body_browser_utils.h",

[Łukasz Anforowicz, 2017/05/25 16:11:37]

I assume that after decoupling from the rest of //content,
content/browser/loader will define an abstract LoaderDelegate interface that
will be used to interact with things that should stay in the //content.  I
assume that ResourceDispatcherHostImpl::ShouldServiceRequest(...) will move into
LoaderDelegate::ShouldServiceRequest(...) that will overriden/implemented in the
content layer.  Therefore I think it is okay to add the dependency above - this
dependency will stay in the //content layer in the end (i.e. the dependency
would be used from ContentLoaderDelegate::ShouldServiceRequest).

Does what I said above make sense?

How can we deduplicate the code while still supporting the efforts for
decoupling the loader from the rest of //content?

[mmenke, 2017/05/25 16:31:08]

For better or for worse, the plan is now to make a service from scratch, so it
won't be using this code at all.

The RDH-equivalent will be in a separate process, unclear how much, if any,
Chrome code will be in that process.

[Łukasz Anforowicz, 2017/05/25 16:50:26]

Does that mean that the change to the DEPS file looks okay?

     "+content/browser/service_worker/foreign_fetch_request_handler.h",
     "+content/browser/service_worker/link_header_support.h",
     "+content/browser/service_worker/service_worker_context_wrapper.h",