duplicate header "Content-Length" in HTTP responses

[mek-omkar]

If duplicate header "Content-Length" in HTTP responses, getting error,

error { Error: Parse Error
    at Error (native)
    at TLSSocket.socketOnData (_http_client.js:359:20)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:172:18)
    at TLSSocket.Readable.push (_stream_readable.js:130:10)
    at TLSWrap.onread (net.js:535:20) bytesParsed: 133, code: 'HPE_UNEXPECTED_CONTENT_LENGTH' }

using wget i am getting the following headers

HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Content-Length: 84
  Pragma: no-cache
  Cache-Control: no-cache
  Content-Type: text/html; charset=UTF-8
  Content-Length: 84
Length: 84 [text/html]

[bnoordhuis]

It's a violation of the spec. Node could ignore the second Content-Length header iff it's identical to the first one but that's arguably pandering to broken server software.

[mek-omkar]

using node http/https client i am getting the error, we should be able to get response from buggy servers in some purpose right? if ignoring why we are getting error?

-- thanks

[Fishrock123]

we should be able to get response from buggy servers in some purpose right?

Not really, if the content lengths were different how would we know which to use? Arguably we could ignore it if they are identical but it still highlights a downstream problem.

[jasnell]

The reason this check is necessary is that there are a number of security exploits that can be performed involving the use of multiple Content-Length headers. Different HTTP implementations treat multiple Content-Length headers differently -- some pay attention only to the first one, others pay attention only to the second one, others die completely as they are supposed to. The effect is that using multiple Content-Length headers has been proven to be an effective way to sneak content past firewalls/proxies/caches to deliver malicious content to clients.

Per: https://tools.ietf.org/html/rfc7230#section-3.3.3

If a message is received without Transfer-Encoding and with
either multiple Content-Length header fields having differing
field-values or a single Content-Length header field having an
invalid value, then the message framing is invalid and the
recipient MUST treat it as an unrecoverable error.

@bnoordhuis is correct that, per the spec, we are permitted to ignore multiple Content-Length headers that specify the same value:

Per: https://tools.ietf.org/html/rfc7230#section-3.3.2 (emphasis added)

If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message body
length or forwarding the message.

The safest (and most performant) thing to do is to simply reject the message.