- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 18 Feb 2007 12:17:04 +0100
- To: Anne van Kesteren <annevk@opera.com>
- CC: public-webapi@w3.org
Anne van Kesteren schrieb: > On Sun, 18 Feb 2007 11:46:49 +0100, Julian Reschke > <julian.reschke@gmx.de> 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
Received on Sunday, 18 February 2007 11:17:11 UTC