From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Mon, 8 Feb 2021 22:49:42 +0000 (+0000)
Subject: Allow 1xx and 204 responses with Transfer-Encoding headers (#769)
X-Git-Tag: 4.15-20210522-snapshot~35
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c64d8e60a3f04951509929c03ab57d99b2c068e7;p=thirdparty%2Fsquid.git

Allow 1xx and 204 responses with Transfer-Encoding headers (#769)

HTTP servers MUST NOT send those header fields in those responses, but
some do, possibly because they compute the same basic headers for all
responses, regardless of the status code. Item 1 in RFC 7230 Section
3.3.3 is very clear about message framing in these cases. We have been
ignoring Content-Length under the same conditions since at least 2018.
We should be consistent and apply the same logic to Transfer-Encoding.

I also polished the Transfer-Encoding handling comment for clarity sake.
---

diff --git a/src/HttpHeader.cc b/src/HttpHeader.cc
index 3d2cb8d1c0..31472069db 100644
--- a/src/HttpHeader.cc
+++ b/src/HttpHeader.cc
@@ -539,11 +539,10 @@ HttpHeader::parse(const char *header_start, size_t hdrLen, Http::ContentLengthIn
         if (delById(Http::HdrType::CONTENT_LENGTH))
             debugs(55, 3, "Content-Length is " << clen.prohibitedAndIgnored());
 
-        // RFC 7230 section 3.3.1 has the same criteria forbid Transfer-Encoding
-        if (delById(Http::HdrType::TRANSFER_ENCODING)) {
+        // The same RFC 7230 3.3.3#1-based logic applies to Transfer-Encoding
+        // banned by RFC 7230 section 3.3.1.
+        if (delById(Http::HdrType::TRANSFER_ENCODING))
             debugs(55, 3, "Transfer-Encoding is " << clen.prohibitedAndIgnored());
-            teUnsupported_ = true;
-        }
 
     } else if (getByIdIfPresent(Http::HdrType::TRANSFER_ENCODING, &rawTe)) {
         // RFC 2616 section 4.4: ignore Content-Length with Transfer-Encoding