News for hackers. Stuff that matters.

A comment on Retrospective and technical details on the recent Firefox outage. Parent comment

Re:Retrospective and technical details on the recent Firefox... by lmm on Wednesday February 02, 2022 @05:01AM (#30175678)
> Why does my browser need connectivity to some internal services? I am fine with offering opt-in service integration (Firefox Sync, Pocket, ...) but is there a reason why Firefox needs internal infrastructure to do the one thing it is supposed to do, browsing the web?

If you read the whole post, the connection was explicitly for telemetry (and so you could avoid the issue by turning off telemetry), and it blocked other connections because the request went into an infinite loop rather than failing outright.

[ Parent | on HN ]
Re:Retrospective and technical details on the recent Firefox... by nanis on Wednesday February 02, 2022 @05:20AM (#30175798)
> If you read the whole post, ... (and so you could avoid the issue by turning off telemetry)

Speaking of reading the whole post:

>> users who disabled Telemetry would see this problem resolved even though the problem is not related to Telemetry functionality itself and could have been triggered otherwise.

This does not make sense to me:

>> Without the header, the request was determined by the Necko code to be complete,

This is written as if it makes sense to treat a request as "complete" when it's missing a content length header. Huh?!

[ Parent | on HN ]
Re:Retrospective and technical details on the recent Firefox... by mozdeco on Wednesday February 02, 2022 @05:36AM (#30175895)
At this point, the code relied on the Content-Length header being present because the higher-level API was supposed to add it. The field that is supposed to be populated by Content-Length (mRequestBodyLenRemaining) is pre-initialized to 0.
[ Parent | on HN ]
Re:Retrospective and technical details on the recent Firefox... by lmm on Wednesday February 02, 2022 @06:47AM (#30176323)
> users who disabled Telemetry would see this problem resolved even though the problem is not related to Telemetry functionality itself and could have been triggered otherwise.

All they mean by that is that it was a bug in their HTTP/3.0 code that could have been triggered by any HTTP/3.0 connection that was using that codepath. But the reason for that particular connection (which had the conditions to trigger the bug) was for telemetry.

[ Parent | on HN ]