please wait for a bit

This module only works for routes, not for middlewares like postgraphile. Unfortunately there is no real solution for this atm.

You'll need to develop something like https://github.com/mshick/hapi-postgraphile on top of https://github.com/mcollina/fastify-gql

Please open this again. I rebased it out however CI was failing badly.

This PR addresses adding secureOptions to ISecureClientOptions. This addition gives the interface the ability to accept secureOptions for TLS, including TLS version enforcement and cipher suite lists.

MQTT over TLS does not currently support adding TLS secureOptions on connect, so this is a new that improves our ability to control security on the MQTT client..

The code is ok, the test on the EventEmitter warning is missing

  this.once('connected', dequeue)

Please make this top-level, outside of this function.

Integration/black box test.

Start an external aedes broker and use MQTT.js to validate it works.

Done https://github.com/moscajs/aedes-cli

Instead of calling shift() just use a for(;;) loop and then assign this.parser._queue to null.

  this.once('connected', () => {

Can you please use a top level function for this listener instead of a closure?

This commit adds an option http2SessionTimeout to be able to gracefully closing an http2 server. This is analogous to the 5000ms timeout of keepalive connections.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Tip: npm run bench to compare branches interactively.

Contributors guide: https://github.com/fastify/fastify/blob/master/CONTRIBUTING.md -->

Checklist

• [x] run npm run test and npm run benchmark
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added
• [x] commit message and code follows Code of conduct

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Tip: npm run bench to compare branches interactively.

Contributors guide: https://github.com/fastify/fastify/blob/master/CONTRIBUTING.md -->

Checklist

• [x] run npm run test and npm run benchmark
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added
• [x] commit message and code follows Code of conduct

It seems this is consistently failing on ARM. @Trott can you take a look?

I don't think so. The current tests are too tied and this adds unnecessary complexity.

Can’t you? Il 23 gen 2020, 14:01 +0100, Daniel Lando notifications@github.com, ha scritto:

@mcollina Could you start another repo called aedes-cli? I think this is the best option — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Seems good, thanks!

I think this is already there Il 23 gen 2020, 13:47 +0100, Daniel Lando notifications@github.com, ha scritto:

@mcollina Is this a feature that needs to be added? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Implement more instance functions

• aedes.instances(): returns current running brokers list
• aedes.isConnected(clientId): returns if a clientId is currently connected to any aedes instance or not (all aedes instance can currently keep track of connected clientIds)

done

no clue

Il giorno gio 23 gen 2020 alle ore 12:26 Daniel Lando < notifications@github.com> ha scritto:

@mcollina https://github.com/mcollina Has this been fixed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/moscajs/aedes/issues/221?email_source=notifications&email_token=AAAMXY7FOKAZM3U5LXRYUFDQ7F5GZA5CNFSM4GDEJ5KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJXBWRA#issuecomment-577641284, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMXY6KFPTYQ3WCXDGFS3LQ7F5GZANCNFSM4GDEJ5KA .

sure thing, yes.

Hi! In npm the last version is 0.7.6, but the last version in the repo is 0.7.5. can you push the source code?

Pushed, sorry for this.

Thanks!

yes, definitely!

Il giorno gio 23 gen 2020 alle ore 10:30 Daniel Lando < notifications@github.com> ha scritto:

Ignore my PR so. WIll wait you to start a different repo for them. I think the actions.yml code can be taken as a base for actions (or not) ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/moscajs/aedes/issues/357?email_source=notifications&email_token=AAAMXY27ZVP2UBSL2IXUZSTQ7FPS7A5CNFSM4KKIU4IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJWXMVQ#issuecomment-577599062, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMXYYI6UIIT4L2FNREMPLQ7FPS7ANCNFSM4KKIU4IA .

Not a rewrite, new tests.

I'm +1 with a deprecation warning that includes the cutoff date and --insecure-http-parser.

I would prefer a very different approach.

Having some tests that use mqtt.js to connect to Aedes and very some of the basic functionality. Most of the tests here are unit and they expect things to run single-process.

Most of the tests are unit. We need a new batch of tests that works treating aedes as a black box.

IMHO, I'd place them in another repo.

I would say so, Mosca is currently dead.

This should significantly improve our cold start time on serverless, definitely +1.

I would recommend to open new issues for bug reports.

Yes, that's what I was trying to say. Remove all code from Mosca and replace the internals with Aedes, adding a CLI and an Authorizer.

Can you post the benchmark results?

I think we should improve the API with a few caveats:

1. a max number of retries for reconnects that will emit an error on the client itself, so we can potentially let the application do something.
2. an offline event, so that the app can do something
3. make the requests error after a timeout

I’m +1 if it does not cause a perf regression to the eventemitter, http, and streams benchmarks.

After getting to know ElasticSearch mappings, I would as well. Go ahead with the PR. Il 22 gen 2020, 22:02 +0100, Manuel Spigolon notifications@github.com, ha scritto:

I had the chance to understand better the case:

• the code I linked send the logs to elastic, it doesn't create the index • elastic, cause doesn't have the index of the day, create a new index with the default settings and it will index all the things

The logic I would apply in this module would be: if the user specified a custom mapping

• at startup create the index and ignore the error index already create • if the user define the %{DATE} index's name, schedule a timeout to create the next index (or "when the generated index name has changed, create it then continue logging")

Am I the only one that would like to apply a different mapping than the default? 🤔 😅 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

If you find the root cause, please send a PR!

My view of Mosca is to be “aedes standalone”, with a CLI and everything.

Why this? What about to make mosca unmantained (like it is from 2018) and redirect users to use aedes instead?

Mosca provides an out-of-the-box experiece with all the dependencies. I'm also happy to mark that unmaintained. Moreover, we should also add some integration tests that are currently missing. In my original ideas those would live inside Mosca, but they can also live in another repo.

Here is the authorizer https://github.com/moscajs/mosca/blob/master/lib/authorizer.js and docs are in https://github.com/moscajs/mosca/wiki/Authentication-&-Authorization#using-moscas-standalone-authorizer-with-an-embedded-mosca.

🐛 Bug Report

chokidar@2 depends on a vulnerable dependency as defined in https://app.snyk.io/org/mcollina/project/77093841-f46e-47c6-ae49-548b8c809106?utm_campaign=weekly_report&utm_source=Project&fromGitHubAuth=true.

Chokidar@3 requires Node 8 as a minimum version. I've already sent a PR to pino-colada to update it https://github.com/lrlna/pino-colada/pull/33.

Proposal

I propose we drop Node 6 and update chokidar@3 and release a new major. We can also update some other dependencies, and potentially drop Node 10 as well.

The other option is to do nothing, as chokidar should only be used during dev and it really as no risk - however there is no way to mark this as "safe" in npm audit.

(Lesson for ourselves, we should have shipped Fastify@2 without the support for Node 6 - my fault)

Closing, our dependency tree is not vulnerable at all, the vuln database had the wrong range.

Actually, it's already fixed.

Chokidar@2 depends on this module in version 3.x. It would be great to release the security fix to this line, so that Chokidar@2 is not vulnerable anymore.

I think the security fix is https://github.com/jonschlinkert/kind-of/commit/975c13a7cfaf25d811475823824af3a9c04b0ba8. Is this the only thing?

I'm happy to do the PR to backport the change if you cut me a 3.x branch

Let me know once the db is updated.

That dependency tree uses kind-of@3.2.2 and kind-of@5.1.0, so I think we should be good.

Would you like to craft one? From my point of view:

[ ] update Mosca so that is based on Aedes and mqemitter (this means a full rewrite of the codebase) [ ] use github action to test all the persistences / mqemitter on separate processes to avoid limits of the databases [ ] implement the authorizer. [ ] closing all issues and PRs that are outstanding

On top of this, we should work on adding MQTTv5 as a long term activity

@lirantal can you help?

Would you like to be added to the org?

I've also asked the module to be updated so we do not have the security fix: https://github.com/jonschlinkert/kind-of/issues/33.

Chokidar@2 depends on this module in version 3.x. It would be great to release the security fix to this line, so that Chokidar@2 is not vulnerable anymore.

I think the security fix is https://github.com/jonschlinkert/kind-of/commit/975c13a7cfaf25d811475823824af3a9c04b0ba8. Is this the only thing?

I'm happy to do the PR to backport the change if you cut me a 3.x branch

Note that moving from pino-colada to pino-pretty as defined in #214 solves only part of the problem.

🐛 Bug Report

chokidar@2 depends on a vulnerable dependency as defined in https://app.snyk.io/org/mcollina/project/77093841-f46e-47c6-ae49-548b8c809106?utm_campaign=weekly_report&utm_source=Project&fromGitHubAuth=true.

Chokidar@3 requires Node 8 as a minimum version. I've already sent a PR to pino-colada to update it https://github.com/lrlna/pino-colada/pull/33.

Proposal

I propose we drop Node 6 and update chokidar@3 and release a new major. We can also update some other dependencies, and potentially drop Node 10 as well.

The other option is to do nothing, as chokidar should only be used during dev and it really as no risk - however there is no way to mark this as "safe" in npm audit.

(Lesson for ourselves, we should have shipped Fastify@2 without the support for Node 6 - my fault)

chokidar@2 depends on a vulnerable dependency as defined in https://app.snyk.io/org/mcollina/project/77093841-f46e-47c6-ae49-548b8c809106?utm_campaign=weekly_report&utm_source=Project&fromGitHubAuth=true.

In the process of updating chokidar, I've updated most of the dependencies (minus Merry, as it does not log by default anymore) because I thought it was handy.

This change in semver-major as the minimum version of Node.js needed by chokidar is 8.

Hello, then i use compress brotli content encoding in browser gz

This module does not offer caching for compressed files, and it will compress the file each time it is read. Given that brotli provides better compression, I would expect that it takes longer to compress.

I would recommend to use nginx in front of your Node.js process, as it's an overall better solution for serving files.

It would work automatically on recent Node.js, see https://github.com/fastify/fastify-compress/blob/c99f2fab776f0b9139e33f2fdc374be57ef5c29c/index.js#L86.

Is this not working for you?

Hello, i try use webpack comression, output gzip files.

link rel="preload" href="/dist/4.52e140b28097204e4353.chunk.js" as="script"

js files work, gzip not

image https://ibb.co/3c45HQM Webpack created two variants file, js and compressed sometimes size 1/3 from original, greate time economy

i think this is it 1 "The NginxHttpGzipStaticModule is enabled by adding gzip_static on; to the nginx.conf" 2 https://www.npmjs.com/package/express-static-gzip 3 https://github.com/koajs/static

This is server support? Not client?

how i can enable this?

compression is enable automatically with fastify-static if the browser supports it, you do no have to do anything.

I think this PR should also change the docs: https://nodejs.org/api/url.html#url_url_username.

Technically this can be seen as a patch or semver-major change, and I'm uncertain between the two.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Tip: npm run bench to compare branches interactively.

Contributors guide: https://github.com/fastify/fastify/blob/master/CONTRIBUTING.md -->

Checklist

• [x] run npm run test and npm run benchmark
• [x] tests and/or benchmarks are included
• [x] commit message and code follows Code of conduct

@brianwarner Fastify is missing. Where may I send a PR to?

Would a flag to avoid adding the mapping be enough then?

there is no need to use after here.

I don't understand what you are trying to achieve and what is the problem.

If I understand correctly, using https://github.com/fastify/fastify-static should solve your problem.

Quick errata: 10.x will go EOL on April 2021, while 12.x will go EOL on April 2022.

From my experience in dealing with production system, this seems a very dangerous proposition for our backward compatibility story. Changing the http parser is a breaking change, and the TSC can decide to ship a breaking change in LTS if we think it is important.

I am +1 in removing http-parser from 12.x with the introduction of --insecure-http-parser, as it seems to have fixed most of the issues in the migration. Removing it from 12.x will shorten our support window by one year, and I think it'd be a good compromise.

I'm more conflicted about what to do with 10.x. Do --insecure-http-parser have the same quirks of http-parser? In case, can we consider shipping llhttp with --insecure-http-parser turned on in v10.x?

Added a reference to chainable methods on 'inject' function based on the update of 'light-my-request'

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Tip: npm run bench to compare branches interactively.

Contributors guide: https://github.com/fastify/fastify/blob/master/CONTRIBUTING.md -->

Checklist

• [x] run npm run test and npm run benchmark
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added
• [x] commit message and code follows Code of conduct

I'll bump twice, it's just an integer. Il 21 gen 2020, 19:42 +0100, Manuel Spigolon notifications@github.com, ha scritto:

@Eomm approved this pull request. Should we wait fastify v3 for this major release or will bump twice? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

I don't see how, there is very little state involved

ok

yes! All of this solves some issues with http2 that it was not really possible to fix with the implementation that were in Node 8. Il 21 gen 2020, 13:26 +0100, James Sumners notifications@github.com, ha scritto:

@jsumners approved this pull request. LGTM This will be released as a new major, right? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

## Persistences

We should probably include links to the mqemitter equivalents as well.