Sunava Dutta wrote:
Inline...
- "add" semantics for setRequestHeader
- semantics for setRequestHeader(...,null)
- silent data loss for send() when DOM can't be serialized
- ...
I think only for the last one I have suggested that I rather not change it
based on that this seems like a safer choice. I have not seen any tests
that show that implementations actually throw in that case.
Which reminds me...
To Anne: ...speaking of which, I just showed that two days ago. As a
matter of fact, neither IE7 nor FF3 do what the spec say, they either
throw or send the non-wellformed document.
setRequestHeader() currently simply is broken. We should deprecate it,
and add new methods with well-defined semantics:
- removeHeader(...) (or specify set with null to mean remove)
- addHeader...
- getHeader...
"Deprecating" a method does not help implementations converge. Besides,
for typical usage there's no issue in using this header at all.
[Sunava Dutta] I agree with Anne here. Deprecating an existing implementations
and re-engineering XHR is something we just cannot accept. This spec should be
designed to reflect reality and seek interoperability for each and every single
section/method/event with at least one (I think the W3C mandates two?) existing
implementations. That does not mean the entire spec is aligned with FF or IE,
but it should be harmonious at any instance with one existing implementation.
The existing API sucks big time. It is not consistently implemented
anyway, and the way it is specified right now easily causes invalid HTTP
messages to be sent (for instance, including broken Content-Type headers).
Deprecate it, and come up with something that is good.
<sarcasm>I you're looking for an SDO to rubber stamp a bad thing, go to
ECMA or ISO :-)</sarcasm>
BR, Julian
