CORB is blocking embedded twitter images
Reported by
kevinma...@gmail.com,
Jul 25
|
||||
Issue descriptionChrome Version : 67.0.3396.99 (Official Build) (64-bit) URLs (if applicable) : https://www.svgshare.com/ isolated case: http://www.kevinmarks.com/chromebug.html Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: OK 11.1.2 (12605.3.8.1) Firefox: OK 61.0.1 (64-bit) Edge: What steps will reproduce the problem? (1) load the page, notice the missing user images (2) look in the inspector, see that images are blocked by CORB (3) curl -v the image URL and note that it has text/html on the 302 and an interstitial message the final url https://pbs.twimg.com/profile_images/826300294136868864/bB22s4pc.jpg has mime type image/jpeg and loads correctly in very other browser. What is the expected result? an image What happens instead? no image and a note in the console curl -v https://twitter.com/kevinmarks/profile_image?size=original * Trying 104.244.42.65... * TCP_NODELAY set * Connected to twitter.com (104.244.42.65) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: CAfile: /Users/kevinmarks/.certs/ca-bundle.crt CApath: /usr/local/etc/openssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=Delaware; serialNumber=4337446; street=Suite 900; street=1355 Market St; postalCode=94103; C=US; ST=California; L=San Francisco; O=Twitter, Inc.; OU=tsa_f Point of Presence; CN=twitter.com * start date: Jan 12 00:00:00 2017 GMT * expire date: Jan 17 12:00:00 2019 GMT * subjectAltName: host "twitter.com" matched cert's "twitter.com" * issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA * SSL certificate verify ok. > GET /kevinmarks/profile_image?size=original HTTP/1.1 > Host: twitter.com > User-Agent: curl/7.59.0 > Accept: */* > < HTTP/1.1 302 Found < cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0 < content-length: 134 < content-type: text/html;charset=utf-8 < date: Wed, 25 Jul 2018 02:39:24 GMT < expires: Tue, 31 Mar 1981 05:00:00 GMT < last-modified: Wed, 25 Jul 2018 02:39:24 GMT < location: https://pbs.twimg.com/profile_images/826300294136868864/bB22s4pc.jpg < pragma: no-cache < server: tsa_f < set-cookie: fm=0; Expires=Wed, 25 Jul 2018 02:39:15 GMT; Path=/; Domain=.twitter.com; Secure; HTTPOnly < set-cookie: _twitter_sess=BAh7CSIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCAIsTs9kAToMY3NyZl9p%250AZCIlMTQyYWEzYzgzNTFmZDFkYjJjYTIxYjdhZTRjNmJmOTI6B2lkIiVlOTVk%250AMGYzY2ZkY2JhMGQ0ODM3NDk3NzFjMzJlYWM1MA%253D%253D--104b72890d472f1aa1a7e2599c4d8ee7c9209d5e; Path=/; Domain=.twitter.com; Secure; HTTPOnly < set-cookie: personalization_id="v1_Jj+1KNkRmpyovwN5GB8PCw=="; Expires=Fri, 24 Jul 2020 02:39:24 GMT; Path=/; Domain=.twitter.com < set-cookie: guest_id=v1%3A153248636415797530; Expires=Fri, 24 Jul 2020 02:39:24 GMT; Path=/; Domain=.twitter.com < set-cookie: ct0=4c7a072e69f480e6032bba205811ce16; Expires=Wed, 25 Jul 2018 08:39:24 GMT; Path=/; Domain=.twitter.com; Secure < status: 302 Found < strict-transport-security: max-age=631138519 < x-connection-hash: 7d390b380260901877a3ad2af1eef15f < x-content-type-options: nosniff < x-frame-options: SAMEORIGIN < x-response-time: 127 < x-transaction: 00f9051f00bcdbff < x-twitter-response-tags: BouncerCompliant < x-ua-compatible: IE=edge,chrome=1 < x-xss-protection: 1; mode=block; report=https://twitter.com/i/xss_report < * Connection #0 to host twitter.com left intact <html><body>You are being <a href="https://pbs.twimg.com/profile_images/826300294136868864/bB22s4pc.jpg">redirected</a>.</body></html> What is the expected result? What happens instead? Please provide any additional information below. Attach a screenshot if possible.
,
Jul 25
kevinmarks@ - thank you very much for the report! Could you please check if the problem repros in Chrome 68 (e.g. in Chrome Beta)? Note that Chrome 68 is currently getting released to the stable channel (still ramping up to 100%, currently 68 is only shipped to 10% of Windows and Mac users on the stable channel). So far I was unable to repro the problem. All repro attempts below had Site Isolation turned on. - 68.0.3440.75 (Linux): No repro (http://www.kevinmarks.com/chromebug.html shows an image + no CORB messages are shown in the DevTools console) - 67.0.3396.87 (Mac): No repro (same as above) I also believe (based on reading the code - I haven't explicitly tested this) that CrossSiteDocumentResourceHandler::OnResponseStarted will only get called for the final response (and not for the intermediate redirect which would be handled by ResourceHandler::OnRequestRedirected). Based on this, I don't think CORB should block 302s. I think this is also be true for the NetworkService version of CORB (i.e. for URLLoader::OnResponseStarted VS URLLoader::FollowRedirect).
,
Jul 25
Yes, I'm seeing the same as lukasza@ so far, on 68.0.3440.75 and 70.0.3502.0 (Mac) and 67.0.3396.99 (ChromeOS and Windows). I do see the 302 redirect in the DevTools network panel, but the image works and I don't see a CORB warning. I'm curious why it might have triggered for you. Are you able to reproduce it on other versions of Chrome, like Chrome Canary? You can also manually update to Chrome 68 on the stable channel by visiting chrome://chrome.
,
Jul 26
I do see it in 68 too - I get a 403 on first load, and the CORB warning on reload. Is this because I'm in the UK and twitter is loading more slowly?
,
Jul 26
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
,
Jul 26
kevinmarks@ - thanks for testing on M68. Could you please also 1) help us verify if the problem is related to CORB by testing in Chrome launched with the cmdline flags that disable CORB: --disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating 2) help us verify if the problem is related to Site Isolation by testing in Chrome launched with the cmdline flag that disables Site Isolation trials: --disable-site-isolation-trials I can certainly see that a 403 response might be a text/html document that would be blocked by CORB. At the same time, even if CORB didn't inject an emtpy body into the response, the text/html still wouldn't render as an image. If the 403 response is the root cause of the problem, then I would expect the problem to repro with and without CORB (and I would really appreciate if you could help verify this by trying the cmdline flags given above). One other thing you might be able to do is to open the "Network" panel in DevTools while reproing the problem. This should help verify the contents of the response to https://twitter.com/kevinmarks/profile_image?size=original request - if it is a 302 or 403 or 200-with-an-image.
,
Jul 31
Adding 'Needs-Feedback' label as per comment #6. kevinmarks@ Request you to please check comment #6 and update the thread with the observations. Thanks.. |
||||
►
Sign in to add a comment |
||||
![https://pbs.twimg.com/profile_images/826300294136868864/bB22s4pc.jpg">redirected](https://pbs.twimg.com/profile_images/826300294136868864/bB22s4pc.jpg">redirected){kind=link}
Comment 1 by vamshi.kommuri@chromium.org
, Jul 25