Node v8.8.0 | Hacker News Reader

Node v8.8.0

nodejs.org

199 pointsnikolay46 comments

Open articleView on HN

Notable Changes

* crypto:

- expose ECDH class

* http2:

- http2 is now exposed by default without the need for a flag

- a new environment varible NODE_NO_HTTP2 has been added to allow userland http2 to be required

- support has been added for generic Duplex streams

* module:

- resolve and instantiate loader pipeline hooks have been added to the ESM lifecycle

* zlib:

- CVE-2017-14919 - In zlib v1.2.9, a change was made that causes an error to be raised when a raw deflate stream is initialized with windowBits set to 8. On some versions this crashes Node and you cannot recover from it, while on some versions it throws an exception. Node.js will now gracefully set windowBits to 9 replicating the legacy behavior to avoid a DOS vector.

‘Userland’ http2? As opposed to being implemented as a Linux kernel module?

No, there is an npm package that has the same name. Userland === npm package

I think it would be Userland instanceof npm package === true

that might not work in an iframe ;)

In case anyone missed it, a Node module used in production at Bing to multi-thread shared memory for CPU-intensive work hit the big time last week.

https://github.com/Microsoft/napajs/wiki/Why-Napa.js a bit edited:

1) quick iteration

2) multiple cores

3) share memory with structures

4) fine granularity parallelism, minimizing communication cost

Discussion: https://news.ycombinator.com/item?id=15498219 (Oct 2017, 201 comments)

Some info about CVE-2017-14919 here: http://nodejs.org/en/blog/vulnerability/oct-2017-dos/

To test if your version is affected:

    zlib.createDeflateRaw({windowBits: 8})

Is version 8 still planned to enter active LTS on 10/31? Or does this release mark the beginning of LTS?

Does it server-push my Link preload header resources? (https://w3c.github.io/preload/#server-push-http-2)

That would typically be implemented by a proxy or service like Cloudflare. The server itself should not do this based on header contents - instead the application should use the push protocol directly: https://nodejs.org/api/http2.html#http2_http2stream_pushstre...

It wouldn't be appropriate for the http2 core module to do this implicitly, but I wouldn't be surprised if higher level server abstractions, such as Express, did implement such a feature (though imo it'd still be better to not use the Link header).

It's also likely to work a lot better for a caching proxy to perform this action rather than the source server - since it can cache the contents of the resources being pushed.

How efficient is to have an HTTP2 server serving sever-push events to thousands of clients? Better than websockets I assume.

Do you mean Server-Sent Events? That's a well-supported and efficient model that'll work fine, although the payload will always be heavier than websockets since all the headers have to be sent, even if compressed within the HTTP/2 stream. It's also not supported on IE or Edge.

If you actually mean server-push then that would basically be long-polling and not very efficient, also it's meant to send along assets that the server already knows will be needed for a request (like CSS with the HTML). There's not much client-side API to actually deal with server-push because it's just like another network http request/response.

I’m sorry, but when you mention all headers need to be sent, what are you referring to? I have working SSE implementations where I only send out the headers once and then pipe minimal data to the client while the socket is open.

You're right, I misspoke. I meant that the "data: " pseudo-header for each SSE message is always included, and repeated for multiple lines (but it's HTTP so can be gzipped). It's also UTF8 encoded and meant for text while websockets can send the exact binary bytes you need and no more. Either way, it doesn't really matter unless it's a latency-sensitive or high-volume service, but I prefer the simplicity of SSE.

Yeah, but packets being able to be maximized to the window size of the connection early on (and being able to have more than 6 "parallel" downloads as a result) is great for initial page loads.

Server push is not like long polling because the connection is shared. You could keep a stream open and push messages as needed. This already sort of is possible with fetch in the browser, but iirc there are some things the spec authors are working on for this use case.

You can't do much with these assets. These are plain network requests as far as the browser is concerned so there's no API logic for your JS code to use. You're limited to just forcing the browser to download more things and it can also choose to ignore these push requests.

You can do whatever you want with them. For example, let's say you push /api/todos and your client-side code does a `fetch('/api/todos')`. This stream stays open, and the client code can receive each message as they come in, using ReadableStream.

Now the server, having this connection open can later push more data into this /api/todos stream. Boom, you have websockets. Without needing a separate port and connection.

You just described long-polling: holding the connection open until the response arrives or it times out.

Even if you just send push-promises and push-responses while keeping the original response stalled (and the browser accepts the response), the client-side JS still has no idea what those requests were or what was loaded.

SSE is the evolution of long-polling so that browsers already include the logic to keep a connection open with streaming updates so that you can avoid all this in the first place.

This differs from long polling in that http2 doesn't create a new connection. Also long-polling is request and then response, whereas http2 is (like websockets) full duplex.

Small nitpick: long-polling can be done over http/2, in which case the connection is shared.

We use SSE for realtime identity verification updates at CertSimple but note it's hampered by lack of support in Edge - looking at Microsoft's roadmap it doesn't look like it's coming soon either.

But i think SSE can easily be polyfilled, not sure about performance though.

Yep, trying to get away from polyfills though - we only support current browsers and doing so avoids a bunch of unnecessary complexity.

I can't speak for exact performance comparisons but server-push isn't designed for events like SSE or websockets. It's designed for the client to make a request and the server to efficiently responded with multiple payloads to populate a client cache.

I'm pretty sure that's not how server push works. Client requests A, then server pushes B and C with A. Server just cannot push something to God knows where.

Server-Sent Events (SSEs) are actually a thing. Sure, the client must establish a connection with the server first, but from then on data can be streamed from the server. Similar to websockets, but then a one-way connection from server to client.

But do SSEs have anything to do with HTTP/2 server push?

They do not. https://en.m.wikipedia.org/wiki/Server-sent_events

If you mean Server sent events then no, WebSockets are still more performant.

I'm ignoring the fact that SSE are not replacement for WebSocket because with SSE we can't send data from client to server.

I'd like to see the non-LTS version of node in 8.x move to OpenSSL 1.1 and expose more: scrypt, schnorr, curve25591, bn etc.

There is no good internal password storage, and bitcoin operations require bringing in most libs

scrypt: https://github.com/nodejs/node/issues/8417

Not sure if you read that issue because it was closed as it depends on OpenSSL 1.1.

Fire up 8.8.0 and you'll find crypto.scrypt is undefined.

nodejs will have to get the OpenSSL 1.1 upgrade in as the support period for nodejs 8.x exceeds the support period for OpenSSL 1.0.x

First attempt was made here[0]

[0] https://github.com/nodejs/node/pull/11828

"Not sure if you read that issue because it was closed as it depends on OpenSSL 1.1."

Sure, I opened the issue.

I provided the link so you can follow it.

It would be great to have scrypt in Node, as well as argon2 and DJB's chacha20+poly1305.

NodeJS will be way faster with the HTTP/2 support. GG!

Can I use client side certificates with http2?

Does anyone know what happened to Ayo.js?

It would be great to hear from an insider, but it seems to me like they are having a little difficulty establishing organization around roles/permissions. Also the GitHub repo hasn't seen any commits in a month.

https://github.com/ayojs/ayo/graphs/commit-activity

You are in a maze of twisty pronouns, all alike.

Seems like they got stuck on discussing codes of conducts and genders and forgot to do actual work.

Well they do use the slogan "Humans before technology." so I am sure "the community" is more important than any kind of actual technology, code or advancement of node

Those "commits" are just bringing in stuff from Node.js as far as I can see

I would be very surprise if people took that fork seriously.

the sj witch hunters got bored and moved on to another victim?

Most likely polishing their code of conduct.

Nothing. It was not even a newsworthy event. Someone somehow managed to get a story published somewhere about it.

Reply on news.ycombinator.com