On 28 Sep 2000, at 21:36, iain truskett wrote:
> * Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]:
> > On 27 Sep 2000, at 23:48, iain truskett wrote:
>
> > > So surely you'd want %HTTP (the input headers) to also be an array
> > > rather than a hash, since they'd be required in order as well?
>
> > I don't care, because I don't work with this much.
>
> It's a case of: if you're going to have the output order, then you
> should provide for the input to be ordered. *As well as* unordered.
Sorry, I don't follow your line of reasoning. Why should having the
output ordered influence what I want to see the input as? They're
two different things; the output is aimed for the HTTP user agent, and
the input is aimed (at the web server and then) for me. Two different
sets of requirements.
> > And I don't know whether I'd need to bear in mind the protocol which
> > requires the order; I'd probably want to access them randomly. But
> > that I send out has to follow the protocol.
>
> 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 want to order output headers because I have no control over
what's on the other end. The only fixed point of reference I have is
what the protocol specifies. So I want to stick to the protocol.
However, the protocol on incoming headers is mainly significant
between the HTTP user agent and the web server; once it gets to
me, I don't care about the protocol any more -- the web server took
care of that already. So the input headers can be unordered for all I
care.
Again, I don't do CGI much -- there may be people who want the
exact headers in the exact order. For me, knowing what the "User-
Agent:" header and what the "Accept-Charset:" header (or
whatever) say is sufficient, and I don't care whether one is before or
after the other.
> I'm thinking a $headers_in and a $headers_out type thing is needed
No comment on this one. Might be good, might not be; don't want to
evaluate it right now. I just didn't want to snip it.
> Having a %HTTP and a @HEADERS is rather simplistic and not really that
> accommodating for potential modifications to the protocols for HTTP and
> CGI.
Possibly true. However, I believe that headers will still follow the
"Key: Value" style, so @HEADERS should not be affected (if the
programmer has to specify the order, that is -- then she can still do
so in the future). And %HTTP may not need to be ordered.
> > In other words, the input has an order (the order in which the user-
> > agent sent the headers), but I'm not necessarily interested in it
> > (frequent CGI programmers may have different needs);
>
> Precisely. So theoretically, we should provide for both situations.
Well, if you provide it ordered, you *are* providing for both situations
-- those who want it ordered have it ordered, and those who don't
care about the order will be happy, too. After all, I didn't say "I
explicitly want it unordered" or "ordered according to the hash of
each header field".
Cheers,
Philip
