That is not CGI, nor is an embedded web server general-purpose.
Any server where you have control over the nature of the resources
back-end is not general-purpose.
The reason it doesn't make any sense to implement IPP via a CGI script
is because the server is being installed specifically to listen to IPP
requests on the IPP port, and thus doesn't need to deal with the
multifaceted heterogenerity of resources on a general-purpose HTTP server.
It therefore doesn't make sense to have an IPP implementation that is
generic among many servers (the ONLY reason to ever use CGI).
>running fine. I can think of many reasons why you'd want to base it on an
>existing web server, not the least of which is keeping the code size
>reasonable. I would imagine that most printer OEMs would do a lot of soul
>searching before deciding to use two separate instances of much the same
>code in a printer...
Your own implementation uses a server-specific API on a specific set
of pre-allocated printer resources within an embedded system. That is
exactly what I would expect of an IPP implementation, and there is no
reason why you can't support chunked requests. My point was that it is
silly to limit IPP capabilities to the lowest common denominator of
existing HTTP origin servers, since IPP isn't an existing HTTP service.
....Roy