Issue metadata
Sign in to add a comment
|
HTTP/1 access pattern on HTTP/2 connection when rewriting url in service worker
Reported by
erik.w...@baqend.com,
May 24 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 Steps to reproduce the problem: 1. Compare the Waterfalls A) Chrome: https://www.webpagetest.org/results.php?test=180524_76_cbbaad116df03c5c5d342aec6e58cbe0 B) Firefox: https://www.webpagetest.org/results.php?test=180524_77_fa0656745b097aa81d7cc50818030848 2. What you see is perfect HTTP/2 parallelism in Firefox but HTTP/1.1 access pattern for the javascript requests in Chrome. 3. If you look at the Chrome waterfall for the same website but with the HTML hosted on an HTTP/2 server, you see perfect HTTP/2 parallelism again: https://www.webpagetest.org/results.php?test=180524_QK_85bfca5e408bbf245a5ae4a310c13c9a The index.html and sw.js are attached. If you want to host yourself: 1. Hosts the index.html and sw.js on an HTTP/1.1 Server and look at the waterfall in Chrome 2. Do the same on Firefox and compare 3. Hosts the index.html and sw.js on an HTTP/2 Server and look at the waterfall in Chrome again Number 2 and 3 should show perfect HTTP/2 parallelism. Number 1 should show HTTP/1.1 access patterns for the scripts (only 6 requests in parallel). What is the expected behavior? Requests to an HTTP/2 domain should not show HTTP/1.1 access patterns even if the site that executes these requests is served via HTTP/1.1. What went wrong? How this minimal example works: [1] shows a waterfall of [0]. You can see, that the actual site is served via HTTP/1.1 and installs a service worker. Once the service worker is installed, a script inserts 50 img tags and 50 script tags into the body. The image and script requests are rewritten in the service worker to an HTTP/2 domain. The waterfall shows that all the images are loaded in parallel (as expected with HTTP/2). The scripts on the other hand (request 60 to 103) are loaded in blocks of 6 (just like HTTP/1.1 would do it). I can only reproduce this behavior with script tags. Image tags work correctly and scripts loaded via the fetch API as well. Only for script tags, the browser seems to issue the requests to the service worker as if it would suffer from HTTP/1.1 head-of-line blocking. [1] https://www.webpagetest.org/results.php?test=180524_76_cbbaad116df03c5c5d342aec6e58cbe0 [2] https://s3.eu-central-1.amazonaws.com/h2testpage/index.html Did this work before? No Does this work in other browsers? Yes Chrome version: 66.0.3359.139 Channel: n/a OS Version: Flash Version: For HTTP/1.1 sites that use a service worker to rewrite requests to an HTTP/2 domain, this is a real performance bottleneck.
,
May 25 2018
,
May 25 2018
Let's try with NetworkService on. The throttling may be done by the browser process.
,
May 25 2018
[+tbansal]: FYI (Not sure if this is scheduler related).
,
May 25 2018
This is likely not related to my changes: I can repro it on fast connections while my changes only affected the scheduler on slow connections. Also, the experiment to throttle H2 requests has not yet started. It looks like at most 6 requests are being allowed in-flight at any time. So, it seems related to scheduler. I will take a look later today.
,
May 25 2018
The original URL of the JavaScript files in index.html is s3.eu-central-1.amazonaws.com which is not h2 capable. However, the service worker intercepts that requests and redirects (not sure if that's technically the right term here) the request to testpage.app.baqend.com which is h2 capable. Since the original URL is for a non-H2 origin, resource scheduler applies 6/origin limit. Issue 285567 is relevant here. Assigning to falken@ to see if there are any other possible solutions here.
,
May 28 2018
This sounds like bug 835448 and will be fixed with NetworkService/S13nServiceWorker. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, May 24 2018