5 seconds delay on https 302 response (SAFE_BROWSING_DEFERRED)
Reported by
baiy...@gmail.com,
Nov 4 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Example URL: https://zhiyejing.com Steps to reproduce the problem: 1. Restart (close and open) chrome. 2. View the website 3. Request: "https://zhiyejing.com/FFC/GEN/PRO/GetCover?deco=190x225&id=105864558983250632&attid=105864559457206985" will take five seconds. What is the expected behavior? Should not hang 5 seconds. What went wrong? Event 420: URL_REQUEST https://zhiyejing.com/FFC/GEN/PRO/GetCover?deco=190x225&id=105864558983250632&attid=105864559457206985： t=1788 [st= 18] SAFE_BROWSING_DEFERRED --> source_dependency = 421 (SAFE_BROWSING) t=1788 [st= 18] +DELEGATE_INFO [dt=5002] --> delegate_info = "SafeBrowsingResourceThrottle" t=1798 [st= 28] URL_REQUEST_SET_PRIORITY --> priority = "MEDIUM" t=6790 [st=5020] SAFE_BROWSING_DEFERRED --> source_dependency = 421 (SAFE_BROWSING) t=6790 [st=5020] SAFE_BROWSING_CHECKING_URL --> source_dependency = 421 (SAFE_BROWSING) t=6790 [st=5020] -DELEGATE_INFO Event 421: SAFE_BROWSING Start Time: 2016-11-04 18:35:23.568 t=1788 [st= 0] +SAFE_BROWSING_CHECKING_URL [dt=5002] --> source_dependency = 420 (URL_REQUEST) --> url = "https://dn-zhiyejing-pub.qbox.me/105864559457206985/190x225" t=1788 [st= 0] +SAFE_BROWSING_DEFERRED [dt=5002] --> defer_reason = "redirect" --> source_dependency = 420 (URL_REQUEST) --> url = "https://dn-zhiyejing-pub.qbox.me/105864559457206985/190x225" t=6790 [st=5002] -SAFE_BROWSING_DEFERRED t=6790 [st=5002] -SAFE_BROWSING_CHECKING_URL --> result = "safe" Did this work before? N/A Chrome version: 53.0.2785.143 Channel: stable Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 23.0 r0 No extension installed.
,
Nov 4 2016
This is likely due to a full-hash request timing out. If Google is not reachable and there is a hash-collision between something on the current page and a blacklisted site, this will happen. It's how the system is designed, and it'll happen on about 1 out of 1000 resources.
,
Nov 4 2016
Yes, Google is not reachable in china mainland, 1/1000 of collision ratio seems too high, is there any method to moderate it?
,
Nov 4 2016
I can confirm that this URL leads to a full hash request. That may not be the only reason for the 5 second delay, but it did contribute to it. [Also, anecdotal so not very useful, but it doesn't take that long for me to load that URL.]
,
Nov 8 2016
1/1000 requests means roughly 1 in 10 page loads requires a 5-second safe-browsing lookup in China. And for the unfortunate sites that have prefix matches (but not full matches) on their primary resources, they'll always have this performance hit. Perhaps we shouldn't enable safe-browsing by default in China? Or find a way to reduce false-positives?
,
Nov 8 2016
One more data point: If the browser was _never_ able to connect to Google, then it won't have downloaded any blacklist database, and then it'll never do a full-hash check. So it won't cause any delays. If we had a google-is-unreachable detector, Safe Browsing hash-checks could be gated on that. Beyond that, I'm glad to chat about Safe Browsing in China offline.
,
Nov 8 2016
From China, the connectivity with google may be resumed occasionally and randomly. It is because the unknown mechanism of the GFW (Great Fire Wall). I guess the blacklist database been downloaded that time.
,
Nov 18 2016
Thanks for reporting this issue. This is on our radar but not prioritized at the moment. An unfortunate workaround is to turn off SafeBrowsing when Google is unreachable. |
|||
►
Sign in to add a comment |
|||
Comment 1 by mmenke@chromium.org
, Nov 4 2016Components: -Internals>Network Services>Safebrowsing
Labels: Performance