There are use cases where invoking incoming-handler.handle may be desirable from within the guest, for example a Wasm HTTP server application consisting of 2 components:

1. Component A - listening and accepting connections via wasi:sockets, parsing the HTTP header (and optionally handling decryption if TLS is used) and passing the plaintext HTTP further down to the next component for processing
2. Component B - processing plaintext HTTP (wasi:http/incoming-handler implementation)

Component A would be able to correctly handle the connection, but would not be able to invoke wasi:http/incoming-handler.handle on Component B, because it would have no means to construct incoming-request required to be passed to the implementation. Moreover, even if the host would provide custom functionality to construct incoming-request, the guest (unlike in wasi:http/outgoing-handler.handle case) would not be able to asynchronously write the HTTP body bytes (and future trailers), since wasi:http/incoming-handler.handle signature is synchronous and calling it would block the guest

So the suggestion here is two-fold:

1. Define a constructor for incoming-request, or perhaps a better option would be introducing a unidirectional morphism mapping outgoing-request to incoming-request, e.g. something like into-incoming-request: static func(this: outgoing-request) -> incoming-request method defined on outgoing-request resource
2. Refactor wasi:http/incoming-handler.handle to return an asynchronous value, just like wasi:http/outgoing-handler.handle, which the caller can poll for. After taking a better look at the existing interface, this probably would not work or would not be desired. I suppose the "correct" solution here would be to define yet another "adapter" component, which would export wasi:http/outgoing-handler.handle and import wasi:http/incoming-handler.handle and would "convert" the outgoing request into an incoming one without modifying the body, such a solution would still depend on (1.), a solution to allow body streaming downstream is TBD for this case

Do note, that a simple solution to this problem would be simply not composing such an application from two components, but rather just have one component using wasi:sockets and handling HTTP directly without invoking wasi:http/incoming-handler - while true, this diminishes the value of this package, since the "component A" with the proposed structure could be a generic, reusable HTTP server component