From the start of the development of Iroha 2, we tried to limit the number of dependencies in order to ensure higher security. With the acceptance of Maintenance Endpoint RFC, the work on the implementation of HTTP and Web Socket API has been started. Taking into account the size of the team and the time constraints it seems reasonable to use already existing libraries for both of the selected protocols (HTTP, WebSocket), and therefore add these dependencies to Iroha 2. This RFC discusses the possibility of introducing these dependencies and the selection of these libraries if they are decided to be added.
...
It is suggested to use external libraries for both of these protocols. The pros and cons of this decision are shown below
Pros
Cons
Saves development time and it is important because:
The team is rather small and with the use of libraries will be able to focus more on Iroha specific tasks
The deadline for the MVP is soon
Both protocols are heavily standardized and libraries have to follow these standards, making their
behavior
behaviour predictable and secure
Addition of many external dependencies introduces potential security holes of which our team is not aware
Requirements for Libraries
These are the high-level requirements that seem reasonable to propose for libraries that we will use:
Async I/O - as Iroha2 is heavily async and relies on executors for low-level thread management.
Relatively A relatively small number of new dependencies - as new dependencies introduce potential security risks.
Library rather than framework - as Iroha2 has already a rather specific structure and should not change its style to fit the framework.
It should be possible to upgrade HTTP connection from http HTTP library with WebSocket
Free open license
HTTP 1.1 support - as Substrate offchain workers do not support HTTP 2
Recognizes URL patterns with support for dynamic and glob segments. Can be easily replaced with our custom solution later. Used to speed up the development process. Also doesn't have any dependencies.
The usage of these libraries would, in general, mean that we will implement our own web server based on TCP streams, but the messages will be parsed with the help of http HTTP library. When the upgrade request for web socket will be received, then the connection management manager will be passed to async-tangstenite tungstenite library.
Does not support parsing from streams or raw bytes, which is a functionality that we might spend a lot of time writing if it is not supported out of the box.
The crate http-service provides the necessary types and traits to implement your own HTTP Server.
The crate mainly provides the interface for the servers to implement the same methods, it might be good for architecture in general, but it is an additional dependency and our priority is to only add absolutely necessary ones.