Once a release candidate is issued, only documentation changes and changes to address critical bugs should be made. In general the bar for bug fixes at this point is even slightly higher than the bar for bug fixes in a minor release. We may prefer to issue a release with a known but very rare crash than to issue a release with a new but not production-tested fix.
One of the criteria for issuing a release candidate is that Google be using that version of the code for new production builds by default: if we at Google are not willing to run it for production use, we shouldn't be asking others to.
The closer you are to a release, the bigger the blocker needs to be. If there was incorrect behaviour in a mainline use case, that would be much more significant than a performance regression.
A 20% performance regression in a minimal http server (i.e. one that doesn't have any business logic) does not sound like a big problem to me; that kind of overhead would normally be dwarfed by database calls, and a 20% increase in the overhead doesn't sound like it's a large increase in what I'd expect to already be a very small number.
So a similar situation in node.js-land would be if require('http') would get a worst-case scenario of a 20% performance hit, right?
If this is the case, even I, who only run single instances of node, would think it would be a fairly big impact that i'd try to fix if I was the maintainer and still had the possibility to fix it.
The issue is that's it's 20% of the http library's time, not 20% of your application's time. Put a large app on it, and now the regression is 0.02%... Does it still make sense to push everything back for that 0.02%?
Usually, the release candidate is modified only if significant bugs are detected. But this this branded more of an implementation pitfall so I doubt it'll be fixed.
You're absolutely right about asking if it can be fixed now rather than later (I was very surprised they wanted to wait till 1.9!), and thanks for asking that on there. 1.8 would be known for this bug in case of static site hosting since there are more req/s for that use case, if this did make the official release.
It should be noted that it was tested against a hello world benchmark and it won't matter in higher payload cases when the limiting factor isn't the extra routine but the payload itself by a long shot.
I have never used GO so it might be a bit rude of me to ask. But when I looked at the commit, it seemed to be a fairly small subset of changes which I, maybe stupidly, assumed meant that it would be quick to fix. :)
If not, could someone please educate me?