I been lurking on this list but can offer some assistance here having
implemented a couple of network printers, a few HTTP servers (simple
ones, but HTTP servers nonetheless, including one inside a network
printer) and lots of CGI programs.
> Apparently there are a lot of books on HTTP.
I haven't seen many on HTTP. HTML yes, but that is something completely
different. The NCSA people have CGI documentation at their site,
> However, they have a lot of detail and it has been reported that it
> is hard to find out about HTTP servers and CGI scripts.
For HTTP there is the HTTP RFC and draft for HTTP/1.1 (is this an RFC yet?)
CGI is quite simple. The server runs an external program with various
environment variables set.
> The IPP project has agreed as a goal that the IPP protocol can be implemented
> in an HTTP server as a CGI script that interfaces with a printer or print
> system using whatever protocol that printer or print system supports so that
> no modifications have to be made to the HTTP server, except installing the
> CGI script.
CGI lets you do that. There may be a need to perform some simple HTTP server
configuration though to indicate that a particular name refers to a CGI
program. That of course is completely outside the domain the the PWG.
> Presumably you need a separate CGI script for each such printer or print
> system job submission protocol.
Not necessarially. It depends on how complicated you want to make the CGI
program. Such a program can be completely driven via parameters passed to
it that originate in the URL, e.g., the following URL,
could be interpreted as a request to use the IPP CGI program. In this
case there is an "argument" to the CGI program which results in the
PATH_INFO environment variable being set to "/printer-1". How PATH_INFO
gets interpretered is entirely up to the CGI program.
Another method of access is to use the QUERY_STRING environment variable
but that is primarially intended for use with forms but almost duplicates
what is possible with PATH_INFO.
> We want to prototype the IPP protocol as we develop it.
A wise move.
Although I won't quote them here several follow-ups to Tom's message
made mention of ISAPI. I haven't looked at it but from all accounts
it is quite straightforward. You should also consider the Apache
HTTP server and it's Fast CGI (another version of the ISAPI-style
server extension where the program runs in the same process as the
One query I did have however was just how much of HTTP is going to
be required by IPP? HTTP/1.1 can be quite a deal to implement in
certain devices (although if you've got a TCP/IP stack already
adding HTTP isn't all that bad I guess).
Andy Newman <andy at research.canon.com.au>