* Nathan Wiger ([EMAIL PROTECTED]) [29 Sep 2000 02:14]:
> > A future protocol could well require things in order. Hence you're
> > having the output headers in order. Therefore you should have the
> > input ones available in order as well.
> I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't
> both be supported.
Neither can I =)
[...]
> > Having a %HTTP and a @HEADERS is rather simplistic and not really
> > that accommodating for potential modifications to the protocols for
> > HTTP and CGI.
> I'm not sure I agree. The goal is to make this stuff easy for the
> majority of cases. We're certainly not going to get everybody's needs
> with this simple pragma.
Indeed not. In some cases, not even our basic needs.
> The idea is to make it so "use cgi" lets you write a simple CGI
> script. One that can fluidly parse every header and is fully
> extensible per the newest HTTP/6.73 spec? Nope, then it's module time.
Such as good ol' CGI.pm, or the appropriate mod_perl module. I'm still
failing to see the point of most of this RFC. It doesn't really appear
to do anything that isn't done better elsewhere and I'm on the school of
thought "If you have good stuff, then don't add not-so-good stuff".
> Stuff that's in the core should be building blocks off of which other
> stuff can be based. Providing @HTTP and %CGI is great, because then
> modules can just "use cgi" and parse those thing up, without having to
> read from STDIN and do all the GET/POST special stuff.
Or they can just grab stuff using CGI.pm...
Or someone could split CGI.pm up so that there's CGI::FormValues and
CGI::HTTPHeaders.
cheers,
--
iain truskett, aka Koschei. <http://eh.org/~koschei/>
A library is a hospital for the mind. Anonymous
