http_server: always set the content-length on HTTP/1.x (fix #9010) #9036
Conversation
) When a client uses HTTP/1.1 protocol version, we are only setting the content-length at special cases, however if the caller like in_splunk, in_http or other sets a response body, the header is not set, so the client "have to assume" the response of the request is either none or just hangs and wait for some bytes. This patch forces to format a content-length header when the request comes from a HTTP/1.1 session This fix issue #9010. Signed-off-by: Eduardo Silva <[email protected]>
edsiper
requested review from
leonardo-albertovich,
fujimotos and
koleini
as code owners
|
This works as intended. Are we discarding #9019 in favor of this one? |
|
@lecaros right now #9019 just disables keepalives if the user-agent is curl, its a workaround to receive the data buffer on the client but the root cause is different, so this PR fixes the missing content-length header which was the primary problem reported on #9010. I am troubleshooting a pending issue where Keepalive is not working if the following conditions are met:
only the first request succeed and the others cannot arrive since the server drops the connection. It works fine if work in process. |
|
CI failed because of CentOS 7 and Appveyor trying to upload an artifact |
When a client uses HTTP/1.1 protocol version, we are only setting the content-length at special cases, however if the caller like in_splunk, in_http or other sets a response body, the header is not set, so the client "have to assume" the response of the request is either none or just hangs and wait for some bytes.
This patch forces to format a content-length header when the request comes from a HTTP/1.1 session
This fixes the issue #9010.
Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.