Hacker News Reader

Comment by danielmg | Hacker News Reader

Reading the bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1749957#c5 and then the code, isn't there still a problem if content-length is not set by the server? Not that it should ever not be set but...

  if (contentLengthStart == -1) {
    // There is no content-Length.
    return;
  }

That's the same flow it would have taken with the case sensitive code.

View on HN

That comment is interesting too:

"I'm just a random kibbitzer, so my apologies if this is off-base, but... isn't an even more fundamental problem here that the code is doing a naive string-based search in the first place? For example, I believe this is a valid HTTP header block that could be passed into this code:

GET / HTTP/1.1\r\nHost: example.com\r\nCookie: foo="Content-Length: 100"\r\n\r\n (In particular, GET requests normally don't have a content-length header at all, since the default if none is present is to assume an empty body.)

Wouldn't this cause the code to compute the wrong body length and break things?"

> Not that it should ever not be set

I am an HTTP/1.1 dinosaur. Is chunked transfer encoding no longer a thing in HTTP/3? It used to be a valid reason to omit Content-Length.

> Is chunked transfer encoding no longer a thing in HTTP/3? It used to be a valid reason to omit Content-Length.

IIRC HTTP/2 and HTTP/3 are essentially always chunked. I would expect a missing content-length to be completely valid.

That is correct. By default HTTP/2 and HTTP/3 requests are streamed and can have an "infinite" length. The presence of a content-length header will limit limit that length, and inform the peer upfront on how much data will be sent.

For HTTP/1.1, a stream where the length is not known upfront required the usage of chunked encoding. With HTTP/2 and /3 that encoding is no longer required since the underlying protocol already support framing and contains and end-of-stream information.

I suspect no, because there is no mismatch between there being no content length header found by this file and the content header later being discovered by some other part of the code. It'll probably require more digging but I don't think FF would crash if the header was missing, this was likely caused by the header existing but this part disagreeing about it.

Plenty of servers out there configured not to return /Content-Length:\s?(\d+)/i at all. I mostly stumble upon them in my video plugin. m3u8 (content-type: application/vnd.apple.mpegurl) resources seem to be particularly configured this way most of the time.

Note that this code is parsing the client’s requests, not the server’s responses.

Reply on news.ycombinator.com