> The item which is difficult to pass as an env. variable is the decoded
> query string. If we pass it as a single string separated by spaces, a
I think argv[2...] is enough, I don't think we need an env variable also.
I think what we should state is that if the resulting command line would
excede system maximuns (length or # arguments) then *NO* argv[2] is
passed and you must decode the URL yourself or punt. This is also
the case if there is no query string (then you check $SERVER_QUERY
or whatever it's called and if it's not set there is no query at all).
> On the command line, there should be two arguments:
I would restate that, even if you don't adopt the suggestion above
it's not true.
> argv[1] is always the path info, untouched. If there is no path info,
> this is "".
>
> argv[2....] is the decoded query info, split on spaces or ampersands.
You can't split on spaces, you mean pluses `+'. How do you decide
if it's spaces or ampersands? I assume if it has &'s then you split
on & else +, just need to make that clear.
> If the server does not use popen() or system(), and instead uses
> fork() and execl(), the command-line length limitation should not
> apply. I haven't verified this.
It does, it's a low-level problem with exec.
> The server should pass the header for the request as given by the
> client to the script as stdin. It should also, after the header, pass
> the client's data stream.
I assume this includes the ``GET /foobar HTTP/1.0'' part.
> Note that above, the server must know what content-type and
> content-length are in order to put them in environment variables.
> Should this be necessary, or should the server pass the entire header
> without touching it, and make the script pull content-type and
> content-length out?
I think the server must always touch the data so this isn't a problem,
the server will always have to relay the information. I don't see a clean
way around this because there is no way to read "just" the right amount
of information so you don't snarf in some of the headers or the data.
That would require length information *before* you read the request.
A smarter HTTP protocol would have a fixed size data header with this
information, but without it you can't do what you imply.
> *** The script's STDOUT
I need to look at all the plexus gateways and see what "callbacks" they
will require (the two you listed are the big ones).
--sanders