Chrome 55 - ERR_SPDY_COMPRESSION_ERROR
Reported by
durgasri...@gmail.com,
Dec 12 2016
|
|||
Issue description
Chrome Version : <Copy from: 'about:version'>
OS Version: OS X 10.12
URLs (if applicable) : 55.0.2883.87 (Official Build) (64-bit)
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 10.0.1 (12602.2.14.0.7): Works
Firefox 50.0.2:Works
IE 7/8/9:Not Tried
What steps will reproduce the problem?
Deploy Web Application using Tomcat Server8.5.9 by enabling http 2 with Dojo.
Web page dojo files access fails with ERR_SPDY_COMPRESSION_ERROR.
What is the expected result?
Page should load without any issues.
Details:
Recent chrome [Mac - Sierra : Version 55.0.2883.87 (64-bit) ] we are seeing issues in http2 sites.
Initially we have seen problem with http2 table header size limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where tomcat has increased the header limit from 16K to 64K.
Now with latest tomcat 8.5.9 we are seeing ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
Tried couple of steps (flush SPDY sokets etc) based on google search on this issue but nothing worked..
Initial content is downloaded (other JS files etc) but on some dojo libraries alone, we are this issue which make application home page load fails.
Firefox works!
We are having latest tomcat 8.5.9 already. Not sure where else problem now. We have not enabled any compression server side.
,
Dec 12 2016
Is there any change you could set up a publicly facing server that I could test a custom Chromium build against? I have a suspicion about the root of the problem, and am having great difficulties configuring Apache Tomcat locally to serve HTTP/2.
,
Dec 13 2016
No we don't have any setup to access over WAN. Yes, tomcat requires native APR connector libraries for http2. Otherwise is there any way i can get patch build with the probable fix? Thanks, Durga Srinivasu
,
Dec 13 2016
It's not a fix. My guess is that the bug is in Tomcat, in that it does not send an HPACK dynamic table size update (so the dynamic table should be the default 4 kB) but uses a 64 kB dynamic table. As soon as it references entries that are in fact already emitted, that's a compression error. See https://www.ietf.org/mail-archive/web/httpbisa/current/msg27867.html for a discussion on how to interpret the specs. I would love to verify this, and if this is the case, then file a bug against Tomcat.
,
Dec 14 2016
Initially we got into this header size problem in chrome 55 and we used to get connection closed error. When we debug from tomcat end it is closing connection because of earlier limit 4KB and in latest tomcat the size been increased to 64KB. https://bz.apache.org/bugzilla/show_bug.cgi?id=60173 (Tomcat 64K limit fix) When we took latest tomcat now, we are getting into these compression errors. I am posting same issue in tomcat forum now. Thanks, Durga Srinivasu
,
Dec 14 2016
Even though Chromium advertises SETTINGS_HEADER_TABLE_SIZE = 64 kB, a server can only use 64 kB if it first emits a HPACK dynamic table size update to 64 kB first, otherwise the header size is still 4 kB. [1] If by any chance Tomcat does not do this, Chromium signals a compression error as soon as an evicted entry is addressed (which was evicted because it does not fit in 4 kB, but would not be evicted if the dynamic table was 64 kB). [1] http://httpwg.org/specs/rfc7540.html#SettingValues
,
Dec 21 2016
For reference, here is the posting mentioned in comment #5: http://tomcat.10.x6.nabble.com/Chrome-55-ERR-SPDY-COMPRESSION-ERROR-td5058369.html. So far no response.
,
Dec 25 2016
This is now fixed from tomcat end. We can close chrome defect. https://www.mail-archive.com/users@tomcat.apache.org/msg124633.html Thanks for the support!! Thanks, Durga Srinivasu
,
Dec 25 2016
Thank you for the update. Linked thread states bug in Tomcat is "fixed for 9.0.0.M16 onwards and 8.5.10 onwards". I'm therefore closing this issue. |
|||
►
Sign in to add a comment |
|||
Comment 1 by b...@chromium.org
, Dec 12 2016Owner: b...@chromium.org
Status: Assigned (was: Unconfirmed)