I would like to use beast to send the push notifications to Apple Push Notification Service, it requires the HTTP2(https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW1) support, my question is does beast is support HTTP2 now ?
Thanks!
No
It is unlikely that Beast will ever support HTTP/2, as there is now a published HTTP/3 specification (based on QUIC).
The proposed HTTP/3 can't be the reason for not wanting to support HTTP/2 (which works today in all major browsers already).
What is the real reason?
HTTP/2 (and to some extent HTTP/3) is difficult and complex to implement, probably more difficult than it was to write all of beast in the first place. The amount of value that comes out of implementing a new HTTP version is relatively low compared to the other things I could be working on now (such as automatic websocket timeouts or more multi-threaded server examples).
It would very likely take over a year of focused effort to have HTTP/3, so I have to carefully choose what to work on in order to generate the most value since I am just one person working on this. Now, it doesn't mean that HTTP.Next will never happen, but I have other more high priority things to take care of for now.
Nothing stops someone from building a new HTTP/2 or HTTP/3 library from Boost.Asio's networking APIs, and using Beast's http::message container (can't use the parser and serializer obviously, or the stream algorithms). They could also use Beast's core functionality such as the composed operation helpers and various buffer types and algorithms. Such a library could interoperate nicely with other libraries that use Beast - HTTP/1, HTTP/2, and HTTP/3 messages are the same and could use the same Beast container.
Perhaps you could write it?
If you're not partial to windows (where it won't build natively yet), nghttp2 already provides libnghttp2_asio.
I've built it with cygwin and in docker containers on Windows. Works great on Linux and Mac. shrug
If you're not partial to windows (where it won't build natively yet), nghttp2 already provides libnghttp2_asio.
I've built it with cygwin and in docker containers on Windows. Works great on Linux and Mac. _shrug_
It seems this lib has C++ already integrated and ready to use as you can see here in this file: https://github.com/nghttp2/nghttp2/blob/master/src/nghttpd.cc
It is unlikely that Beast will ever support HTTP/2, as there is now a published HTTP/3 specification (based on QUIC).
So you planned to add HTTP/3 soon? Do you have a timeline for this?
I don鈥檛 think we have plans to include http3 into beast.
I don鈥檛 think we鈥檝e seen a compelling motivation yet.
@madmongo1 Then could nghttp2 be adapted to be used with Beast? It seems they also use asio but do not require it. Have you looked at this option?
I haven鈥檛 looked into nghttp2 as I鈥檓 not a maintainer of it. Happy to offer help if the maintainers would like to use beast.
Most helpful comment
HTTP/2 (and to some extent HTTP/3) is difficult and complex to implement, probably more difficult than it was to write all of beast in the first place. The amount of value that comes out of implementing a new HTTP version is relatively low compared to the other things I could be working on now (such as automatic websocket timeouts or more multi-threaded server examples).
It would very likely take over a year of focused effort to have HTTP/3, so I have to carefully choose what to work on in order to generate the most value since I am just one person working on this. Now, it doesn't mean that HTTP.Next will never happen, but I have other more high priority things to take care of for now.
Nothing stops someone from building a new HTTP/2 or HTTP/3 library from Boost.Asio's networking APIs, and using Beast's
http::messagecontainer (can't use the parser and serializer obviously, or the stream algorithms). They could also use Beast's core functionality such as the composed operation helpers and various buffer types and algorithms. Such a library could interoperate nicely with other libraries that use Beast - HTTP/1, HTTP/2, and HTTP/3 messages are the same and could use the same Beast container.Perhaps you could write it?