Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 49493 Unable to browse "https://" sites
Starred by 23 users Reported by roman.ro...@gmail.com, Jul 19 2010 Back to list
Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jul 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug
M-6

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Chrome Version       : 6.0.466.0 (Official Build 52279) dev
URLs (if applicable) : anything with SSL secured ie. https://chrome.google.com/extensions

Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK
  Beta and Stable Versions of Chrome: OK

What steps will reproduce the problem?
1. Just go to any https:\\ site

What is the expected result?
Expect to see the site.

What happens instead?
See an error page:

This webpage is not available.

The webpage at https://chrome.google.com/extensions might be temporarily down or it may have moved permanently to a new web address.

  More information on this error
Below is the original error message

Error 9 (net::ERR_UNEXPECTED): Unknown error.

Please provide any additional information below. Attach a screenshot if
possible.

Attached a screenshot and my chrome_debug.log 

 
error-screenshot.PNG
29.2 KB View Download
chrome_debug.log
11.3 KB View Download
Labels: -Area-Undefined Area-Internals not-extensions
Just to double-check, did you try browsing to any other secure websites just to make sure it wasn't this one site being temporarily down? (eg https://encrypted.google.com/ )
Chrome Version: 6.0.466.0 

I am encountering the same problem just after updating to the latest dev build. The previous dev build was working fine just minutes before. Any HTTPS site will fail and I noticed that LastPass will also fail since it is undoubtedly using SSL to do it's magic.
@asargent, yes I tried plenty of https:// sites, none of them work in this build. At the same time, they all work in all other browsers. This is an issue with the latest dev build because the previous dev build was working fine.

To add more info, I have tried completely uninstalling Chrome and re-installing the dev build, with no changes. I am also behind a WebMarshal proxy here. Reading the release notes for this build I noticed:

-- Late binding enabled for SSL sockets: High priority SSL requests are now always sent to the server first.

So, maybe it has something to do with this error.
The same build works fine from home with no proxy, but fails at work with proxy so I would say @roman.radov is on the right track here.
Just tried to go back to 458.1 dev and that was just crashing all the time. Went back to 453.1 dev and that's working fine, https is working as well. Definetly something is broken in 466.0 dev. Cheers.
Issue 49553 has been merged into this issue.
Labels: OS-All Mstone-6 Internals-Network
Status: Assigned
roman.rodov, can you confirm that with a recent build (post 466.0) you see net::ERR_TUNNEL_CONNECTION_FAILED.

Providing some network debug information will help resolve this problem:  Open chrome://net-internals in a new tab, visit an https site in a different tab and get the error, then click the "Dump to text" button on the net-internals page and paste the result (or email it to me, if you'd rather).
The net-internals log is attached. I've done a clean install of 466.0. Navigated to https://tools.google.com, got ERR_UNEXPECTED.

Uninstalled 466.0, installed latest Chromium build 53108 from http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/53108/. Navigated to https://tools.google.com, got 
Error 111 (net::ERR_TUNNEL_CONNECTION_FAILED): Unknown error.

The net-internals-post-466 log is attached as well.
Chris, does the 502 after a failed Negotiate mean something to you?
roman.rodov: Thanks for attaching net-internals.

The 502 in this case seems to be the response from the proxy after the authentication process does not succeed.

roman.rodov: There have been code changes recently in both the tunneling code paths and the Negotiate authentication code paths. Could you change the proxy temporarily to only specify Basic (or NTLM) authentication challenges to help us figure out where the problem is?



Unfortunately not, I have no control over the proxy :( This is a corporate proxy in a big company :)
I had this problem in 6.0.466.0  (behind enterprise proxy with authentication)

But today, with 6.0.472.0, when trying to access https sites, I get stuck on my proxy authenticating popup (keeps poping up, can't access the site)
Had the same issue in 6.0.466.0 and today solved in 6.0.472.0

Cedric: I had the same issue with popping-up authentication window, how I dealt with this is I authenticated once, and then hit cancel in the next couple of authentication requests, then I hit refresh and whole page loaded successfully. It happened for me while opening Gmail, and from my understanding, the browser has been trying to do multiple ajax requests, that's why I think there were many authentication requests.
I still can't pass the authentication proxy.
I just tested again with https://encrypted.google.com/
and the popup won't go away no matter the number of times I press OK.

And as soon as I press Cancel it fails :
 Erreur 111 (net::ERR_TUNNEL_CONNECTION_FAILED) : Erreur inconnue

And a refresh will just bring back the popup
I've tried https://encrypted.google.com/, and yes, the authentication box kept popping up. What's strange or interesting, is that each time I've hit refresh instead of authenticating myself, more of the page kept loading, so after 5-7 refreshes, the site loaded successfully, and no authentication box appeared.

So, still, even though I'm not getting explicit error messages, as you do, the browser's behavior is not correct.

ps
Is there a way I can help/provide more technical info (logs?) to the Dev Team?
Thanks for the additional reports.

Which platform are you running on (OSX, Linux, Windows)?

For additional data, go to about:net-internals in Chrome, click "Dump to Text" and either append to this bug or email the results to cbentzel@chromium.org or vandebo@chromium.org. Please scrub out any information you wish to keep private.
the dev channel version immediately before 466 was the only one in which I
had no issues connecting through my company's proxy, either because of "page
unavailable" or because of endless login prompts.  i was so happy.
I am getting the same problem with HTTPS sites. It is causing a "Web page is not available" error with either "Error 101 (net::ERR_CONNECTION_RESET): Unknown error." or "Error 9 (net::ERR_UNEXPECTED): Unknown error.". After some refreshes (all unsuccessful) the browser will often crash.

Attached is the about:net-internals. I'm running on Windows XP SP3 with 6.0.472.0 behind an NTLM authenticated proxy server. Version 466 was worse, and I couldn't go to any HTTPS sites. The version before that had no issues.

log.txt
195 KB View Download
I'm not sure if that last is of any use. Here is another one that specifically shows the CONNECTION_RESET error in it.
log2.txt
141 KB View Download
Anthony, Wan-Teh: This is definitely a blocker for mstone6. This has a different root cause from http://crbug.com/49865
thomas.samoht: Thanks for the report, that helped immensely.

vandebo: Between this and some of the other reports, it looks like we are sending up a Negotiate or NTLM response to the proxy before actually seeing a challenge. This can happen in one of two ways.
  - We are incorrectly doing a preemptive authentication on those two schemes.
  - A non-fresh HttpAuthController is being incorrectly used for tunnel authentication. 
Comment 23 by wtc@chromium.org, Jul 23 2010
Labels: -Pri-2 Pri-1 ReleaseBlock-Beta
The net::ERR_UNEXPECTED error code should help narrow down the
possible points of failure in our source code.
My hunch is that reference counted HttpAuthControllers are causing this. So I made this cl: http://codereview.chromium.org/3039028  Instead of a DCHECK when visiting an https site, I now consistently get ERR_TUNNEL_CONNECTION_FAILED. Unfortunately, I won't be ale to look at it more until Sunday.
Status: Started
Any update on this? I just updated to 6.0.472.11 dev but am still seeing this bug and hence can't access any https sites.
vandebo and I have been looking into it, and have discovered the root problem - essentially, there's a bit of a mismatch with using SocketPool's for stateful authentication like NTLM and Negotiate. The fix is unfortunately not simple.  
No worries, thanks for the update, also thanks for your efforts in trying to fix it, they're definitely appreciated. Cheers.
Comment 29 Deleted
Updated a second ago to 6.0.472.11
Bug still exists, attached net-internals.
Good luck!

Google_Chrome_6.0.472.11_net-internals_https_error_111_net_ERR_TUNNEL_CONNECTION_FAILED.log
64.6 KB View Download
Yes, still not corrected in 6.0.472.11
But I am surprised it is not in the "Known Issues" of the release note, since it is a blocking bug for Chrome behind an authenticating proxy (quite common configuration in enterprise)
Hi,

here is my contrib to the diagnosis : I've Wireshared the communications on a Chrome 5.0.375.125 and on a Chromium 6.0.479.0 (54100) for an access to an HTTPS site behind my company proxy which is using NTLM for auth.
Then I have compared the discussions.

Here is my analysis/main différences :
- the NTLMSSP_NEGOTIATE phase is OK on both
- the problem is on the NTLMSSP_AUTH phase : on Chrome, the proxy replies with a HTTP 200, on Chromium a 407 (auth required : start over the auth phase)

Analysis of the NTLMSSP_AUTH phase :
- chromium is not sending its user agent
- On Chromium only (Chrome is OK), Wireshark badly interprets domain name, user name and hostname : it only sees the first character even if length, maxlength and offset are correct and domain name, user name and hostname data *are present* in the NTLM data
If Wireshark does not interpret correctly the data, there is a high probability that the proxy will do the same --> bad user name etc... --> auth fail
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=54405 

------------------------------------------------------------------------
r54405 | vandebo@chromium.org | 2010-07-30 16:21:59 -0700 (Fri, 30 Jul 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket.h?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool.h?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool_unittest.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_handle.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_handle.h?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socket_test_util.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socket_test_util.h?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool.cc?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool.h?r1=54405&r2=54404
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool_unittest.cc?r1=54405&r2=54404

Fix late binding induced mismatch of Socket and AuthController

ClientSocketPool treats all pending SocketParams as interchangeable. Therefore they can not contain any connection specific data.  This only affects the Http Proxy tunnel case. The lowest risk change to fix this problem is to create the HttpAuthController in the HttpProxyClientSocket.  If we get a 407 and need to restart the Tunnel, the pending HttpProxyClientSocket is returned to the HttpNetworkTransaction in the additional error state of the connection and then complete the auth in a pair of states in the HttpNetworkTransaction.  This reintroduces a dependency between tunnel setup and the HttpNetworkTransaction, but that will need to be fixed at a later date.

BUG= 49493 
TEST=existing unit tests + manually visiting many SSL sites through a kerberized http proxy.

Review URL: http://codereview.chromium.org/3058013
------------------------------------------------------------------------

Status: WillMerge
r54405 should fix this issue.  Please post about any cases where it does not.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=54616 

------------------------------------------------------------------------
r54616 | nick@chromium.org | 2010-08-02 15:03:12 -0700 (Mon, 02 Aug 2010) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket.h?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool.h?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool_unittest.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_handle.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_handle.h?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socket_test_util.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socket_test_util.h?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool.cc?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool.h?r1=54616&r2=54615
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool_unittest.cc?r1=54616&r2=54615

Revert 54405 - Fix late binding induced mismatch of Socket and AuthController

[Reason for revert: large spike in crash rate on reliability bots]

ClientSocketPool treats all pending SocketParams as interchangeable. Therefore they can not contain any connection specific data.  This only affects the Http Proxy tunnel case. The lowest risk change to fix this problem is to create the HttpAuthController in the HttpProxyClientSocket.  If we get a 407 and need to restart the Tunnel, the pending HttpProxyClientSocket is returned to the HttpNetworkTransaction in the additional error state of the connection and then complete the auth in a pair of states in the HttpNetworkTransaction.  This reintroduces a dependency between tunnel setup and the HttpNetworkTransaction, but that will need to be fixed at a later date.

BUG= 49493 , 50822 
TEST=existing unit tests + manually visiting many SSL sites through a kerberized http proxy.

Review URL: http://codereview.chromium.org/3058013

TBR=vandebo@chromium.org
Review URL: http://codereview.chromium.org/3056040
------------------------------------------------------------------------

Status: Fixed
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=54714 

------------------------------------------------------------------------
r54714 | vandebo@chromium.org | 2010-08-03 00:38:59 -0700 (Tue, 03 Aug 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket.h?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool.h?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_proxy_client_socket_pool_unittest.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_handle.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_handle.h?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socket_test_util.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socket_test_util.h?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool.cc?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool.h?r1=54714&r2=54713
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_pool_unittest.cc?r1=54714&r2=54713

Recommit 54405 - Fix late binding induced mismatch of Socket and AuthController

ClientSocketPool treats all pending SocketParams as interchangeable. Therefore they can not contain any connection specific data. This only affects the Http Proxy tunnel case. The lowest risk change to fix this problem is to create the HttpAuthController in the HttpProxyClientSocket. If we get a 407 and need to restart the Tunnel, the pending HttpProxyClientSocket is returned to the HttpNetworkTransaction in the additional error state of the connection and then complete the auth in a pair of states in the HttpNetworkTransaction. This reintroduces a dependency between tunnel setup and the HttpNetworkTransaction, but that will need to be fixed at a later date.

Original Review URL: http://codereview.chromium.org/3058013

BUG= 49493 
TEST=existing unit tests + manually visiting many SSL sites through a kerberized http proxy.

Review URL: http://codereview.chromium.org/3029052
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=54732 

------------------------------------------------------------------------
r54732 | vandebo@chromium.org | 2010-08-03 04:15:18 -0700 (Tue, 03 Aug 2010) | 14 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/base/net_error_list.h?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_network_transaction.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_network_transaction.h?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_network_transaction_unittest.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_proxy_client_socket.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_proxy_client_socket.h?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_proxy_client_socket_pool.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_proxy_client_socket_pool.h?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/http/http_proxy_client_socket_pool_unittest.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/socket/client_socket_handle.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/socket/client_socket_handle.h?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/socket/socket_test_util.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/socket/socket_test_util.h?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/socket/ssl_client_socket_pool.cc?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/socket/ssl_client_socket_pool.h?r1=54732&r2=54731
   M http://src.chromium.org/viewvc/chrome/branches/472/src/net/socket/ssl_client_socket_pool_unittest.cc?r1=54732&r2=54731

Merge 54714 - Recommit 54405 - Fix late binding induced mismatch of Socket and AuthController

ClientSocketPool treats all pending SocketParams as interchangeable. Therefore they can not contain any connection specific data. This only affects the Http Proxy tunnel case. The lowest risk change to fix this problem is to create the HttpAuthController in the HttpProxyClientSocket. If we get a 407 and need to restart the Tunnel, the pending HttpProxyClientSocket is returned to the HttpNetworkTransaction in the additional error state of the connection and then complete the auth in a pair of states in the HttpNetworkTransaction. This reintroduces a dependency between tunnel setup and the HttpNetworkTransaction, but that will need to be fixed at a later date.

Original Review URL: http://codereview.chromium.org/3058013

BUG= 49493 
TEST=existing unit tests + manually visiting many SSL sites through a kerberized http proxy.

Review URL: http://codereview.chromium.org/3029052

TBR=vandebo@chromium.org

Review URL: http://codereview.chromium.org/3066031
------------------------------------------------------------------------

Comment 39 by Deleted ...@, Aug 5 2010
Aug. 5 I am still having this problem and have had it since the first day I added Google Chrome.  I see that above it says it's fixed but it isn't.
rocnbeva1: Could you please specify which version of Chrome you are using? Open a new tab and go to about:version. Thanks!
I'm having the same problem as described in comment 39 above (unable to access my gmail account for instance). Here is my about:version info:
Chromium	6.0.486.0 (Developer Build 55037)
WebKit	534.5
V8	2.3.4.1
User Agent	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.5 (KHTML, like Gecko) Chrome/6.0.486.0 Safari/534.5
mmartinelli: Are you having problems with all SSL sites, or just Google properties? i.e does your bank/amazon/etc work?  If you can attach a copy of net-internals (see comment 8), that may help find the problem.
Comment 43 Deleted
vandebo, attached is the net-internals output txt file and an updated about:version below:

Chromium	6.0.487.0 (Developer Build 55202)
WebKit	        534.5
V8	        2.3.5.3
User Agent	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.5 (KHTML, like Gecko) Chrome/6.0.487.0 Safari/534.5
Command Line	"D:\Marcelo\mmartinelli\bin\chromium\chrome-win32\chrome.exe" --enable-geolocation --enable-internal-flash --enable-extension-timeline-api --enable-sync-extensions --sync-url=https://clients4.google.com/chrome-sync/dev

Also, I seem to see the problem surface only on Google sites. I was able to login to amazon.com and other https sites, no problem.
net-internals.txt
289 KB View Download
mmartinelli:  You are having a different problem than this bug, I opened bug 51405 for you.  You should star it so that you get updates.
Labels: Restrict-AddIssueComment-Commit
Closing this bug to comments. I think this issue has been resolved.  Please open a new bug for any further problems.
Project Member Comment 47 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Mstone-6 -Internals-Network M-6 Cr-Internals Cr-Internals-Network
Project Member Comment 48 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment