[For help] Failed to process the incoming request: unsupported protocol version

[ShawnXiong]

2021/11/09 12:01:55 [ERROR] Failed to process the incoming request: unsupported protocol version: 69 => server.go:261
2021/11/09 12:01:55 [ERROR] Failed to process the incoming request: unsupported protocol version: 84 => server.go:261
2021/11/09 12:01:55 [ERROR] Failed to process the incoming request: unsupported protocol version: 49 => server.go:261
2021/11/09 12:01:55 [ERROR] Failed to process the incoming request: unsupported protocol version: 116 => server.go:261
2021/11/09 12:01:55 [ERROR] Failed to process the incoming request: unsupported protocol version: 101 => server.go:261
2021/11/09 12:01:55 [ERROR] Failed to process the incoming request: unsupported protocol version: 105 => server.go:261
2021/11/09 12:01:55 [ERROR] Failed to process the incoming request: unsupported protocol version: 115 => server.go:261

Hi,
Sometime it's happen in my standalone deployment env, could you give me an idea about the above error output, what's the reason that cause protocol read version incorrect?

[Burak Sezer]

Hi @ShawnHsiung

I have never seen that error before. Which version do you use? The current production version is v0.4.0. Maybe you use a different version on the client-side? Do you have any procedure to reproduce that error?

[ShawnXiong]

Hi @ShawnHsiung

I have never seen that error before. Which version do you use? The current production version is v0.4.0. Maybe you use a different version on the client-side? Do you have any procedure to reproduce that error?

Hi @buraksezer

thanks for your reply. the output log incorrect protocol version was caused by our service scanner to do some security things. But, I have an question about why not to close the conn actively when handle message failed, and may we output more detail log while client using unknown protocol version, it's useful to  position error.

for {
    // handleMessage waits to read a message from the TCP socket.
    // Then calls its handler to generate a response.
    err := s.handleMessage(conn, &connStatus, done)
    if err != nil {
	  // The socket probably would have been closed by the client.
	  if errors.Is(errors.Cause(err), io.EOF) || errors.Is(errors.Cause(err), protocol.ErrConnClosed) {
		  s.log.V(6).Printf("[DEBUG] End of the TCP connection: %v", err)
		  break
	  }
	  s.log.V(5).Printf("[ERROR] Failed to process the incoming request: %v", err)
    }
}

[Burak Sezer]

But, I have an question about why not to close the conn actively when handle message failed,

Olric implements connection pooling. Closing the socket due to a message processing error is not useful at all. Because the underlying TCP socket would be healthy.

and may we output more detail log while client using unknown protocol version, it's useful to position error.

It's possible to improve the logging. Could you please send a PR or snipped to clarify the idea?

[ShawnXiong]

But, I have an question about why not to close the conn actively when handle message failed,

Olric implements connection pooling. Closing the socket due to a message processing error is not useful at all. Because the underlying TCP socket would be healthy.

It's might be better to distinguish protocol error from errors while handleMessage, close the connection if the protocol.ReadMessage returns error, because it would be a bad client with high probability, and there is a problem that olric not read until the EOF from conn that keep sending data.

and may we output more detail log while client using unknown protocol version, it's useful to position error.

It's possible to improve the logging. Could you please send a PR or snipped to clarify the idea?

yes, I'd like to make a PR to improve the logging readability. let's talk about the first question, is it possible to close conn if protocol read error? if it's possible, I 'd like to include it in the PR.