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 99ba7ee375c4dc664768724d1f9ed4475112c5eb..c2ec06e05e2155f1510b9ce564f560f0abe999e8 100644 (file)
--- 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