1. File transfer, client->server; 2. Problem with popen in CGI script.

Errors-To: listmaster@www0.cern.ch
Date: Sat, 30 Apr 1994 21:36:38 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <"30-Apr-94 12:33:04 PDT".*.Ernesto_Nebel.sd@Xerox.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: Ernesto_Nebel.sd@xerox.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Ernesto_Nebel.sd@xerox.com
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: 1. File transfer, client->server; 2. Problem with popen in CGI script.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas


1.) I'm quite new at this, but I assume either a CGI script or a client side
program can be written to transfer any file from the client to the server
executing only HTTP commands.  Is this correct?  Are there any plans to build
this capability into HTML servers and browsers?  I'm thinking of business
applications in which the server (a business) wants to receive documents
electronically from clients running HTML browsers on a variety of platforms.
Has this been discussed here before?

2.) I've run into a problem when executing a "popen" command from a CGI script.
In some cases, the client does not see the response created by the CGI script.
Instead, he is asked to store it as a file on his machine.  See the details
below if you're interested and you care to comment and help.

Thank you.


Problem with popen:
I'm using NCSA httpd 1.1 and NCSA Mosaic-2.2a on a Sun Sparcstation 1 with
SunOS 4.1.2.

I have a simple CGI script written in C that executes an "ftp" command to get a
file from a client-specified machine to the server machine.  The script is
executed as a result of submitting a form with method POST.  The relevant code
(without error checking) is:

   printf("Content-type: text/html%c%c",10,10);
   printf("<H1>FTP request:</H1>");
   ftpcom  = (char *) malloc(20);  /* allocate string for ftp command */
   sprintf(ftpcom, "ftp %s", machinename);  /* put ftp command in string */
   fp = popen(ftpcom, "w");       /* send ftp command */
   fprintf(fp, "%s%c", username, 10);  /* login at remote machine, under ftp */
   fprintf(fp, "%s%c", password, 10);  /* 10 is a newline character */
   fprintf(fp, "cd %s%c", directory, 10); /* go to correct directory */
   fprintf(fp, "get %s /tmp/%s%c", filename, filename, 10); /* get file */
   fprintf(fp, "quit%c", 10); /* quit ftp */
   pclose(fp);  /* close pipe */
   printf("Command:  %s  was executed<p>%c", ftpcom, 10); /* tell client ftp
done */

(You can substitute every "%c" with a "\n" and eliminate every ",10", with the
same results.)

The code executes fine: the file is retrieved to the server.  However, the
client does NOT see the response created by the CGI script in his/her Mosaic
browser.  Of course, (s)he is supposed to see:

FTP request:
Command:  ftp bomb  was executed

INSTEAD, the client sees a window pop up: "NCSA Mosaic: Save Binary File to
Local Disk", and (s)he is asked to specify a path and file name.  The file that
gets retrieved is the HTML document that is supposed to be the response.  It

<H1>FTP request:</H1>Command:  %s  was executed<p>

If I delete every "%c" and ",10" from the code above, the user DOES see the
response appear in his/her Mosaic browser, but of course, the ftp command
fails.  Other commands that do not require additional input, like "lpr",
execute fine and the client gets a correct response.  For example:

   printcom = (char *) malloc(40);
   sprintf(printcom, "/usr/ucb/lpr -P%s /tmp/%s", printername, filename);
   fp2 = popen(printcom, "r");
   printf("Command:  %s  was executed<p>%c", printcom, 10);

This causes no problems.  So the only thing that makes the CGI response to the
client fail is the newline character in the "fprintf(fp, "...\n",...);"

I've also tried using: "printf("Location:..." instead of
"printf("Content-type:" at the top of the CGI script, with exactly the same

Is this a bug in httpd?  In Mosaic?  Has anybody seen this before?

Thank you in advance.

Ernesto Nebel
XSoft, a Xerox Division
San Diego, CA,  USA