[NoStatePrefetch] Support only GET and HEAD

chrome/browser/prerender/prerender_resource_throttle.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/prerender/prerender_resource_throttle.h"
 
 #include "base/logging.h"
 #include "base/numerics/safe_conversions.h"
 #include "build/build_config.h"
 #include "chrome/browser/prerender/prerender_final_status.h"
@@ skipping 103 matching lines @@
     ResourceType resource_type,
     int render_process_id,
     int render_frame_id,
     const GURL& url) {
   bool cancel = false;
   PrerenderContents* prerender_contents =
       PrerenderContentsFromRenderFrame(render_process_id, render_frame_id);
   if (prerender_contents) {
     // Abort any prerenders that spawn requests that use unsupported HTTP
     // methods or schemes.
-    if (!PrerenderManager::IsValidHttpMethod(method)) {
+    if (!prerender_contents->IsValidHttpMethod(method)) {

[mmenke, 2016/09/20 13:31:18]

Would it make more sense just to cancel the individual request, not the entire
prerender, when this fails for prefetch prerenders?  For "real" prerenders, if
we cancel a request, the entire prerender is unusable.  For prefetch prerenders,
however, the whole point is the resources we fetch, so there doesn't seem to be
a reason to cancel the prerender other resources, unless this is the main frame
request, right?

[droger, 2016/09/20 15:07:27]

I think you are right indeed, we could cancel the individual request instead of
the whole prefetch.

To do this, it would probably be enough to set cancel to true, but only call
>Destroy() if the resource_type is "main frame". I will play with this.

[droger, 2016/09/21 09:57:48]

Done, although the scenario where a prefetch subresource has an invalid method
cannot actually happen currently (since these requests are created by the HTML
preload scanner).

[mmenke, 2016/09/21 16:56:20]

Good point, though I suppose extensions and Chrome components can do all sorts
of weird things.  May make sense just to remove this class entirely, once we get
rid of prerenders.

       prerender_contents->Destroy(FINAL_STATUS_INVALID_HTTP_METHOD);
       cancel = true;
     } else if (!PrerenderManager::DoesSubresourceURLHaveValidScheme(url)) {
       prerender_contents->Destroy(FINAL_STATUS_UNSUPPORTED_SCHEME);
       ReportUnsupportedPrerenderScheme(url);
       cancel = true;
 #if defined(OS_ANDROID)
     } else if (resource_type == content::RESOURCE_TYPE_FAVICON) {
       // Delay icon fetching until the contents are getting swapped in
       // to conserve network usage in mobile devices.
@@ skipping 84 matching lines @@
   if (g_prerender_contents_for_testing)
     return g_prerender_contents_for_testing;
   content::RenderFrameHost* rfh = content::RenderFrameHost::FromID(
       render_process_id, render_frame_id);
   content::WebContents* web_contents =
       content::WebContents::FromRenderFrameHost(rfh);
   return PrerenderContents::FromWebContents(web_contents);
 }
 
 }  // namespace prerender