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 3d2cb8d1c07c7325c920c8ccab683f37a5f82f34..31472069dbd0cee0eb12a0ea03381e1602eecfef 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