Issue metadata
Sign in to add a comment
|
walmart web app suffer beacon loss issue with error server-refused-stream
Reported by
joanna.c...@gmail.com,
Oct 4
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. go to walmart.com 2. search nike actually go to https://www.walmart.com/search/?query=nike 3. open developer tool --> network 4. at filter box input `SEARCH_VIEW` you could see one failed beacon request What is the expected behavior? expect success What went wrong? request failed this failed happen at 9/18 Did this work before? Yes Does this work in other browsers? N/A Chrome version: 69.0.3497.100 Channel: stable OS Version: OS X 10.13.6 Flash Version: it may be because our long request, however the request drop not happen at firefox and IE
,
Oct 4
,
Oct 5
Unable to reproduce the issue on chrome reported version# 69.0.3497.100 using Mac 10.13.6 with steps mentioned below: 1) Launched chrome reported version and navigated to URL: walmart.com, page got loaded 2) Searched for 'nike', page got navigated to "https://www.walmart.com/search/?query=nike" 3) OPened Devtools > Network tab, in search filter box searched for 'SEARCH_VIEW', able to see two instances but not in failed state. @Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue. Try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists. Thanks!
,
Oct 9
Also cannot reproduce on Linux 69.0.3497.100. Both requests load fine. If you can reproduce, there might be useful information in a netlog dump, captured with the instructions at https://www.chromium.org/for-testers/providing-network-details.
,
Oct 9
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 10
Unable to reproduce the issue on chrome reported version# 69.0.3497.100 and latest chrome# 71.0.3575.0 using Mac 10.13.6 with steps mentioned in comment# 3. As the issue is unable to reproduce from TE end, hence removing Needs-Bisect label and requesting someone from the Blink>Network team provide further inputs on this issue. Thanks!
,
Oct 11
Things I learnt looking from the netlog: 1. These are regular image loads, not using the beacon API. 2. ERR_SPDY_SERVER_REFUSED_STREAM is genuinely being returned by the remote server. Chrome retries each request 2 more times but it doesn't seem to help. 3. There are many requests for rum.gif in a short space of time. This might be what is making the server unhappy. At the moment this is looking most like a server problem. Sending to Internals>Network>HTTP2 in case there's something to do on the Chrome side.
,
Oct 25
As per comment #8, requesting Internals>Network>HTTP2 team to look into the issue and help in further triging. Hence adding 'TE-NeedsTriageHelp' label. Thanks.. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by phanindra.mandapaka@chromium.org
, Oct 4