Remove the HANDLED_EXTERNALLY status code.

net/url_request/url_request.cc

Index: net/url_request/url_request.cc
diff --git a/net/url_request/url_request.cc b/net/url_request/url_request.cc
index 3f62e0c6b2aeda742ef72abe9d4b06c88a5313ab..a86b8e34f1f9c026cc6c4cdcfb6d42e50c21f9ef 100644
--- a/net/url_request/url_request.cc
+++ b/net/url_request/url_request.cc
@@ -513,8 +513,6 @@ void URLRequest::CancelWithSSLError(int error, const SSLInfo& ssl_info) {
 }
 
 void URLRequest::DoCancel(int error, const SSLInfo& ssl_info) {
-  DCHECK(error < 0);

[darin (slow to review), 2012/07/11 18:12:43]

It feels wrong to allow non-negative (non-error) results here.  If we want to
support cancelling the request with OK_HANDLED_EXTERNALLY, then we should
probably make it a negative value: ERR_HANDLED_EXTERNALLY.

This brings us back to the previous discussion about whether or not this is an
error code or a success code.  We should also think about whether we want the
network stack to know about the concept of "handled externally".

The goal of removing URLRequestStatus::HANDLED_EXTERNALLY is either to remove
the concept of "handled externally" from the network stack or to help us
eliminate URLRequestStatus altogether.  Both seem like reasonable goals.

I am curious about completely eliminating the "handled externally" concept from
the network stack since it isn't something that makes much sense to a network
stack.  A network stack produces data or errors.

"handled externally" is something that only makes sense to web page navigation
requests.

-
   // If the URL request already has an error status, then canceling is a no-op.
   // Plus, we don't want to change the error status once it has been set.
   if (status_.is_success()) {