#10592 closed bug (wontfix)
readonly XMLRequestHeaders not detected in setRequestHeader
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | ajax | Version: | 1.6.1 |
Keywords: | Cc: | jaubourg | |
Blocked by: | Blocking: |
Description
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. )
Change History (7)
comment:1 Changed 12 years ago by
Component: | unfiled → ajax |
---|---|
Priority: | undecided → low |
comment:2 Changed 12 years ago by
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. )
comment:3 Changed 12 years ago by
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.
comment:4 Changed 12 years ago by
Cc: | jaubourg added |
---|---|
Keywords: | needsreview added |
Status: | new → open |
comment:5 Changed 12 years ago by
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:
comment:6 Changed 11 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
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.
comment:7 Changed 11 years ago by
Keywords: | needsreview removed |
---|
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.