Cloudfront - Chrome SPDY error

[AnaBelgun]

This bug ticket is ported from TerriaCube where it was first discovered.

Error message: ERR_SPDY_SERVER_REFUSED_STREAM

to test:

• go to terria cube app https://terria-cube.terria.io/

• go to DEA Production, Near real time, Sentinel 2A - https://terria-cube.terria.io/#share=s-2fAVZ6zGV3KUus4DPSyPonNERPK

• error message
  

• and in console:
  

• terriaCube has Cloudfront

• same data services (https://nationalmap.gov.au/#share=s-7J1ezmmIYhns1wF1tWdlfrzN7Hr), from same stack (https://ows.services.dea.ga.gov.au), do not present this error in NationalMap, where Cloudfront is not applied (to double check because at the time of filing this bug, this is what the console had:
  

[AnaBelgun]

PR for handling the error (which doesn't solve the underlying problem): #3706

[AnaBelgun]

response from Cloudfront:
The client browser is observing error "ERR_HTTP2_SERVER_REFUSED_STREAM" for the application hosted in CloudFront "https://terria-cube.terria.io/#share=s-zVC2mGEZCdM4icB2lA86tV8YZVg".
Upon investigation and as per RFC,A peer can limit the number of concurrently active streams using the SETTINGS_MAX_CONCURRENT_STREAMS parameter within a SETTINGS frame. Here server specified the maximum number of concurrent streams the client can initiate. Client MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes its advertised concurrent stream limit to be exceeded MUST treat this as a stream error of type PROTOCOL_ERROR or REFUSED_STREAM.
https://tools.ietf.org/html/rfc7540#page-22
Here, I believe by initiating multiple request from Chrome will initiates multiple HTTP streams which exceeds the allowed limit.
However to confirm this behaviour and to check if CloudFront Edge server has set any Hard limit for "maximum allowed HTTP2 stream" per TCP connection, this has been escalated to another CloudFront team.

[AnaBelgun]

Comment from Terria:
We investigated that the server isn't setting a SETTINGS_MAX_CONCURRENT_STREAMS so it's staying at the default (infinite). If it were setting such a limit and that was the cause of the problem, it would imply that both Chrome and Firefox have a bug causing them to not honor that limit. Not very likely.

[rowanwins]

We've made a number of changes to try and get around this...

• Pass a custom update interval to leaflet tile layers #3740 provided an option to set an updateInterval property for ImageryLayerCatalogItems which helps when rapidly changing dates on a WMS, basically it's a debounce style redrawing now.

• Handling for SPDY errors between chrome & cloudfront #3706 rejigged the handling of tileError counts to include the time param which makes the service a little less sensitive.

[AnaBelgun]

reopening this issue