Stream error: stream ID 1; HTTP_1_1_REQUIRED; received from peer

Grafana k6 OSS Support
1

Hi,
We get an error (stream error: stream ID 1; HTTP_1_1_REQUIRED; received from peer) when trying to do a simple GET-request to one of our end-points (REST), no params or such are needed (i.e. very simple request). Executing the request with k6 (with --http-debug=full option) gives below result:

INFO[0001] Request:
GET /api.looney.sales/v1/health/check HTTP/1.1
Host: rsia.a65.looney.org
User-Agent: k6/0.34.1 (https://k6.io/)
Accept-Encoding: gzip

WARN[0001] Request Failed error=“Get "https://rsia.a65.looney.org/api.looney.sales/v1/health/check\”: stream error: stream ID 1; HTTP_1_1_REQUIRED; received from peer"

We do the request the following way:

let res;
res = http.get(“https://rsia.a65.looney.org/api.looney.sales/v1/health/check”);

This request works perfectly fine in PowerShell by running the following command:
PS C:\Users\usr4323> Invoke-WebRequest https://rsia.a65.looney.org/api.looney.sales/v1/health/check

StatusCode : 200
StatusDescription : OK
Content : {“status”:“Degraded”,“totalDuration”:“00:00:00.2567423”,“entries”:{“Lumera”:{“data”:{},“duration”:"
00:00:00.2542867",“status”:“Degraded”},“virtualmemory”:{“data”:{},“duration”:“00:00:00.0933292”,"st
at…
RawContent : HTTP/1.1 200 OK
Pragma: no-cache
Transfer-Encoding: chunked
X-XSS-Protection: 1; mode=block
X-Frame-Options: Deny
X-Download-Options: noopen
X-Content-Type-Options: nosniff
Cache-Control: no-st…
Forms : {}
Headers : {[Pragma, no-cache], [Transfer-Encoding, chunked], [X-XSS-Protection, 1; mode=block], [X-Frame-Opti
ons, Deny]…}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 945

Obviously by looking at the debug from the request we are using HTTP/1.1 but still k6 gets the error regarding HTTP version (HTTP_1_1_REQUIRED). Why is this happening in k6 when through PowerShell it works fine?

Thank you very much for any help regarding this.

Best regards
Fredrik

2

Hi @Lightlore try http:// instead of https://

read this

3

Hi,
Thank you very much for your swift response and your suggestion.

Unfortunately the service we are sending the request to requires https, if using http we get automatically redirected to https because of security reasons. My company is using a proxy, I tried bypassing it and after that the request works in k6. However the issue is that k6 fails to complete the request with proxy, but PowerShell manages to complete it with proxy. Why can’t k6 handle requests through a proxy in this case?

Best regards
Fredrik

4

Hi @Lightlore ,

You are likely hitting --http-debug incorrectly reports http protocol · Issue #986 · grafana/k6 · GitHub as well.

k6 now has the ability to force HTTP/1.1 for the whole process through setting the env variable GODEBUG to http2client=0. On Linux you can do GODEBUG=http2client=0 k6 run testscript.js . Given the fact that this appear to be due to a PROXY usage I would expect you will need it disabled for all requests either way.

Hope this helps

2 Likes
5

Hi,
Thank you very much for that information. Creating a system variable in Windows (in my case) called GODEBUG with value http2client=0 did the trick and now the requests work in k6 as well.
Have a great day and once again thank you very much for a quick reply.
Best regards
Fredrik

6

http2client=0 works great for me locally, but I’m back to the same error using K6 Cloud - I’ve trying adding as an environment variable through the cloud UI, but that doesn’t make a difference, any idea how to get past this for Cloud?

7

Hi @ricodp,

Unfortunately this is a workaround that does it for the whole process and does it through setting an env variable that does control a lot about the process, as k6 is written in go.

Given the above, we are not about to let users set this in the cloud, freely. And the env variables that are settable in the cloud are only for usage through __ENV.

The new HTTP API, currently in design, will address this without this or another env variable being needed.

Until then, you can contact cloud support for potential workarounds.

Sorry for the inconvenience, and hopefully this helps you at least understand the cause of this not working in the cloud.