Git : error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

Question

Please don't mark this a duplicate without reading full question.

When I was trying to push my code to our repository, I got below error:

I tried to search this issue on web and I found amazing resources but not exact solution. There were many similar question but I didn't find clear discussion or proper solution.

I referred this question. I also looked into those answers and references which provides on respective answers.

I increased a buffer size as suggested on this answer but not worked for me.

I downgrade HTTP version from HTTP/2 to HTTP/1.1 as suggested on this answer and it worked for me.

I referred One comment where he mentioned that why we've to downgrade HTTP version from HTTP/2 to HTTP/1.1. I didn't understand his comment. Below one is his comment.

In reply to questions about downgrading to HTTP/1.1, the error message posted by OP points to an issue with HTTP/2; it is likely that something beyond OP's control (a proxy, the GIT server, etc.) does not work well with HTTP/2. Until that's fixed, downgrading to HTTP/1.1 is a valid workaround.

So my questions are

1. Why should we downgrade HTTP version from HTTP/2 to HTTP/1.1?
2. Why increasing the buffer size workaround is not working for everyone?

Answer 1

So my questions are

1. Why should we downgrade HTTP version from HTTP/2 to HTTP/1.1?

We shouldn't—but see below.

2. Why increasing the buffer size workaround is not working for everyone?

This should also be unnecessary.

There can be several different problems here, but if your network connection is fundamentally sound—not all are—then the usual source of HTTP or HTTPS protocol issues is some sort of middleware box, such as a filter that tries to prevent access to unapproved hosts, that is not filtering correctly. That is, you attempt to connect directly to, e.g., github.com, but instead of getting connected to github.com you get connected to some corporate server. The corporate server checks the web request, decides whether to allow or deny it, and upon deciding to allow it, makes its own connection to github.com and then starts relaying traffic.

The problem is that this middleware server, that does this relaying, corrupts the data.

The correct fix is to fix or remove the middleware server. Anything else is merely a workaround. If Bob, the phone relay operator, consistently tells you that Susan is out of the office even when she is in, you stop asking Bob about Susan. Instead, you ask Bob to connect you to her office-mate Suzie. Bob now connects you to Susan (who apparently also goes by the name Suzie) and you're able to get your work done. This does not mean that everyone has to call her Suzie, and in fact, if only Bob calls her Suzie, your friend, whose calls go through Fred instead of Bob, can't ask for Suzie: that won't work with Fred.

Because computer relays are more complicated than confused phone operators, you may have better success using ssh:// URLs than http:// or https:// URLs. But any workaround that works for you, that gets you past the data corruption problem, is fine for you. It might not work for anyone else, but this isn't the right fix anyway. The right fix is to remove or replace the broken filter/relay.