[Iain, I'd really appreciate it if you'd copy me on your replies to my
posts. The volume is so high that I don't always get time to grovel
through the digests in a timely manner.]
On Sat, 30 Sep 2000, iain truskett wrote:
> * Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]:
> > 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.
Fair enough. Which is why I tried to indicate that these were my needs I
was stating.
> > 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 include opposing arguments? I'm not the one writing the RFC that Larry
sees. Do you have me confused with someone? I was just presenting my side
of the argument for the RFC author to notice (hopefully); it's up to him
to agree or disagree, and to include my side in the RFC or not.
> > > 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.
No, that's not what I was saying. I think the output headers should be
ordered, while the input can be ordered or unordered, with no preference.
If it's more useful for them to be ordered (for programs that rely on the
order, perhaps because they want to deal with the CGI or HTTP spec rather
than leaving that up to the web server), that's fine with me. However, in
that case, we can't use a(n untied) hash. A hash would be nice, because it
gives you random access and an easy way to query exists(); however, if
ordering is desired, some other method would have to be used. Which I'm
fine with.
> Don't take this the wrong way, but you are being hypocritical in your
> treatment of input and output headers.
Maybe you misunderstood me :). If not, please point out wherein you
believe my hypocrisy lies.
> > > > 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* am not giving you anything. I think you have me confused with the
author of the RFC again. I agree with you, though, that hashes are
unordered, and that if order is desirable, this interface is not very
useful.
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
