H. G. Muller wrote on Tue, Oct 9, 2018 09:05 AM UTC:
Progress: as I expected the webserver (lighttpd) is configured by default to only execute CGI programs when they are in the cgi-bin directory. But it was also configured to alias any URL that contained this directory name to /usr/bin/perl , which is apparently where gitweb lives. This must have happened as part of installing gitweb (which in some earlier version must have been a true .cgi file, but now apparently is something entirely different). So anything inside the real cgi-bin directory was inaccessible, web-access to the directory being diverted to gitweb.
I now configured lighttpd also to allow cgi execution in a new directory 'my-cgi', and a little test program that prints Content-type: text/html plus 'Hello World!' as HTML header, placed in this directory, shows the properly formatted message. So it seems I am back in business, and can now use compiled C programs as CGI, on a machine where I can be root.
test 2: printing "Content-type: image/png" and then copying an existing PGN file to stdout shows that image in the browser for the CGI's URL.
test3: I managed to instal libcairo, the (raster-image) drawing library used by XBoard. (Alas non-trivial, because the Ubuntu running on my VPS was no longer supported, and I had to reconfigure apt-get to be able to install the package from another source.) I could compile a test program that reads a PNG image into a memory bitmap, and then writes that memory bitmap to stdout as PNG. And running it as CGI indeed displays the image in the browser.
test4: This one drove me to despair again. I managed to install librsvg-2, and find the required include and library arguments for compiling. The rsvg functions that were supposed to give me ponters to 'RsvgHandles' kept returning NULL, however, but did not return an error either. I finally solved it by first calling rsvg_init(), a function that according to the librsvg manual does nothing, is deprecated, and should not be used in new code. Apparently my librsvg is so much older than the online manual, that the info in it does not apply. Strange thing is that XBoard works without calling rsvg_init(), even when I compile it for the same Ubuntu version. But it makes calls to libcairo before it invokes librsvg, and perhaps the (equally obsolete) libcairo calls rsvg_init() without me knowing it. Anyway, it works now: the CGI program reads the requested SVG image file into a buffer, and then uses rsvg_handle_new_from_data to convert this data (which at that point was still the exact file contents) to an RsvgHandle. (I took that detour, because the direct route through rsvg_handle_new_from_file() with which I started also gave me errorless NULL pointers, and I wanted to make sure that it wasn't due to inability to access the file. But I had planned to do it through the detour anyway, to get an opportunity to change the colors before rendering.)
test5: I now implemented color changing by replacing all occurences of "#ffffcc" (the default filling color of the XBoard white pieces) by the c=... CGI argument. For now, only hexadecimal RGB codes are accepted as values; it is read as an int through a "%x" format.
Mission accomplished! You can right-click on the images to see how the URL for them looks (under 'image info'). Apart from the c (color), s (size) and p (name of the SVG file without extension) there is a d (directory) argument that can be used to select another piece set.
Progress: as I expected the webserver (lighttpd) is configured by default to only execute CGI programs when they are in the cgi-bin directory. But it was also configured to alias any URL that contained this directory name to /usr/bin/perl , which is apparently where gitweb lives. This must have happened as part of installing gitweb (which in some earlier version must have been a true .cgi file, but now apparently is something entirely different). So anything inside the real cgi-bin directory was inaccessible, web-access to the directory being diverted to gitweb.
I now configured lighttpd also to allow cgi execution in a new directory 'my-cgi', and a little test program that prints Content-type: text/html plus 'Hello World!' as HTML header, placed in this directory, shows the properly formatted message. So it seems I am back in business, and can now use compiled C programs as CGI, on a machine where I can be root.
test 2: printing "Content-type: image/png" and then copying an existing PGN file to stdout shows that image in the browser for the CGI's URL.
test3: I managed to instal libcairo, the (raster-image) drawing library used by XBoard. (Alas non-trivial, because the Ubuntu running on my VPS was no longer supported, and I had to reconfigure apt-get to be able to install the package from another source.) I could compile a test program that reads a PNG image into a memory bitmap, and then writes that memory bitmap to stdout as PNG. And running it as CGI indeed displays the image in the browser.
test4: This one drove me to despair again. I managed to install librsvg-2, and find the required include and library arguments for compiling. The rsvg functions that were supposed to give me ponters to 'RsvgHandles' kept returning NULL, however, but did not return an error either. I finally solved it by first calling rsvg_init(), a function that according to the librsvg manual does nothing, is deprecated, and should not be used in new code. Apparently my librsvg is so much older than the online manual, that the info in it does not apply. Strange thing is that XBoard works without calling rsvg_init(), even when I compile it for the same Ubuntu version. But it makes calls to libcairo before it invokes librsvg, and perhaps the (equally obsolete) libcairo calls rsvg_init() without me knowing it. Anyway, it works now: the CGI program reads the requested SVG image file into a buffer, and then uses rsvg_handle_new_from_data to convert this data (which at that point was still the exact file contents) to an RsvgHandle. (I took that detour, because the direct route through rsvg_handle_new_from_file() with which I started also gave me errorless NULL pointers, and I wanted to make sure that it wasn't due to inability to access the file. But I had planned to do it through the detour anyway, to get an opportunity to change the colors before rendering.)
test5: I now implemented color changing by replacing all occurences of "#ffffcc" (the default filling color of the XBoard white pieces) by the c=... CGI argument. For now, only hexadecimal RGB codes are accepted as values; it is read as an int through a "%x" format.
Mission accomplished! You can right-click on the images to see how the URL for them looks (under 'image info'). Apart from the c (color), s (size) and p (name of the SVG file without extension) there is a d (directory) argument that can be used to select another piece set.