about http rfc content-length

[dino-ma]

I have a technical question that I would like to discuss. Let me describe the background.

Upstream A service, calling downstream B service (Starlight, GDP) through HTTP GET. The Content-Length is specified manually in the message and does not match the actual message. After my testing, (Starlight, GDP) in this scenario can only rely on the server to time out and not return any messages to the client.

In fact: as long as the Content-Length does not match the length of the message (greater than)

The root cause is that the upstream A service does not follow the HTTP RFC protocol, but in this scenario, at the RPC framework level, I don't think much about how I can go to the bottom.

I think it's OK for the RPC framework to be interpreted according to RFC. Let's wait because there are two situations:

1. Requests are nonstandard

2. Requests are canonical, some packets are delayed a long time due to network reasons

But such requests, if at some point they have accumulated into all applications. (Although I think it's cheating, malicious traffic) But can we get around to it?