CDN Fetch Requests Fail
Reported by
j...@cyph.com,
Sep 5 2016
|
||||||||||||||||||
Issue descriptionChrome Version : 55.0.2849.0 (Official Build) canary (64-bit) URLs (if applicable) : cyph.ws, na.cdn.cyph.com Other browsers tested: Chrome 52.0.2743.116 (Official Build) (64-bit) Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: OK Firefox: OK IE: OK What steps will reproduce the problem? (1) Navigate to cyph.ws with console/inspector toolkit open OR (1) Run the following code in the console: fetch('https://na.cdn.cyph.com/cyph/pkg').then(o => o.text()).then(s => console.log(s)).catch(err => console.log(err)) What is the expected result? Cyph application loads without error What happens instead? Application fails to load, and the following error is in the console: "Uncaught (in promise) TypeError: Failed to fetch" Please provide any additional information below. Attach a screenshot if possible. For whatever reason, all network requests to na.cdn.cyph.com fail with the status "(canceled)" For comparison, fetch('https://api.cyph.com/continent').then(o => o.text()).then(s => console.log(s)).catch(err => console.log(err)), works. Possibly relevant details: * server is running Node.js * server is using HTTP/2 implementation from https://www.npmjs.com/package/spdy * server is configured with HSTS and HPKP * responses are gzip-compressed using zopfli, with `Content-Encoding: gzip` explicitly set * explicitly passing `{headers: new Headers({'Accept-Encoding': 'gzip'})}` to fetch makes no difference * issue is reproducible whether we test with `fetch` or `XMLHttpRequest` * requests are cross-domain * CORS header in use is `Access-Control-Allow-Origin: *` * passing `mode: 'cors'` or `mode: 'no-cors'` makes no difference * if helpful for further investigation, source code of server (118 LoC) is here: https://github.com/cyph/cyph/blob/master/serverconfig/cdn.sh#L42
,
Sep 6 2016
It's working for me on M53 beta, but I'm getting ERR_CONNECTION_RESET on Canary (rather than the ERR_FAILED you're getting). We're negotiating an SSL connection, send a request, and then the server resets the connection. Could you provide a log, instructions here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details. SSL/HTTP2 folks: Any big change in SSL negotiation, or HTTP features between M53 and M55 that might make a server sad?
,
Sep 6 2016
We added RSA-PSS, but this does not appear to be one of the servers that fails against it. Might be worth doing a bisect.
,
Sep 6 2016
A bisect sounds like a great idea to me.
,
Sep 6 2016
https://chromium.googlesource.com/chromium/src/+log/4c361942b436b45ddcaab02d6829921b8f3c9e81..bf03b6136f729384110523754d4ee57ed8ba9356 I'm guessing it's https://chromium.googlesource.com/chromium/src/+/b3cafaaea4c3c0c1cf553d8ec9999f83a8c1c7f4. Assigning to bnc@ to look at.
,
Sep 6 2016
Requested log is attached. Let me know if you need anything else.
,
Sep 6 2016
What software are you all using for HTTP/2? If the bisect is correct, it does not like the larger SETTINGS_HEADER_TABLE_SIZE advertisement? I'm not familiar with HTTP/2 and will defer to bnc@ as to whether it is legal for a server to reject such a thing. (I would think there'd be some negotiation mechanism to pick a smaller value without breaking the connection?)
,
Sep 6 2016
,
Sep 6 2016
Mentioned in the original submission. HTTP/2 is being handled by: https://www.npmjs.com/package/spdy
,
Sep 6 2016
Ah, my bad, I missed that. Thanks! Looks like this is coming from here: https://github.com/indutny/hpack.js/blob/7338b7ec5c2fc3c234bbf56d1e570925c15d32a1/lib/hpack/table.js#L82 Which gets set by way of here: https://github.com/indutny/spdy-transport/blob/aa2d889f7b49d6f6b52ed6979fcb236f6662eb39/lib/spdy-transport/protocol/http2/hpack-pool.js#L19 And defined here: https://github.com/indutny/spdy-transport/blob/aa2d889f7b49d6f6b52ed6979fcb236f6662eb39/lib/spdy-transport/protocol/http2/constants.js#L18 bnc: Is this correct behavior for an h2 implementation, or is it supposed to do something else in response to a larger value from the client?
,
Sep 6 2016
Receipt of SETTINGS_HEADER_TABLE_SIZE should not cause a server to throw a protocol error. If the client sets this value to X, the server is free to use any value <= X. http://httpwg.org/specs/rfc7540.html#SettingValues "SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the remote endpoint of the maximum size of the header compression table used to decode header blocks, in octets. The encoder can select any size equal to or less than this value by using signaling specific to the header compression format inside a header block (see [COMPRESSION]). The initial value is 4,096 octets." Assuming davidben@'s links point to the right code, this definitely looks like a server bug: https://github.com/indutny/hpack.js/blob/7338b7ec5c2fc3c234bbf56d1e570925c15d32a1/lib/hpack/table.js#L82 https://github.com/indutny/spdy-transport/blob/8bb0b80dbef87da21a40a88f642259528638daff/lib/spdy-transport/connection.js#L514
,
Sep 16 2016
,
Sep 16 2016
Re #7 and #11: indeed the issue seems to be the server choking on valid HTTP/2 SETTINGS. Since Chrome is behaving in compliance with the specs, closing this as WontFix.
,
Sep 16 2016
bnc: Since you understand the protocol (I don't) and we know which project is choking, could you file a ticket with them to explain the issue? Also, do we have appropriate UMA metrics to check before and after the change to make sure this bug isn't too widespread? E.g. on the TLS side, we try to avoid making changes without a probe of top million sites just because of how widespread latent implementation bugs tend to be.
,
Sep 19 2016
Bug has been fixed in Node.js HTTP/2 server, see https://github.com/indutny/spdy-transport/issues/29. I was able to reproduce bug locally with a server checkout before the fix, and I confirmed that the issue is resolved by updating the server.
,
Sep 25 2016
Nice, thanks! |
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Sep 5 2016