* Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]:
> On 28 Sep 2000, at 21:36, iain truskett wrote:
[....]
> > 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.
You accepted that output should be ordered, in case of new HTTP protocol
versions that may have a particular order requirement for headers.
Surely such a requirement of output headers would also be a requirement
for input headers? The order of them is just as important as the output
headers.
[...]
> 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.
For all your care, yes. Others may have different requirements, and
those requirements may change with new HTTP revisions.
> 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.
Again --- that's you. This RFC is for all of us. At the very least,
include the opposing arguments so that Larry can see that there were
multiple factions.
> > 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.
=) Objects are good (in some respects).
> > 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.
So you're saying that @HEADERS (the output one) can quite happily be
ordered (which it is by default) or unordered, erring on the side of
ordered; while on the other hand you're saying that %HTTP (input) may
not need to be ordered (just as it may need to be ordered), erring on
the side of unordered.
Don't take this the wrong way, but you are being hypocritical in your
treatment of input and output headers.
> > > 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".
But a %HTTP is the only variable you're giving us, which (by its nature)
is unordered.
I still free that objects are the way to go. At the very least both
array and hash variables should be exposed; ideally two scalars that are
object references.
cheers,
--
iain truskett, aka Koschei. <http://eh.org/~koschei/>
You know you are addicted to coffee if: 12 You don't sweat, you percolate.
