Pass in bad proxy to NotifyProxyFallback and not the successful one.

Pass in bad proxy to NotifyProxyFallback and not the successful one.

This cl fixes a bug which was causing the final successful proxy
to be passed to NotifyProxyFallback rather than the proxy for which
fallback happened.

BUG=395769
Committed: https://crrev.com/0391069e0646754f934bce7407fce8acaee0bb27
Cr-Commit-Position: refs/heads/master@{#294039}

[Not at Google. Contact bengr, 2014-09-09 18:51:21]

kundaji@chromium.org changed reviewers:
+ bengr@chromium.org

[Not at Google. Contact bengr, 2014-09-09 20:01:27]

kundaji@chromium.org changed reviewers:
+ mmenke@chromium.org

[Not at Google. Contact bengr, 2014-09-09 20:02:35]

net/*: mmenke

[mmenke, 2014-09-09 20:29:16]

On 2014/09/09 20:02:35, kundaji wrote:
> net/*: mmenke

LGTM

[bengr, 2014-09-09 20:43:30]

https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service.cc
File net/proxy/proxy_service.cc (right):

https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service....
net/proxy/proxy_service.cc:1254: const ProxyRetryInfo& proxy_retry_info =
iter->second;
Is it correct to always use SCHEME_HTTP?

[Not at Google. Contact bengr, 2014-09-09 20:51:30]

https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service.cc
File net/proxy/proxy_service.cc (right):

https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service....
net/proxy/proxy_service.cc:1254: const ProxyRetryInfo& proxy_retry_info =
iter->second;
On 2014/09/09 20:43:30, bengr1 wrote:
> Is it correct to always use SCHEME_HTTP? 

SCHEME_HTTP is the default used by the net stack as far as I can see. For
example, see
https://code.google.com/p/chromium/codesearch#chromium/src/net/proxy/proxy_li....

[bengr, 2014-09-09 21:48:23]

On 2014/09/09 20:51:30, kundaji wrote:
>
https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service.cc
> File net/proxy/proxy_service.cc (right):
> 
>
https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service....
> net/proxy/proxy_service.cc:1254: const ProxyRetryInfo& proxy_retry_info =
> iter->second;
> On 2014/09/09 20:43:30, bengr1 wrote:
> > Is it correct to always use SCHEME_HTTP? 
> 
> SCHEME_HTTP is the default used by the net stack as far as I can see. For
> example, see
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/proxy/proxy_li....

That can't be right. See:
https://code.google.com/p/chromium/codesearch#chromium/src/net/proxy/proxy_se...

Won't this all break if QUIC is used?

[bengr, 2014-09-09 21:52:24]

On 2014/09/09 21:48:23, bengr1 wrote:
> On 2014/09/09 20:51:30, kundaji wrote:
> >
>
https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service.cc
> > File net/proxy/proxy_service.cc (right):
> > 
> >
>
https://codereview.chromium.org/556933003/diff/20001/net/proxy/proxy_service....
> > net/proxy/proxy_service.cc:1254: const ProxyRetryInfo& proxy_retry_info =
> > iter->second;
> > On 2014/09/09 20:43:30, bengr1 wrote:
> > > Is it correct to always use SCHEME_HTTP? 
> > 
> > SCHEME_HTTP is the default used by the net stack as far as I can see. For
> > example, see
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/proxy/proxy_li....
> 
> That can't be right. See:
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/proxy/proxy_se...
> 
> Won't this all break if QUIC is used?

I see that it won't now. Lgtm.

[Not at Google. Contact bengr, 2014-09-09 22:02:29]

The CQ bit was checked by kundaji@chromium.org

[commit-bot: I haz the power, 2014-09-09 22:06:32]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kundaji@chromium.org/556933003/20001

[commit-bot: I haz the power, 2014-09-09 23:50:00]

Committed patchset #2 (id:20001) as f6eb941fa3d9c561e3f4b573d5e639ea3df3fafa

[commit-bot: I haz the power, 2014-09-10 03:56:38]

Patchset 2 (id:??) landed as
https://crrev.com/0391069e0646754f934bce7407fce8acaee0bb27
Cr-Commit-Position: refs/heads/master@{#294039}