tree 036040000ccacbfce17c9490732935affed99a5c
parent 2a0d3a18389f8ac04b6d4a3586555c0e14231dd6
author QUICHE team <quiche-dev@google.com> 1764091470 -0800
committer Copybara-Service <copybara-worker@google.com> 1764091527 -0800

Always reset content length status when removing the Content-Length header in BalsaHeaders.

Currently, when removing the "Content-Length" header, BalsaHeaders does not reset its internal content length status if "Transfer-Encoding: chunked" is also present. This can lead to inconsistencies where `content_length_valid()` remains true even after the "Content-Length" header is gone. This change introduces a new reloadable flag, `gfe2_reloadable_flag_reset_content_length_status_when_removing_content_length_header`, which, when true, ensures that the content length status is always reset when "Content-Length" is removed, regardless of the presence of "Transfer-Encoding: chunked". Tests are added to cover a scenario where both headers are initially present in a request.

I manually e2e tested, and confirmed that
* When gfe2_reloadable_flag_reset_content_length_status_when_removing_content_length_header is false, we saw `REQUIRED_BODY_BUT_NO_CONTENT_LENGTH` in the test backend http://screen/C7QyLfJxaEwCtsA.
* When the feature flag is true, the response code is 200, and the request headers sent by GFE has `transfer-encoding`: http://screen/9yDWwpGSFhnYVZi

I am now writing the nice automated e2e test that requires changes in the implementation. Given the tight timeline of the product launch, I don't think the automated test is blocking this change.

Protected by gfe2_reloadable_flag_reset_content_length_status_when_removing_content_length_header.

PiperOrigin-RevId: 836699619