cgserv (that's short for captchaserv) works like a web server and gives you a cool image in response to an http request that includes the word that will be contained in the image -- right?
Right.
the sg webserver would figure out what word it wants to use, then use lwp or something to make the request to cgserv and get the image -- it would then make up a name for the image file, save it on the webserver, and present it to the user as part of the sign-up page? That is, the user page image tag-url will go to a real image file on the spamgourmet webserver rather than to the cgserv url?
Yep, that's the principle. The captchaserv directory even has a file with a couple of perl routines to help pick the word.
My first reaction when I read your message was to think "Wait, why do we have that intermediate stage? Why do we have to slurp the captcha from cgserv to the web server instead of just putting the cgserv URL on the user registration page?" Well duh, of course: because right now, the cgserv URL contains the captcha word. Some security.
So with the current scheme, we have that intermediate stage (the captcha copied from cgserv to web server) which is a useless burden. Why not suppress it? Here is what I suggest. I modify the captchasrv code so that it makes up a random captcha file name and saves the captcha to that file. Then it returns the name of the file -- just the name -- to the caller on spruce.
Since the machine on which cgserv runs (gourmet) has its own HTTP server, all you now have to do to show that image to the user is to put the captcha URL (with the random name) in an image tag in the user registration page. Of course, cgserv has to put the captcha image in a web-accessible dir, clean up old images, etc. All things that would have to be coded on spruce in the current scheme anyway.
This would save some CPU and bandwidth.
Shall I do it?