Go get fails to install lib

[darsenault]

I am using benthos (benthos.dev) which has bluemonday as a dep. Both the benthos build and direct installation of bluemonday fail with the following error:

% go get -u github.com/microcosm-cc/bluemonday go: downloading github.com/microcosm-cc/bluemonday v1.0.4 go get: github.com/microcosm-cc/bluemonday@v1.0.4: stream error: stream ID 3; NO_ERROR

Google has no good answers. There is some traffic about line breaks in RPC responses but nothing directly addressing this problem. I am on go 1.15.2 on a current macOS. Other go project install and build without issues. The other deps for benthos install without complaint. Thank you.

[buro9]

Hmm... this is interesting. Stream here, in that syntax, looks like a HTTP/2 error... that the stream is terminated prematurely?

I have just tested on Catalina and with go1.15.2 and the local go get worked fine.

Unfortunately a pcap of what is happening at your end isn't going to help... we'd see the establishment of a TLS HTTP session, but the break happens in stream 3 - by which point the communication is encrypted and the pcap will be largely noise. I'm not convinced the TCP connection is the problem, more that the server or client is potentially prematurely breaking the connection - but this is not within my control as Microsoft / Github own the HTTP server within Github.

I don't know how to address this, but a workaround may be to git clone this repo in your $GOPATH so that the build for benthos picks it up.

[darsenault]

I regressed to go 1.14.9, same error. I tried go get -insecure, same error. Tethered to my phone hotspot to try another network, same error. The problem only seems to impact this library. Everything else I try to install (even a random lib from Awesome Go) works just fine. Very deeply puzzled. Off to do the clone route.

[buro9]

And there's definitely no AV other strange intercept thing going on?

I'm wondering... the tests for this component, they could easily trigger an overly aggressive AntiVirus / anti-Malware program... if you have such a thing running, that could possibly explain why the commonality is this lib and your laptop but not the Go version or network. i.e. that it detects the test files contain patterns that it might consider XSS (the irony) and then it terminates the HTTP connection.

[darsenault]

Problem solved.

export GOPROXY="direct"

Prior value: GOPROXY="https://proxy.golang.org,direct"

go get github.com/microcosm-cc/bluemonday go: downloading github.com/microcosm-cc/bluemonday v1.0.4

Success!

Why this is the case for this particular library I have no idea, but it appears to be a proxy.golang.org issue.

Thanks for the assistance.

[buro9]

Oh. Thank you for letting us know what the resolution was.

I'll go raise an issue with the Go team.