Re: XHR LC comments

Anne van Kesteren wrote:
> On Sat, 17 May 2008 14:23:24 +0200, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> Anne van Kesteren wrote:
>>> On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke 
>>> <julian.reschke@gmx.de> wrote:
>>>> But what IMHO happens all over again is that strange choices in the 
>>>> design are defended with the statement "this is what the vendors do, 
>>>> or want to do", and when we check it, that turns out to be incorrect.
>>>  Could you point out one such example? I've actually tested a fair 
>>> amount
>>
>> They are in the current threads.
>>
>> - "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.

Data loss is not a "safe" choice, it's a bad choice.

Do you have any evidence of deployed code that would break if this would 
throw?

 > ...
>> 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.

Currently there is no conversion, and what is specified clearly can 
cause implementations to create broken requests, where the code worked 
before.

The semantics has always been broken (as compared, for instance, the 
equivalent methods in the servlet spec). The sanest way out of this is 
to deprecate the existing method, and to define new methods with sane 
semantics.

BR, Julian

Received on Saturday, 17 May 2008 12:51:37 UTC