On Mon, Sep 25, 2000 at 09:34:41PM -0700, Nathan Wiger wrote:
> Adam Turoff wrote:
> > 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.
>
> Like this?
>
> $CGI{fullname} = 'Nathan Wiger';
> $CGI{creditcard} = '1234-1234-1234-1234';
>
> I'm 99% sure that's what you're saying. And I like it. :-)
Yes. More like $CGI{...} eq "...", since they're set from the CGI
environment. :-)
> One thing that %HTTP could be used for is _incoming_ headers - for
> example, 'If-Modified-Since', 'Set-Cookie', and others that a browser
> throws at you. These don't go in %ENV and wouldn't belong in %CGI.
Good point.
> > 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.
>
> For output, that's probably better. However, this is treading a line
> between a pragma and a lightweight module. :-{
>
> If it imports a function, then it's a module. Perhaps what we should
> look at doing is providing a lightweight CGI module instead?
That loses half of the intent, which is automagically turning on
tainting (before it's too late to turn it on) along with setting up
a Perl program to process CGI variables. Then taint mode needs
to be explictly turned off rather than turned on for the default
CGI program.
The http_header() is a straw man intended to demonstrate that there
are issues with shoving all of the outgoing HTTP headers into a simple
variable. Not insoluable problems, but problems.
I do like the idea of stacking HTTP headers and queueing them up
before the first print statement, where that print is a little
more magical than every subsequent print. I'd imagine that if the
HTTP headers were blank, it would Do The Right Thing (tm) and emit
a "Content-type: text/html\n\n", before replacing itself with the
standard print builtin.
And if HTTP headers are segregated from document content, it's
easier to determine when the headers are finished and when the
content starts. That aids in determining when '\n\n' is appropriate.
> > 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.
>
> Yeah, I think that would be cool, *if* we take care of this. But I think
> it's a slippery slope. [...]
OK, then draw a line in the sand where it's not so slippery. :-)
> I think we should provide robust input parsing,
> but just general purpose output formatting tools.
Robust input parsing: yes.
General purpose output formatting: no, nyet, nein, non, "over my dead body".
Rudimentary HTTP header emission: probably.
Z.
