brotli support

[patrickkettner]

It would be great to be able to server assets with brotli - especially if I could precompile and serve with lookupCompressed. In general it has a much better compression ratio than gzip.

[hueniverse]

I don't know what exactly you are asking for.

[jamesdixon]

He appears to be asking for Hapi to support brotli compression in addition to gzip as well as allowing inert to lookup pre-compressed assets created with brotli. Maybe something that could be done in a plugin for the time being? Browser support appears to be nearly non-existent at this point....

[patrickkettner]

Sorry for not being clearer. James is correct. Browser support is low, but it is a requirement for WOFF2 web fonts, and as such all browsers will be implementing it in the near future.

On Jan 30, 2016, at 5:52 PM, James Dixon [email protected] wrote:

He appears to be asking for Hapi to support brotli compression in addition to gzip as well as allowing inert to lookup pre-compressed assets created with brotli. Maybe something that could be done in a plugin for the time being? Browser support appears to be nearly non-existent at this point....

—
Reply to this email directly or view it on GitHub.

[hueniverse]

I'll consider a PR.

[nrotta]

@patrickkettner I will give it a try. I have an initial version (sort of) working and have already pushed the changes to Inert to my fork. Will push the initial hapi changes to my fork next.

Consider that I'm just starting with Hapi so my code might require lots of changes.

[nrotta]

@patrickkettner I finished the work to support brotli on hapi. Looks like it works. Can you please check it out?

You have to use the following from my fork:

hapi (master branch): https://github.com/nrotta/hapijs
subtext (master branch): https://github.com/nrotta/subtext
inert (brotli branch): https://github.com/nrotta/inert

I have a failing test on inert so I cannot send the PRs yet. I will fix it over the next few days.

Thanks

[patrickkettner]

I'd love to check it out! did you mean https://github.com/nrotta/hapi ? https://github.com/nrotta/hapijs doesn't exist

I only ask because nrotta/hapi doesn't contain any brotli commits form what I can see.

[nrotta]

Yes, you are right. Sorry typo. The correct one is: https://github.com/nrotta/hapi

Let me know how it goes.

[patrickkettner]

awesome work! It is not working for me, however. I believe this line has to be modified in order for brotli to be one of the encodings that is possible. or am I screwing something up?

[nrotta]

I did modify that line: https://github.com/nrotta/hapi/blob/brotli/lib/request.js#L119

Try the brotli branch on my fork and let me know how it goes.

Btw, it took me a while to get my fork to be installed as a dependency in hapi. Not sure why but the updated code was not being installed. Once you install my hapi fork, you have to change the package.json to point to my fork of inert and subtext. And check the content of node_modules in your hapi install to ensure that the inert & subtext libs have my changes (you can look for 'brotli' on the code base).

Thanks

[AdriVanHoudt]

@nrotta this is probably due to the shrinkwrap

[patrickkettner]

@nrotta yeah, I found that out. npm link is how I usually get around sub dep issues

the latest change doesn't work. In this context, it would be br, not brotli. And since Accept.encodings() is finding the first supported compression type in the list, brotli wouldn't ever be reached behind gzip. If you move br to the front of the list (since it should be preferable, I imagine)

[nrotta]

@AdriVanHoudt you are right. Thanks.

@patrickkettner you can set { 'accept-encoding': 'brotli' } in the header of the request and should work with brotli (instead of the default gzip). Btw, how are you testing? Can you send me the code to ensure that I'm not missing anything?

Regarding using br instead of brotli that could be changed but for what I read online there is no naming defined so I decide to go with brotli for the name of the encoding and br for the extension.

[patrickkettner]

Regarding using br instead of brotli that could be changed but for what I read online there is no naming defined so I decide to go with brotli for the name of the encoding and br for the extension.

Chrome and Firefox send br. here is an example of Chrome's AE header

Accept-Encoding:gzip, deflate, sdch, br

I don't believe any one uses the string brotli in his context

@patrickkettner you can set { 'accept-encoding': 'brotli' } in the header of the request and should work with brotli (instead of the default gzip).

Sure, but no browser sends that header. they send something like the one I used above. gzip is always there as well

how are you testing

I don't have my laptop on me, but I just npm i nrotta/hapi, cd into node_modules/hapi, and npm i nrotta/subtext nrotta/inert#brotli

From there, I just used the hello world hapi example with a single route (and self signed SSL, since its a requirement for browser usage)

[nrotta]

@patrickkettner you are right. I changed the encoding to 'br' and increased the priority of br over gzip.

Please check it out and let me know.

[hueniverse]

Now possible via the new server methods decoder and encoder

[kanongil]

Quick note that Inert has now been updated with multiple encoding support, and can serve pre-compressed brotli files with my newly published brotli encoder / decoder plugin.