Node.js community finally prodded to patch Chromium XHR bug after developer refuses to let flaw stand

The Node.js community has finally taken steps to address a longstanding bug that has been hobbling XHR requests over HTTP/2 in Chromium-based browsers, though the fix won't be immediately available to everyone. "HTTP/2 XHR requests are literally broken in Chrome/Chromium, but no other browsers," explained a software developer …

[Brewster's Angle Grinder]

I've just spent lunch trying to understand this. What happens is when XMLHttpRequest is used from Chrome to talk to a Node server, Node sometimes drops the request.

The Chrome investigation is covered here. It takes 52 comments before the Chrome guy to be able to reproduce the bug. And for most of that, I'm not convinced he's doing anything other than debugging niftylettuce's site. But the Chrome team remains professional throughout (although I bet there was steam let off behind the scenes).

The final solution is "Chrome sets the fin bit of the final non-empty data packet to true, which apparently triggers a bug in the server. Other browsers instead send a separate empty data packet with the fin bit set to true at the end of the request body." So node can't handle non-empty final data packets.

[stiine]

Where does the http/2 spec say that the fin may occur?

[Anonymous Coward]

Here.

"The DATA frame defines the following flags:

END_STREAM (0x1):

When set, bit 0 indicates that this frame is the last that the endpoint will send for the identified stream. Setting this flag causes the stream to enter one of the "half-closed" states or the "closed" state (Section 5.1)."

[Brewster's Angle Grinder]

As Def says, it's the http/2 fin bit not the TCP one. Http/2 has its own frames which flow over a single TCP connection.

[Mike 16]

_Chrome_ sets the FIN bit?

OK, I've been retired for a while, but since when is it up to user code to handle the plumbing of TCP/IP?

Does Chrome have its own stack? Or does (user mode) HTTP/2 reach down into TCP to change the specs?

(Commenting mainly because it was once not uncommon to see a packet with both SYN and FIN set,

and some stacks didn't crash.)

[Anonymous Coward]

Re: _Chrome_ sets the FIN bit?

It's a ...Chrome bug... I guess? The way the article is written I can't tell if it is exclusive to using Chrome with node.js servers or Chrome itself everywhere, the article goes back and forth with context.

*IF* it's exclusive to Chrome+node.js servers, yeh that's a bad look and I'd say that in itself is a security risk regardless of XHR.

[Anonymous Coward]

Re: _Chrome_ sets the FIN bit?

As I understand it, Chrome sets the END_STREAM bit of the last HTTP/2 data packet to be sent. Other browsers send the last true data packet as normal followed by an empty packet with the END_STREAM flag set.

I guess the bug in Node.js is it throws away the data of any packet with END_STREAM set. (But I really am just guessing here.)