skip to Main Content

I do have at least two wordpress sites which very inconsistently throw a varying number of net::ERR_HTTP2_SERVER_REFUSED_STREAM errors. When these errors occur the number of errors thrown highly varies from page-load to page-load (or reload) from say 4 requests with that error to about 60 and sometimes even more (if the page has some many requests). The actually affected ressources/requests seem completly random and therefore don’t leave any clue where this is coming from.

If these errors occur their occurrence mostly persists (when doing a simple page refresh or hard refresh) until the browser is restarted. Seldomly they even stay after a restart as well.

When this hiccup does happen and the browser/system gets in this faulty state, these errors also happen in the wordpress backend loading basic files like .../wp-includes/js/wp-lists.min.js?ver=5.7 and similar.

At least two users have experienced this behaviour in Chrome, Opera and Edge while being logged-in to and -out of wordpress. In Opera and Edge we do not have any browser extensions installed. As far as we know other users never had this issue even though some of them visited the site many times.

What might be the reasons for this and/or what might be a way to solve it?


List of Plugins installed on both sites:


3

Answers


  1. This is not related to WordPress. It’s related to either Apache or Nginx using the HTTP/2 standard.

    REFUSED_STREAM (0x7): The endpoint refused the stream prior to
    performing any application processing (see Section 8.1.4 for
    details).

    It can either come from too many concurrent streams:

    Endpoints 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 (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. The choice of error code determines whether the endpoint wishes to enable automatic retry (see Section 8.1.4) for details).

    It can also be sent during a Push Response operation:

    If the client determines, for any reason, that it does not wish to receive the pushed response from the server or if the server takes too long to begin sending the promised response, the client can send a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code and referencing the pushed stream’s identifier.

    Or if the client is trying to connect using HTTP/1.1:

    Servers that donโ€™t wish to process the HTTP/1.1 response should reject stream 1 with a REFUSED_STREAM error code immediately after sending the connection preface to encourage the client to retry the request over the upgraded HTTP/2 connection.

    There is no way for me to pinpoint what is happening during those requests, as it can have multiple reasons, as stated above.

    So I suggest you a couple of options:

    • Pass your site’s traffic throughugh Cloudflare, so they act as a middle-man for these connections and normalize the requests sent to your server
    • You can increase the SETTINGS_MAX_CONCURRENT_STREAMS to minimize the risk of sending a REFUSED_STREAM. If you use Nginx, you can see how to do this here: http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_concurrent_streams
    • If you don’t know how to do the above, contact your hosting company and ask them to do it for you and upgrade your Nginx version, as some older versions are known to have issues.
    • Disable HTTP/2 in Nginx. How to disable http2 in nginx
    • As a last resource, you can migrate to another hosting company.

    If you use Apache, everything I said above applies to it as well.

    Login or Signup to reply.
  2. I do have at least two wordpress sites which very inconsistently throw a varying number of net::ERR_HTTP2_SERVER_REFUSED_STREAM errors. When these errors occur the number of errors thrown highly differs from say 4 requests to about 60 and sometimes even more (if the page has enough requests),

    As you said,the count of stream error is more than requests. A possibie explains is stream is push streams which has even stream id. Push stream is initiated by server side. In cotrast, stream initated by client side has odd id.

    Why error counts so much?

    We follow key error word to try to find some roadmap.
    search key word ERR_HTTP2_SERVER_REFUSED_STREAM in chromium github repo

    We get the following sutuation to reply ERROR_CODE_REFUSED_STREAM.

    • Browser handles server side stream RST frame (SpdySession::OnGoAway).RST frame means closing stream but not closing session.
      we may recevive error ERR_HTTP2_SERVER_REFUSED_STREAM

    • Browser handles server side stream Goway frame (SpdySession::OnGoAway). Goway frame means closing session. Server side request goway frame without any error(spdy::ERROR_CODE_NO_ERROR).
      we may recevive error ERR_HTTP2_SERVER_REFUSED_STREAM

    The error counts is far more than the requests. So we may be led to stage concultion.
    Server side sent RST frame with high probability.

    Now we keep digging in.

    search key word ERROR_CODE_REFUSED_STREAM in chromium github repo

    Server may sent ERROR_CODE_REFUSED_STREAM with the following suituation:

    • When session property enable_push_ is off, but try to create push stream.
    • session state goes to STATE_GOING_AWAY, but receive push stream
    • Wrong Push stream without ":url" header
    • Only http scheme allowed for cross origin push by trusted proxy. If not, get refused.
    • Pushed URL must have https scheme
    • Certificate does not match pushed URL.
    • Duplicate pushed stream with the same url.
    • ERR_TIMED_OUT or ERR_HTTP2_CLIENT_REFUSED_STREAM

    Useful utility

    use debug tools to get more info.

    chrome://net-internals/http2#events
    

    or

    chrome://net-export/
    

    About server push news

    Chrome to remove server push

    Login or Signup to reply.
  3. I got the same error 2023 in Chrome connection to k8s nginx container, that had 100’s of small .js files to load.
    "net::ERR_HTTP2_SERVER_REFUSED_STREAM"
    No problem with Firefox, only Chrome.

    After trying all kinds of nginx settings it was resolved for me by upgrading my ingress-nginx helm chart from 4.2.0 to latest 4.6.0 ๐Ÿ™‚
    https://github.com/kubernetes/ingress-nginx/releases

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search