Issue 3772: Distributed reliability test failures with NewHTTP
http://code.google.com/p/chromium/issues/detail?id=3772

Comment #9 by [EMAIL PROTECTED]:
wtc points out that establishing_tunnel_ is set to false inside of the 200  
case, so we still need to
explain the mismatch of establishing_tunnel_.

Thinking out load here, I can see two scenarios:

1. establishing_tunnel_ never got set to true to start with.
2. establishing_tunnel_ got set to true, and then back to false

For case (2), it would mean that DoConnectComplete() never reached the  
block that sets
establishing_tunnel_ to true. In order for that to happen, the connect  
result would have to be !=
OK. This then sends control down into ReconsiderProxyAfterError().  
TODO(eroman): is there a control
path through ReconsiderProxyAfterError() that can allow this.

For case (1), there is only 1 place where we set establishing_tunntle_ to  
false:

if (establishing_tunnel_ && headers->response_code() == 200) {
...
}

All I can think of here is that the second part of the expression is wrong.
HttpResponseHeaders::response_code() will return 200 for malformed  
responses, so it may be possible
that in one piece of code we think it is an error, and in another piece of  
code (here) we think it
is OK.





-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Chromium-bugs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to