On Sun, Sep 24, 2000 at 11:16:46PM -0700, Nathan Wiger wrote:
> > Perl is frequently used in CGI environments. It should be as easy to write
> > CGI programs with perl as it is to write commandline text filters.
>
> First off, good idea, I do like this. Critiques:
>
> > Parse the CGI context, returning CGI variables into %CGI
>
> Which variables are you talking about? Everything you need is already in
> %ENV, as I'm sure you're aware.
>
> If you're talking about splitting up the query string, then this should
> be stated explicitly. And I think %CGI is a fine place for this. Will it
> be quotemeta'ed?
I'm thinking that whether the request came from a GET or a POST,
the un(HTTP)-escaped values will be in %CGI, just as CGI::params()
does.
That removes the ambiguity of query strings coming into %CGI, while
environment variables are shoved into %ENV (something rather obscure
by comparison).
> > Offer simple functions to set HTTP headers (e.g. content type, result codes)
>
> How about %HTTP, which is just flushed on the first line of output?
>
> use cgi;
> $HTTP{'Content-type'} = 'text/html';
> print "Hello!"; # flushes %HTTP first
>
> Just one idea.
HTTP headers is tricky. It's reasonably easy to figure out when
there are multiple form values in a request. It's less easy to
figure out when a program has finished emitting values for a
specific header type.
I think I'd prefer an exported function like:
http_header("Content-type" => "text/html");
http_header("Expires" => "+3 Days");
or whatever. Then it's an implementation issue to figure out
which headers are overridable, and which headers should appear
multiple times.
The idea of flushing on the first print call isn't too difficult
and kinda cool. That way, http_header() could flag a warning if
the user is trying to set a header after the header is done.
> The RFC should just be a little more specific on what's being included
> and not included. Are any of the functions like header(), h2(),
> footer()?
None of those. I'm preparing an update to make this stated more
explicitly.
Z.
