Better error code when attempting to contact HTTP/1 server over HTTP/2

[DmitryKakurin]

When an attempt is made to access HTTP/1 server with gun using HTTP/2 protocol the server (correctly) returns HTTP/1.1 400 Bad Request. But when gun is unable to parse this response (expecting HTTP/2 reply), it converts it to {closed, The connection was lost."}. It would be very helpful to return a distinct error in this case to indicate protocols mismatch.

[essen]

Oh yeah good idea.

[DmitryKakurin]

Hi @essen, to clarify :-): do you plan to make the change, or do you prefer me to give it a try?

[essen]

You can try and experiment as I'm busy elsewhere at the moment.

Question is what should be done, should we switch back to gun_http when this happens? Or just parse and close the connection? Need to check the RFCs.

[DmitryKakurin]

I think closing connection is the only option, as the receiving HTTP1 server would not know where the original HTTP2 request ends and the next HTTP1 request starts.

[DmitryKakurin]

Now the error is: {connection_error, protocol_error, 'HTTP/1 response to HTTP/2 request'}

[essen]

Can you clarify on how Gun is used by the way? Do you set protocols => [gun_http2]? And is this over TLS? To be honest I don't think the solution is that simple depending on how you configure Gun and how the connection is performed.

From what I can guess you are doing the configuration I mentioned and connecting over TCP (so direct HTTP/2 over TCP, known as "prior knowledge") so the solution is appropriate BUT we would only want to do so in this particular case, so it's missing a check on the transport at the very least. I think we should only do this check for stream 1 as well.

[DmitryKakurin]

Yes, it's the "prior knowledge" scenario. I'll add the check, thanks.

[essen]

I have pushed 1bdc4fdb8f8634075944671ae00d14dadeba89df fixing the problem in master. A few comments:

• This will not always result in a gun_error message, because those are sent to pids that opened streams (on master at least, it might not be as clear cut on 1.x). Though you may get gun_error if you managed to open streams before the error occurs.
• If you do get gun_error, it contains {protocol_error, 'Invalid connection preface received. (RFC7540 3.5)'} in the error reason. This translates to {connection_error, {protocol_error, '...'}} when using gun:await.
• The gun_down message contains {connection_error, protocol_error, 'Invalid connection preface received. (RFC7540 3.5)'} in the down reason. Previously a normal reason would have been sent, which was wrong. Note that await functions coming with Gun do not receive gun_down at this time. You will however get an error once Gun has retried the configured amount of times and the Gun process exits. (I should add a test for this.)

I intend to apply the same changes to 1.3.x once you confirm that it works out for you.

[essen]

I've pushed the 1.3.x equivalent as well.

[essen]

We do a best effort detection of HTTP/1 responses now and give a different error message in both branches.

[essen]

Tagged 1.3.2 and should arrive to hex.pm soon-ish (the MachineGun author has the upload rights). Thanks!

[DmitryKakurin]

I can see it on hex.pm, thanks a lot for the quick fix!