chrome.webRequest APIs do not reliably handle QUIC requests
Reported by
ma...@yesware.com,
Nov 15
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Steps to reproduce the problem: 1. Create or use an extension with webRequest, webRequestBlocking, and *://*.googleusercontent.com/* permissions. 2. Add a chrome.webRequest.onBeforeRequest handler which logs to console. Provide a filter for urls matching *://*.googleusercontent.com/* and 'blocking' opt_extraInfoSpec. 3. Open gmail.com. 4. Open the extension background page and inspect the console. What is the expected behavior? The onBeforeRequest handler is invoked and the background console logs the details for each request to *://*.googleusercontent.com/* What went wrong? The onBeforeRequest handler is not invoked. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 70.0.3538.102 Channel: stable OS Version: OS X 10.14.0 Flash Version: Example extension implementation: https://github.com/mattduggan/webRequest-onBeforeRequest-example Based on the attached HAR file, it's been observed that the requests not handled by the webRequest APIs are made using the QUIC protocol. Disabling the enable-quic flag resolves the issue for most. Using a different Chrome browser (Chrome Dev) resolves the issue for others.
,
Nov 15
,
Nov 16
,
Nov 16
Unable to reproduce the issue on mac 10.13.6 using chrome reported version #70.0.3538.102 and latest canary #72.0.3611.0. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Opened the extension provided at comment #0. 3. Opened gmail.com. 4. Open the extension background page and inspected the console. 5. Observed that the console did not show anything and remained blank. mattd@ - Could you please check the attached screen cast and please let us know if anything missed from our end in reproducing the issue. This will be helpful in triaging the issue further. Thanks...!!
,
Nov 16
@krajshree@chromium.org My apologies, the example extension callback does not log to console, it cancels the request for the pixel which is inserted into your Gmail via the gmail.js script. These requests do not appear to have been cancelled based on my activity report for that pixel. Attached is the report. (Note that the pixel was generated for an email sent to my personal email; since the pixel was proxied via google image proxy and the request succeeded, our system associated the proxied request as the intended recipient.) Could you verify with that the network requests are being cancelled and that the handler is being invoked?
,
Nov 16
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
,
Nov 16
,
Nov 16
woxxom@gmail.com For users I observed to be affected, disabling QUIC not only resolved the issue, but they remained in a fixed state regardless of QUIC and NetworkService setting. This has made the issue difficult to reproduce.
,
Dec 14
WebRequest should be hooking in well above where we handle QUIC, so it's surprising that it can even distinguish them at all. Adding QUIC label. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by woxxom@gmail.com
, Nov 15