readonly XMLRequestHeaders not detected in setRequestHeader

[losborn@…]

According to ​http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method request headers matching the following pattern are not supposed to be settable in JavaScript.

/^(accept-(charset|encoding)|content-length|(content-)?transfer-encoding|cookie2?|date|expect|host|keep-alive|referer|te|trailer|upgrade|user-agent|via)$/i 

This is all well and good, except different browsers respond to attempts to write to these headers differently. (Some will silently ignore them, while others will issue an exception.) This makes code that appears to work perfectly on one browser fail to work properly on another.

I'm honestly NOT SURE this is a bug that SHOULD be fixed (beyond making sure it's properly documented). This is mostly a bug having to do with programer error, and attempting to fix all such issues would simply bloat jQuery.

The bug is pretty trivial to solve: check any calls to setRequestHeader for name arguments that match the above pattern, and either always throw an error, or always ignore them, but the pattern by itself is over 150 characters. The bigger question is *SHOULD*' this bug be addressed?

(FYI, If you *DO* decide to fix this, it would PERSONALLY make my life easier with my CURRENT PROJECT if attempts to set these values were always ignored, but I can easily imagine other projects or circumstances where I would prefer exactly the opposite behavior. Sorry. )

[dmethvin]

I believe that in some non-browser environments like an embedded Windows browser it does allow the caller to set some of those headers, and I've used jQuery in those cases. So I don't think we should artificially limit the headers. That's especially true if we had to put a long regexp in the code to do it, since that would add a lot of bytes.

[losborn@…]

I wholeheartedly agree, but this does beg the question if there would be value in a "debug build" of jQuery, and if so, how would such a thing be accomplished. (It would have to be something the minifier could recognize and remove. )

[dcherman]

A debug build of jQuery is an interesting idea. I could definitely see something like that with things going even further like if .attr was called on a boolean prop, boolHook could do a console.warn saying "You should be using prop here" or something like that.

[dcherman]

I cooked this up real quick as a prototype "debug" script that can be included in non-production environments. I'm sure it can be improved, but wanted to get feedback on it as an idea:

​http://jsfiddle.net/mLvPu/

[dmethvin]

The idea of a debug plugin has always been a good one, the problem is getting the people encountering problems to use it. :)

I don't think we'll be landing the suggestion from the ticket so I'll close this, but if someone wants to include the code from dcherman into something like the ​lint plugin from padolsey that might be useful.