Re: setRequestHeader / Accept

[Jonas Sicking]

Julian Reschke wrote:


Anne van Kesteren wrote:

...
We shouldn't let what webidl says dictate what we do one way or the 
other. It's just a spec for the idl language, not a recommendation 
for how interfaces should behave.


null/undefined are not really part of the setRequestHeader() method. 
We just need to deal with them somehow and doing what similar APIs do 
in such cases makes sense.

...


Such as xhr.send(null)?


Yes, xhr.send(null) will send an empty body rather than one containing 
"null".


/ Jonas

Re: setRequestHeader / Accept

[Julian Reschke]

Anne van Kesteren wrote:

...
We shouldn't let what webidl says dictate what we do one way or the 
other. It's just a spec for the idl language, not a recommendation for 
how interfaces should behave.


null/undefined are not really part of the setRequestHeader() method. We 
just need to deal with them somehow and doing what similar APIs do in 
such cases makes sense.

...


Such as xhr.send(null)?

(Ducks)

BR, Julian

Re: setRequestHeader / Accept

[Jonas Sicking]

Anne van Kesteren wrote:


On Sun, 25 May 2008 20:40:48 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Agreed. We have in the past said that in the cases where it doesn't 
seem like the web is depending on a certain behavior one way or the 
other do what is most useful. I don't really think it matters much if 
null is treated as 'remove' or as 'do nothing', but appending 'null' 
seems pretty useless in pretty much all cases.


It's pretty common behavior for a lot of APIs though Firefox seems to do 
it differently from everyone else quite often if I remember correctly.


Yes, we never convert null to "null" since per spec null is a valid 
DOMString, so there should be no need to convert it at all.


We shouldn't let what webidl says dictate what we do one way or the 
other. It's just a spec for the idl language, not a recommendation for 
how interfaces should behave.


null/undefined are not really part of the setRequestHeader() method. We 
just need to deal with them somehow and doing what similar APIs do in 
such cases makes sense.


Agreed, but I think defining them to turn null into "null" is a weird 
given that we can just leave it as null. If we should turn it into 
anything it should be the empty string as that seems to me as what makes 
sense.


FWIW I think the webidl spec should be changed here, but i'll raise 
that in a thread for that spec.


I think it makes sense for Web IDL to specify the most common behavior 
as default.


Agreed, but I think we disagree on what "most common behaviour" is :)

/ Jonas

Re: setRequestHeader / Accept

[Bjoern Hoehrmann]

* Maciej Stachowiak wrote:
>Using XHR with non-JavaScript programming languages seems pretty  
>unlikely.

http://www.google.com/codesearch?q=-lang%3Ajavascript+IXMLHTTPRequest
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: setRequestHeader / Accept

[Julian Reschke]

Maciej Stachowiak wrote:
Treating null as empty string here may be sensible (no strong opinion 
either way) but removing the header when set to empty seems wrong. If 
header removal is really essential we should add a method for it.


In HTTP, absence of a header is different from having an empty value.

I can understand the argument that set(..., null) is the wrong way to 
remove a value. But if it doesn't, it shouldn't do anything that a 
non-null argument would do.


So yes, an explicit way to remove an header would be good. Otherwise 
we'll see broken requests on the wire (as just seen in the example I 
cited a few days ago).


BR, Julian

Re: setRequestHeader / Accept

[Julian Reschke]

Anne van Kesteren wrote:
Or are you claiming that people who set a header to null *really* want 
the specified behaviour?


It's consistent with other JavaScript APIs were null also means "null".

Overloading this API to also do removal of the header is not a goal here 
and is simply a bug in Firefox as it also does that for the empty string 
value (Firefox simply treats null identically to the empty string, where 
other browsers treat it identically to "null".


If you don't want to specify removal, then make it either undefined 
behavior, or specify that an exception must be thrown.


It's all better than to let something on the wire that the caller of the 
API didn't want there in the first place.


BR, Julian

Re: setRequestHeader / Accept

[Maciej Stachowiak]

On May 25, 2008, at 3:19 PM, Anne van Kesteren wrote:



On Sun, 25 May 2008 18:04:14 +0200, Julian Reschke <[EMAIL PROTECTED] 
> wrote:
Apparently existing content does not rely on it (FF gets away with  
implementing something that IMHO makes *much* more sense). So why  
standardize it at all, or, when doing so, select something that  
doesn't make sense in practice?


Or are you claiming that people who set a header to null *really*  
want the specified behaviour?


It's consistent with other JavaScript APIs were null also means  
"null".


Overloading this API to also do removal of the header is not a goal  
here and is simply a bug in Firefox as it also does that for the  
empty string value (Firefox simply treats null identically to the  
empty string, where other browsers treat it identically to "null".


Treating null as empty string here may be sensible (no strong opinion  
either way) but removing the header when set to empty seems wrong. If  
header removal is really essential we should add a method for it.


Regards,
Maciej

Re: setRequestHeader / Accept

[Maciej Stachowiak]

On May 25, 2008, at 11:40 AM, Jonas Sicking wrote:



Julian Reschke wrote:

Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke <[EMAIL PROTECTED] 
> wrote:

Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari  
are conformant here. (null and undefined are simply stringified.)


Not terrible useful, I would say. Is that something we have to  
live with because of the IDL definition???


It matches two implementations and is the default behavior for  
null/undefined when passed to something that accepts a string.
Apparently existing content does not rely on it (FF gets away with  
implementing something that IMHO makes *much* more sense). So why  
standardize it at all, or, when doing so, select something that  
doesn't make sense in practice?
Or are you claiming that people who set a header to null *really*  
want the specified behaviour?


Agreed. We have in the past said that in the cases where it doesn't  
seem like the web is depending on a certain behavior one way or the  
other do what is most useful. I don't really think it matters much  
if null is treated as 'remove' or as 'do nothing', but appending  
'null' seems pretty useless in pretty much all cases.


We shouldn't let what webidl says dictate what we do one way or the  
other. It's just a spec for the idl language, not a recommendation  
for how interfaces should behave.


Web IDL can be used to specify all sorts of different behaviors for  
null and undefined. Its default setting is not really materially  
relevant. To change the spec behavior we would just have to change the  
IDL in the XHR spec.


I agree it is unlikely that content deeply depends on behavior for  
null or undefined, but it might be worth doing some testing to  
quantify this.


Regards,
Maciej

Re: setRequestHeader / Accept

[Anne van Kesteren]

On Sun, 25 May 2008 20:40:48 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Agreed. We have in the past said that in the cases where it doesn't seem  
like the web is depending on a certain behavior one way or the other do  
what is most useful. I don't really think it matters much if null is  
treated as 'remove' or as 'do nothing', but appending 'null' seems  
pretty useless in pretty much all cases.


It's pretty common behavior for a lot of APIs though Firefox seems to do  
it differently from everyone else quite often if I remember correctly.



We shouldn't let what webidl says dictate what we do one way or the  
other. It's just a spec for the idl language, not a recommendation for  
how interfaces should behave.


null/undefined are not really part of the setRequestHeader() method. We  
just need to deal with them somehow and doing what similar APIs do in such  
cases makes sense.



FWIW I think the webidl spec should be changed here, but i'll raise that  
in a thread for that spec.


I think it makes sense for Web IDL to specify the most common behavior as  
default.



--
Anne van Kesteren

Re: setRequestHeader / Accept

[Anne van Kesteren]

On Sun, 25 May 2008 18:04:14 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:
Apparently existing content does not rely on it (FF gets away with  
implementing something that IMHO makes *much* more sense). So why  
standardize it at all, or, when doing so, select something that doesn't  
make sense in practice?


Or are you claiming that people who set a header to null *really* want  
the specified behaviour?


It's consistent with other JavaScript APIs were null also means "null".

Overloading this API to also do removal of the header is not a goal here  
and is simply a bug in Firefox as it also does that for the empty string  
value (Firefox simply treats null identically to the empty string, where  
other browsers treat it identically to "null".



--
Anne van Kesteren

Re: setRequestHeader / Accept

[Jonas Sicking]

Julian Reschke wrote:


Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke 
<[EMAIL PROTECTED]> wrote:

Anne van Kesteren wrote:
 Per the updated specification which uses Web IDL IE and Safari are 
conformant here. (null and undefined are simply stringified.)


Not terrible useful, I would say. Is that something we have to live 
with because of the IDL definition???


It matches two implementations and is the default behavior for 
null/undefined when passed to something that accepts a string.


Apparently existing content does not rely on it (FF gets away with 
implementing something that IMHO makes *much* more sense). So why 
standardize it at all, or, when doing so, select something that doesn't 
make sense in practice?


Or are you claiming that people who set a header to null *really* want 
the specified behaviour?


Agreed. We have in the past said that in the cases where it doesn't seem 
like the web is depending on a certain behavior one way or the other do 
what is most useful. I don't really think it matters much if null is 
treated as 'remove' or as 'do nothing', but appending 'null' seems 
pretty useless in pretty much all cases.


We shouldn't let what webidl says dictate what we do one way or the 
other. It's just a spec for the idl language, not a recommendation for 
how interfaces should behave.


FWIW I think the webidl spec should be changed here, but i'll raise that 
in a thread for that spec.


/ Jonas

Re: setRequestHeader / Accept

[Julian Reschke]

Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke 
<[EMAIL PROTECTED]> wrote:

Anne van Kesteren wrote:
 Per the updated specification which uses Web IDL IE and Safari are 
conformant here. (null and undefined are simply stringified.)


Not terrible useful, I would say. Is that something we have to live 
with because of the IDL definition???


It matches two implementations and is the default behavior for 
null/undefined when passed to something that accepts a string.


Apparently existing content does not rely on it (FF gets away with 
implementing something that IMHO makes *much* more sense). So why 
standardize it at all, or, when doing so, select something that doesn't 
make sense in practice?


Or are you claiming that people who set a header to null *really* want 
the specified behaviour?


BR, Julian

Re: setRequestHeader / Accept

[Anne van Kesteren]

On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:

Anne van Kesteren wrote:
 Per the updated specification which uses Web IDL IE and Safari are  
conformant here. (null and undefined are simply stringified.)


Not terrible useful, I would say. Is that something we have to live with  
because of the IDL definition???


It matches two implementations and is the default behavior for  
null/undefined when passed to something that accepts a string.



--
Anne van Kesteren

Re: setRequestHeader / Accept

[Julian Reschke]

Anne van Kesteren wrote:

When invoking request.setRequestHeader('Accept', null):

- Firefox 3b5 removes the Accept header
- Internet Explorer 8 (in IE7 mode) sends Accept: null
- Safari 3.1.1 sends Accept: null
- Opera 9.24 sends Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1


Per the updated specification which uses Web IDL IE and Safari are 
conformant here. (null and undefined are simply stringified.)


Not terrible useful, I would say. Is that something we have to live with 
because of the IDL definition???



...


BR, Julian