Bug Tracker

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#10592 closed bug (wontfix)

readonly XMLRequestHeaders not detected in setRequestHeader

Reported by: losborn@… 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 8 years ago by dmethvin

Component: unfiledajax
Priority: undecidedlow

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.

comment:2 Changed 8 years ago by 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. )

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by timmywil

Cc: jaubourg added
Keywords: needsreview added
Status: newopen

comment:5 Changed 8 years ago by 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/

comment:6 Changed 7 years ago by dmethvin

Resolution: wontfix
Status: openclosed

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 7 years ago by dmethvin

Keywords: needsreview removed
Note: See TracTickets for help on using tickets.