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. :-)
> 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.
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.
> 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?
The more I think about it, I actually think we could ditch outgoing HTTP
headers altogether as "not our problem", at least not in core. After
all, outgoing data content is not our issue. Data parsing and formatting
is. If people need extensive header control, they can either write a
simple function, use Format, CGI, CGI_Lite, or any of the other
bizillion modules out there, or just say:
print "Content-type: text/html\n\n";
Which works just fine and is all you need for 90+% of applications.
> 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. After all, there are no builtins for providing
/etc/passwd formatting. I think we should provide robust input parsing,
but just general purpose output formatting tools.
-Nate
