Package Details: h2o 2.2.6-1

Git Clone URL: (read-only, click to copy)
Package Base: h2o
Description: Optimized HTTP server with support for HTTP/1.x and HTTP/2
Upstream URL:
Licenses: MIT
Conflicts: libh2o
Provides: h2o, libh2o
Submitter: atweiden
Maintainer: HLFH
Last Packager: HLFH
Votes: 28
Popularity: 0.006164
First Submitted: 2014-12-26 01:26
Last Updated: 2020-04-16 10:57

Latest Comments

1 2 3 Next › Last »

HLFH commented on 2020-04-16 10:58

h2o has been updated to 2.2.6.

rgacogne commented on 2019-11-21 08:50

Thank you for maintaining this package! I really would like to see it upgraded to 2.2.6 which fixed several security issues (CVE-2019-9512 CVE-2019-9514 CVE-2019-9515). I can offer to take ownership of this package in the AUR if that helps, since it's used to provide DoH support by the dnsdist-git package I already maintain anyway.

grigruss commented on 2019-09-19 06:30

How about upgrade? I tryed build version 2.2.6, and it's working. Just change version to 2.2.6 and sha256sums to: ('f8cbc1b530d85ff098f6efc2c3fdbc5e29baffb30614caac59d5c710f7bda201' '8a85462b6798deaaab343b5dae73437e251c5018d70d260a4a4440b9bbb053e6')

nickcorona commented on 2019-04-20 13:54

Bison is a missing dependency.

The_Decryptor commented on 2017-01-21 06:38

I tried upgrading to the 2.1.0 package but it refused to install on my system, `makepkg -i` kept spitting out this error

error: failed to commit transaction (conflicting files)
h2o: /usr/lib64 exists in filesystem
Errors occurred, no packages were upgraded.

I think it's because of this upstream commit, but since I've never used cmake before I've really got no idea.

Easy to fix though, just add `-DCMAKE_INSTALL_LIBDIR=/usr/lib` to the cmake line in build() and it installed fine for me.

The_Decryptor commented on 2016-06-27 05:12

The variant of ChaCha20 in the version of LibreSSL that h2o bundles isn't the final IETF variant, it's a earlier Google proposal. LibreSSL 2.4+ supports the IETF variant (Needed for browsers like Firefox that don't support the earlier variant) and OpenSSL 1.1 supports the IETF version as well.

Something that is different though, is that OpenSSL 1.1 supports Curve25519, while I can't find any reference to any version of LibreSSL supporting it, so when 1.1 is out it might be worth switching to OpenSSL for that.

And thanks for providing the package, been using it for a while and it works great!

wlhlm commented on 2016-06-24 17:59

@atweiden Thanks for the quick update!

atweiden commented on 2016-06-24 17:31


I made mruby explicit. Thank you for the recommendation.

> I think using a bundled SSL lib is bad, I much prefer it being managed as explicit dependency by the package manager

Perhaps when the official arch openssl package supports chacha20-poly1305, this can be re-examined; though, even then I would still lean towards doing what the author of h2o recommends, which at this time is using the bundled libressl [1]:

“Generally speaking, we believe that using LibreSSL is a better choice for running H2O, since LibreSSL not only is considered to be more secure than OpenSSL but also provides support for new ciphersuites such as chacha20-poly1305 which is the preferred method of Google Chrome. However, it is also true that LibreSSL is slower than OpenSSL on some benchmarks. So if you are interested in benchmark numbers, using OpenSSL is a reasonable choice.”

There are very few arch systems using libressl right now, so I doubt if the external option is going to be viable except in the case that you are willing to forego libressl for openssl. I'm only aware of libressl being the default on Void Linux systems.


wlhlm commented on 2016-06-24 12:43

Thanks for packaging h2o!

I have a couple of suggestions in regards to packaging:

- h2o can embed ruby for request handling, which can be configured via the -DWITH_MRUBY cmake option. When this option is not explicitly specified, the build script tries to automatically detect whether ruby is installed or not resulting in different packages depending on the build environment. I would prefer to have this option set explicitly (it currently is not) so that h2o builds the same in every environment. I've tested it and it seems that ruby gets statically linked and is not required as runtime dependency (though is needed when building applications with libh2o). This means adding 'ruby' to makedepends(), and optdepends() and '-DWITH_MRUBY=on' to cmake should do the trick.

- libtool, make, and pkg-config can all be removed from makedepends(), because users of the AUR are assumed to have the base-devel group installed [1] of which the previously listed packages are a part of.

- just for consideration: I think using a bundled SSL lib is bad, I much prefer it being managed as explicit dependency by the package manager. In case of a security update one has to wait for the h2o maintainer to update the bundled lib and one has to wait for the maintainer of the h2o package to update the PKGBUILD. When linking to an external lib it's likely to get updated in a more timely fashion and it doesn't require an updated PKGBUILD (no rebuild). Now when using an external SSL lib I think using openssl is the best option here, since there is no libressl package in the official repositories and the only libressl package in the AUR is for the unstable 2.4 branch. So to sum it up I think that using the external openssl lib from the official repos is still a better option than to use the bundled libressl, despite it being discourage in the h2o install instructions.

BTW, h2o 2.0.1 [2] has just been released.


nos1609 commented on 2016-03-21 21:33

No need for bundled ssl flag