Re: XHR LC comments

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

Received on Monday, 19 May 2008 19:51:26 UTC