The vulnerability stems from improper header processing in HTTPChannel.headerReceived. The pre-patch code directly processed Content-Length and Transfer-Encoding headers without validating duplicates or handling conflicts properly:
- When multiple Content-Length headers were present, it overwrote previous values instead of rejecting
- When both Transfer-Encoding and Content-Length existed, it prioritized Content-Length against RFC specs
- Allowed non-chunked/identity transfer encodings
The patch introduced _maybeChooseTransferDecoder to centralize validation, indicating the vulnerability resided in the original headerReceived implementation. The test cases added in the commit specifically target the flawed logic that existed in headerReceived before the refactor.