You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Requests are nonstandard
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?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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:
Requests are nonstandard
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?
Beta Was this translation helpful? Give feedback.
All reactions