Do cookie checks in NetworkDelegate instead of the URLRequest::Delegate.

content/public/common/url_request_user_data.h

+// Copyright (c) 2012 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.
+
+#ifndef CONTENT_PUBLIC_COMMON_URL_REQUEST_USER_DATA_H_
+#define CONTENT_PUBLIC_COMMON_URL_REQUEST_USER_DATA_H_
+#pragma once
+
+#include "base/supports_user_data.h"
+#include "content/common/content_export.h"
+
+namespace content {
+
+// The content library will annotate all URLRequests with the following user
+// data if the request can be associated with a given render view.
+class CONTENT_EXPORT URLRequestUserData
+    : public base::SupportsUserData::Data {
+ public:
+  URLRequestUserData(int process_id, int routing_id);

[cbentzel, 2012/03/05 12:56:12]

Nit: this is typically called child_id rather than process_id. The reason is
that process_id doesn't match the OS's pid, so there is concern about confusion.
Or at least that's how John Abd-El-Malek explained it to me.  

[jam, 2012/03/05 19:11:03]

if this is only for renderer processes, then render_process_id/render_view_id is
best.

sometimes code is shared between renderer/workers, in that case child_id is more
correct.

+  virtual ~URLRequestUserData();
+
+  static const void* kUserDataKey;
+
+  int process_id;

[willchan no longer on Chromium, 2012/03/06 02:59:01]

How come these are public? Sorry if I'm nitting you on something another
reviewer commented on, but member variables typically should be private in
classes (this is not a struct). I think the other classes that use
SupportsUserData::Data keep member variables private.

+  int routing_id;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_COMMON_URL_REQUEST_USER_DATA_H_