Cowboy issues

[CrowdHailer]

@willemdj Hi,

I saw your thread on HTTP/2 features in cowboy. I have been working on an HTTP/2 server. It is clearly not as mature as cowboy but was developed HTTP/2 first so might be more useful for a GRPC foundation. The possible downside from your point of view is at the moment it is in Elixir. I haven't yet worked out how to use an Elixir lib in erlang but I would certainly like to set that up.

Quick summary of the issues you raised here ninenines/cowboy#1191

• It does send trailers
• it makes some assumptions about the headers sent when falling back to HTTP/1 but none about what is sent over HTTP/2 so there are no date and server headers by default
• The peer certificate could be more tricky, but I am currently looking at how to expose more information about the connection.
• headers are a list so ordering should be fine
• flow control, that is a feature I am trying to hold off on until after 1.0 to limit workload.

[tsloughter]

@CrowdHailer for building elixir libs in an Erlang project see https://github.com/barrel-db/rebar3_elixir_compile, it works well.

[willemdj]

@CrowdHailer <https://github.com/crowdhailer> - Nice. In order for gRPC security to work, access to the certificate is necessary (but you can do gRPC without security - I don't know what people do in practice). There must be a minimal level of flow control, because otherwise traffic will stall. But if I understand it correctly you implemented some form of automatic flow control, for most purposes that should be sufficient. I think that it will be pretty difficult for Cowboy to implement "proper" flow control - I don't think it will be easy to combine it with the current API and structure. So perhaps this is an area where a server that was designed for HTTP/2 could be a better option than Cowboy. If you want to create a binding for gRPC we can discuss how to do it, most likely it won't be very hard. Regards, Willem 2017-10-17 17:30 GMT+02:00 Tristan Sloughter <[email protected]>:

…

@CrowdHailer <https://github.com/crowdhailer> for building elixir libs in an Erlang project see https://github.com/barrel-db/rebar3_elixir_compile, it works well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJjx7Lrniye20XYH_mNIJfuvAFdptF7ks5stMgHgaJpZM4P7rPc> .

[tsloughter]

I'd be interested in following any work to plug in a different server, since in addition to Ace I'd like to see chatterbox supported.

[CrowdHailer]

@willemdj yes there is automatic flow control. Working under the assumption that the Elixir endpoint will not be overwhelmed by traffic sent to it.

I have an idea on how to expose connection information to each stream worker. But it seams wasteful for each stream to check the connection security. maybe there should be callbacks available at the connection level. It would be interesting to see a concrete usecase before picking a solution.

I would like to create a GRPC binding. Hopefully in the next month I will be able to carve out some time to focus on this.