Anne van Kesteren schrieb:
On Sun, 18 Feb 2007 11:46:49 +0100, Julian Reschke
<[EMAIL PROTECTED]> wrote:
Well, I'm asking because this spec is supposed to document existing
practice, right? Do we have reliable data about what the applications
really do here?
It does not document existing practice entirely. If it would do that
there wouldn't be much to specify since interoperability is poor at the
more finegrained level.
Also, there's not much reliable data about this.
The issue here is that even if we would have complete data on registered
headers, this doesn't help at all with non-registered headers and future
ones.
As currently implemented, setRequestHeader() is severely broken. The
caller of the API should be able to decide whether a header field is
appended, or the header is reset.
Both problems could be solved by
(1) deprecating setRequestHeader and add setRequestHeader2 (always
resetting the header) and addRequestHeader (always appending), or
(2) adding removeRequestHeader and potentially getRequestHeader.
If it's understood that none of the existing implementations is
compliant anyway, going for option (2) may make sense.
(I'm interested both in having existing behavior documented, but also
to have precise APIs for future implementations)
Right, me too. The problem is that you can't do both at the same time.
Sort of. That we can't change legacy implementations is true, but we
*can* describe how things should be done in future implementations. (Is
there a timeline for a revision that takes us there???)
Best regards, Julian
