I concur ... POST is definitely preferred to GET.
POST provides the name=value pairs via stdin instead
of the command line, and another reason to use it is
that any given form can create a huge amount of data ...
so large, in fact, that the command line limit on
some systems can be exceeded. In the web-based DCS
I designed for Lockheed, I put a limit of 50,000
characters on the size of a value in a name=value pair
because for our CMM Level 4 work, we were exceeding
10,000 characters in a single value.
Richard Conn, ASE and PAL Manager
> -----Original Message-----
> From: Team Ada: Ada Advocacy Issues (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of Tucker Taft
> Sent: Monday, December 06, 1999 10:59 AM
> To: [log in to unmask]
> Subject: Re: Rational A.5 Command Line and HTML
> > ...
> > One major impediment to interfacing with HTML is in the package
> > Ada.Command_Line. The HTML statement,
> > <FORM method="Get" action="file:///C:\Ada_Work/com_line.exe"> is a
> > reasonable key to this problem. It produces a Command_Line
> string and does
> > invoke the com_line program shown below. Unfortunately,
> > Command_Line.Argument_Count does not work with the Command_Line string.
> > The Get method concatenates a '?' directly after the program name.
> I'm not exactly sure what is your point, but the FORM information
> for a GET
> method is being put into the environment variables (e.g. QUERY_STRING).
> There is no language-defined standard way to get the values of
> the environment
> variables, though the Posix/Ada standard provides a way to access them
> (as does Win32/Ada, presumably). Note that by the time the Ada program
> is invoked, the "?" has already been stripped out, and
> the URL request information placed in the environment variables.
> The only time command line arguments are used is with the "ISINDEX"
> tag, and then only if there is no "=" used after the "?" of the URL.
> Since the URL produced by a GET always contain an "=", the command
> line arguments are never used with GET. The "?" is used in the
> URL, but the
> URL is broken apart by the web server (or whatever is
> interpreting the URL).
> As suggested by others, by using the POST rather than the GET
> method, the information from the FORM will be sent via
> standard input, rather than via the QUERY_STRING environment variable. I
> recommend you try that approach. (I see no reason that POST should not
> work just as well as GET on a local file URL.)
> > ...
> > However, the program does run when actuated through the HTML
> form; with the
> > number of arguments equal to 0.
> > C:\Ada_Work\com_line.exe equals the Command_Line
> > This Program is Com_Line
> > The number of arguments = 0
> Take a look at the QUERY_STRING environment variable.
> > ...
> > The question is which operating system, Windows or HTTP? The
> above problem
> > is neither a bug nor a design mistake. It is correct for its
> intended use,
> > Windows. However, it does not work with HTTP. I do believe in
> hindsight that
> > a function that returns the entire command_line including the
> program name
> > should be added.
> That would not solve your problem. By the time the program is invoked,
> the notion of a URL string is long gone. It has been picked
> apart and dumped
> into the environment variables.
> > ... In view of the significance of HTML-XML, I believe that it
> > would be worthwhile to modify the Aonix Command_Line or any other Ada
> > compiler to work with the output of HTML Get.
> > Can any of the Ada compilers read and process a command_line
> that does NOT
> > have a space after the name of the executable? If you wish to test this,
> > please feel fee to use the Ada program and HTML page below.
> This issue is a red herring. The syntax used by the DOS shell is
> different from the syntax used in a CGI URL. By the time a program
> is invoked, it does not know whether it was invoked by the DOS shell
> or via CGI. All it can look at are "argc, argv" and the
> environment variables.
> I suppose you could suggest that if there are no other arguments,
> then the QUERY_STRING environment variable ought to be treated like
> the first and only parameter. But that definitely seems like
> a kludge. The better approach is to agree on a common interface
> to environment variables. Posix/Ada is an obvious place to
> start, though we might want to define an Ada.Command_Line.Environment
> child package some day.
> > ----------------------------------------------------------
> > --Robert C. Leif, Ph.D & Ada_Med
> > --2 Dec. 1999
> > --Last update 3 Dec. 1999