Parse HTTP protocol bug with the response status code 100

[dxsup]

Describe the bug

The response status code 100 means "continue". The Mozilla docs describe it as follows:

The HTTP 100 Continue informational status response code indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished.

To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body.

In this case, the events may arrive in the following sequence.

read
POST /io/bigBody?sleep=1000 HTTP/1.1
User-Agent: curl/7.29.0
Host: 10.10.103.149:19999
Accept: /
Content-Length: 1049
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue

write
HTTP/1.1 100

read
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa....

write
HTTP/1.1 200 Content-Type: application/json Transfer-Encoding: chunked Date: Wed, 07 Dec 2022 13:12:16 GMT 36 {"success":true,"data":"sleep=1000, body size is 921"}

In this case, Kindling can't analyze events to get the correct protocol.

[hocktea214]

该问题由于网络模型导致，Kindling基于FD（文件描述符）对请求响应数据进行匹配，没对端口进行协议强映射

• 第一条请求与响应匹配，识别出HTTP
• 第二条请求与响应匹配，重新解析协议，而请求内容只有Body内容没有其他信息，无法识别为HTTP导致识别为NOSUPPORT
  

[hocktea214]

存在以下两种方案

1. 方案一
   ● 第一次请求解析后 发现响应是HTTP 100返回，将已解析的请求协议缓存
   ● 第二次请求解析时 从缓存中读取出协议为HTTP，强制用HTTP进行解析，并补全Request的协议属性
   

2. 方案二
   ● 第一次请求解析后 发现响应是 100状态码，将请求回写到缓存中并丢弃第一次响应
   ● 第二次请求解析时 以第一次请求 + 第二次请求 / 第二次响应 进行协议解析
   

缺点：

• 方案一：指标中多出1次请求，会引起用户认知上的误解
• 方案二：缺失continue响应包大小，但实际返回大小正常

[dxsup]

HTTP说明中提到，当HTTP客户端收到100状态码时，应该丢弃这个响应，并继续发送请求内容：

The client ought to continue sending the request and discard the 100 response.

从业务角度看，收到100响应码后客户端再继续发送Body，这属于同一次业务请求。因此方案一不满足需求，我们应该采用方案二。