> 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.
> I'm thinking a $headers_in and a $headers_out type thing is needed where
> things are a Headers object that can either return a given header
> Flexible. Transparent. You could even tie things if you want, so things
> are slightly more transparent. Combine operator overloading with some of
> Damian's 'want' and Quantum::Superpositions stuff and things become
> rather interesting.
>
> 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.
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.
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.
-Nate
