3

I'm experiencing an issue with Google Chrome 85 that I didn't seem to have with earlier versions.

I'm triggering an ajax call that uploads a file to get it processed on the webserver. This call is a pretty basic multipart xhr POST request that uploads a file.

For some reason Google Chrome (and Firefox) refuse to accept the response from the webserver. The Chrome Devtools show "(failed)net::ERR_HTTP2_SERVER_REFUSED_STREAM" in the Status column for the XHR request. But I have no idea why the browser seems to refuse the stream...

I was able to debug the return & fetch HTTP headers with curl, but I have no idea what is wrong with the return HTTP headers or why Google Chrome (and other browsers) seem to refuse the result.

Any ideas / or suggestions how I can debug these HTTP headers for "validity"? Or some reason why they are refused?

Request headers (copy & pasted from the chrome devtools):

:authority: www.redactedwebsite.com
:method: POST
:path: /cms/multi-tab-taggable-attachment/fa0acf6/add
:scheme: https
accept: application/json
accept-encoding: gzip, deflate, br
accept-language: nl,en-US;q=0.9,en;q=0.8,zh;q=0.7,zh-TW;q=0.6,zh-CN;q=0.5,de;q=0.4,ja;q=0.3
cache-control: no-cache
content-length: 5431100
content-type: multipart/form-data; boundary=----WebKitFormBoundarytN9UfBZY5RJtGVt0
cookie: PHPSESSID=9a7d2c08b9506a02c18f864fb09262a4
origin: https://www.redactedwebsite.com
referer: https://www.redactedwebsite.com/cms/page/27/edit
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
x-requested-with: XMLHttpRequest

The return headers & body, that are shown in curl, are the following:

HTTP/2 200
date: Thu, 03 Sep 2020 19:21:37 GMT
server: Apache
x-powered-by: PHP/7.2.33
x-generation-time: 0,02101s
set-cookie: PHPSESSID=9a7d2c08b9506a02c18f864fb09262a4; path=/
vary: Accept-Encoding
content-encoding: gzip
content-length: 272
content-type: application/json
x-varnish: 565546302
age: 0
via: 1.1 varnish (Varnish/6.4)
accept-ranges: bytes

{"success":true, <and much more, redacted>}

I don't see anything wrong with the return or request headers and I'm clueless why the XHR call gets blocked by Chrome and gives: "(failed)net::ERR_HTTP2_SERVER_REFUSED_STREAM".

Any ideas? Or suggestions where I could debug or validate my request/return headers? Thanks so much!

Cheers., B.

brtdv
  • 157
  • 1
  • 2
  • 13

4 Answers4

3

For the people who comes from Google, there is an answer with more causes here.

In my case, I was using office VPN. It seems that the VPN was downgrading HTTP2 requests to HTTP/1.1, and consecuentally the server rejected them by ERR_HTTP2_SERVER_REFUSED_STREAM.

1

This may not be of much help in your particular case, but I wanted to weigh in on this nonetheless:

I had the exact same problem/error message with my form posting files yesterday . In my case, the error only showed up with file sizes over 10KB, uploads below 10KB did not pose issues .

The same form on a different web server showed no issues uploading the same, larger files. This led me to believe that this was, at least in my case, a server side configuration issue.

In my case, it got resolved by itself as of today.

0

Followup: I contacted the support team of my webhosting provider where this issue was happening, they investigated. As @Maarten Cuypers indicated, this seemed to be a server side, because they acknowledged the problem & 24h later it got fixed. I didn't change anything to my application layer.

Unfortunately I have no indication what they changed to the server configuration, so I can't post an answer... :-(

brtdv
  • 157
  • 1
  • 2
  • 13
0

I spent 4 days dealing with this same net::ERR_HTTP2_SERVER_REFUSED_STREAM on my wordpress site, only happened when loading my Oxygen Builder edit templates...

I did everything known to man... cmd netsh, reset network, router, everything... I did not have this error using another computer however... just my desktop which, i unintentionally used "manage my device" from Microsoft.

I just switched back to "Use local account"

And my problems went away..

I don't know if this is truly the cause or some weird coincidence, but I could not find any help otherwise... hopefully this was a real fix and you may find it useful.

Michael
  • 1
  • 1