mod_http2 exported functions

[Christian Schoenebeck <ap...@crudebyte.com>]

Hi everyone,

I was just looking at the mod_http2 sources, and wondered why are only the 
following few functions of mod_http2 exposed to the outer world?

	APR_REGISTER_OPTIONAL_FN(http2_is_h2);
	APR_REGISTER_OPTIONAL_FN(http2_var_lookup);
	APR_REGISTER_OPTIONAL_FN(http2_req_engine_push);
	APR_REGISTER_OPTIONAL_FN(http2_req_engine_pull);
	APR_REGISTER_OPTIONAL_FN(http2_req_engine_done);
	APR_REGISTER_OPTIONAL_FN(http2_get_num_workers);

I was expecting to see some more functions being publicly accessible, 
especially for creating new h2 streams programmatically by other modules. Is 
there a reason why those functions are not exported?

The reason for asking: I was considering to make some of the core h2 features 
available through Python or PHP i.e. for dynamically creating server pushes in 
webapps (beyond of what's currently possible with adding link headers). I know 
that such a use case is against what http2 is commonly advertised for, but 
having h2 features directly available on webapp level, would significantly 
reduce complexity and development time for a large scale of web apps.

Best regards,
Christian Schoenebeck

Re: mod_http2 exported functions

[Christian Schoenebeck <ap...@crudebyte.com>]

On Dienstag, 20. März 2018 13:26:49 CEST Christian Schoenebeck wrote:
> In order to be able to leverage h2 features like this, it would be necessary
> to export certain mod_http2 functions to other modules, such that a server
> side webapp script could at least i.e.
> 
> 1.  Programmatically create additional h2 streams.
> 2.  Send data on a specific h2 stream.
> 3.  Register a callback function for receiving incoming data on individual
> h2 streams (or at least a way to poll them).
> 4.  Alter h2 priorities for individual streams.
> 5.  Register a callback function for being informed about additional streams
> being created by the client (or at least a way to poll this).

So, any chance on the mid-term for getting public functions in mod_http2 for 
some of these? Doubts?

Best regards,
Christian Schoenebeck

Re: mod_http2 exported functions

[Christian Schoenebeck <ap...@crudebyte.com>]

On Dienstag, 20. März 2018 09:43:45 CET Stefan Eissing wrote:
> Hey,

Hi Stefan, thanks for your kind reply on this one!

> > The reason for asking: I was considering to make some of the core h2
> > features available through Python or PHP i.e. for dynamically creating
> > server pushes in webapps (beyond of what's currently possible with adding
> > link headers). I know that such a use case is against what http2 is
> > commonly advertised for, but having h2 features directly available on
> > webapp level, would significantly reduce complexity and development time
> > for a large scale of web apps.
> If you can describe how you want to use it and what the benefit is, let's
> hear it. Maybe there are mechanisms already present in the server that can
> fullfill parts of what you want.

Sure! Currently, due to the nature of http1.x you have to implement web apps 
following always the singular request-response principle. But that's against 
what many webapp designs nowadays require, even very small and simple ones.

In practice webapps would often need several continuous streams between each 
client instance and server; for example one stream for sending sequential, 
basic requests to the server, and receiving the server's responses upon those 
sequential requests. Then another, separate stream for receiving just in time 
events from server to client without forcing the client to poll such events. 
Then a bunch of other streams for i.e. loading large (dynamically rendered) 
resources from the server in the background (i.e. graphical charts).

Implementing such webapps with http1.x requires a large overhead of both 
webapp code, as well as performance penalty, because for all these individual 
tasks of one client instance, the client has to make completely separate 
http1.x requests, then the server has to perform the same session validation 
steps over and over again for each single request, then you have to add a 
persistency layer on server side to synchronize the individual http1.x 
requests and make them act like one, single session, then you have to add 
cleanup handlers to get rid of temporarily saved session resources after a 
certain time out, and so on.

With h2 on the other hand I see a large potential to finally get rid of all 
those described technical obstacles and their involved development, 
performance and resource overhead and security issues.

So the basic idea was, how about spawning just one instance of an i.e. Python 
or PHP script for each client instance, and that single script instance would 
do it all, thus one webapp script instance would be exactly the session. So a 
new client would establish exactly one h2 connection to the server and keep it 
alive for all its required sequential requests and responses. Right after that 
the server side script would create addtional h2 streams on that h2 connection 
i.e. for pushing just in time events, or for providing requested resources in 
the background (probably with lower stream priority to not interfere with high 
priority event delivery). The server would thus only need to perform session 
validation tasks once; exactly when the client establishes the h2 connection. 
And for small web apps you would not even need a persistency layer anymore, 
because most (if not all) session data could entirely be stored in RAM by the 
respective script instance.

In order to be able to leverage h2 features like this, it would be necessary 
to export certain mod_http2 functions to other modules, such that a server 
side webapp script could at least i.e.

1.  Programmatically create additional h2 streams.
2.  Send data on a specific h2 stream.
3.  Register a callback function for receiving incoming data on individual h2 
streams (or at least a way to poll them).
4.  Alter h2 priorities for individual streams.
5.  Register a callback function for being informed about additional streams 
being created by the client (or at least a way to poll this).

Best regards,
Christian Schoenebeck

Re: mod_http2 exported functions

[Stefan Eissing <st...@greenbytes.de>]

Hey,

> Am 19.03.2018 um 17:46 schrieb Christian Schoenebeck <ap...@crudebyte.com>:
> 
> Hi everyone,
> 
> I was just looking at the mod_http2 sources, and wondered why are only the 
> following few functions of mod_http2 exposed to the outer world?

So far, only the functions for interworking with httpd core and mod_proxy_http2
were exposed. There is no API for other modules to start streams etc. as you
mentioned below.

> 	APR_REGISTER_OPTIONAL_FN(http2_is_h2);
> 	APR_REGISTER_OPTIONAL_FN(http2_var_lookup);
> 	APR_REGISTER_OPTIONAL_FN(http2_req_engine_push);
> 	APR_REGISTER_OPTIONAL_FN(http2_req_engine_pull);
> 	APR_REGISTER_OPTIONAL_FN(http2_req_engine_done);
> 	APR_REGISTER_OPTIONAL_FN(http2_get_num_workers);
> 
> I was expecting to see some more functions being publicly accessible, 
> especially for creating new h2 streams programmatically by other modules. Is 
> there a reason why those functions are not exported?

Yes, because the functionality is not ready to be exposed and it is not
clear to me what that would exactly do. My lack of imagination maybe... ;-)

> The reason for asking: I was considering to make some of the core h2 features 
> available through Python or PHP i.e. for dynamically creating server pushes in 
> webapps (beyond of what's currently possible with adding link headers). I know 
> that such a use case is against what http2 is commonly advertised for, but 
> having h2 features directly available on webapp level, would significantly 
> reduce complexity and development time for a large scale of web apps.

If you can describe how you want to use it and what the benefit is, let's
hear it. Maybe there are mechanisms already present in the server that can
fullfill parts of what you want.

Cheers,

Stefan

> 
> Best regards,
> Christian Schoenebeck