LoadTiming in net part 4.

Add proxy resolution timing support.
Also document a few weird behaviors.

R=eroman@chromium.org
BUG=77446
Review URL: https://codereview.chromium.org/12047032

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@178524 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 21 insertions, 1 deletions

diff --git a/net/base/load_timing_info.h b/net/base/load_timing_info.h
index 446b1e9..3e876bd 100644
--- a/net/base/load_timing_info.h
+++ b/net/base/load_timing_info.h
@@ -14,6 +14,9 @@ namespace net {
 // All events that do not apply to a request have null times.  For non-HTTP
 // requests, all times other than the request_start times are null.
 //
+// Requests with connection errors generally only have request start times as
+// well, since they never received an established socket.
+//
 // The general order for events is:
 // request_start
 // proxy_start
@@ -33,6 +36,14 @@ namespace net {
 // by the connection attempt itself.  Since the connection attempt may be
 // started before a URLRequest, the starred times may occur before, during, or
 // after the request_start and proxy events.
+//
+// DNS and SSL times are both times for the host, not the proxy, so DNS times
+// when using proxies are null, and only requests to HTTPS hosts (Not proxies)
+// have SSL times.  One exception to this is when a proxy server itself returns
+// a redirect response.  In this case, the connect times treat the proxy as the
+// host.  The send and receive times will all be null, however.
+// See HttpNetworkTransaction::OnHttpsProxyTunnelResponse.
+// TODO(mmenke):  Is this worth fixing?
 struct NET_EXPORT LoadTimingInfo {
   // Contains the LoadTimingInfo events related to establishing a connection.
   // These are all set by ConnectJobs.
@@ -76,11 +87,20 @@ struct NET_EXPORT LoadTimingInfo {
   // True if the socket was reused.  When true, DNS, connect, and SSL times
   // will all be null.  When false, those times may be null, too, for non-HTTP
   // requests, or when they don't apply to a request.
+  //
+  // For requests that are sent again after an AUTH challenge, this will be true
+  // if the original socket is reused, and false if a new socket is used.
+  // Responding to a proxy AUTH challenge is never considered to be reusing a
+  // socket, since a connection to the host wasn't established when the
+  // challenge was received.
   bool socket_reused;
 
   // Unique socket ID, can be used to identify requests served by the same
   // socket.
-  // TODO(mmenke):  Do something reasonable for SPDY proxies.
+  // TODO(mmenke):  Do something reasonable for SPDY proxies.  Currently, SPDY
+  //                sessions (And HTTPS requests?) over SPDY proxies use the ID
+  //                of the SPDY proxy's session.  HTTP requests, however, use
+  //                the ID of the SPDY proxy's socket.
   uint32 socket_log_id;
 
   // Start time as a base::Time, so times can be coverted into actual times.