readonly XMLRequestHeaders not detected in setRequestHeader

Reported by:	losborn@fwm.tv	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. )

Attachments (0)

Change History (7)

Changed October 27, 2011 10:01PM UTC by dmethvin comment:1

component:	unfiled → ajax
priority:	undecided → low

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.

Changed October 28, 2011 12:51AM UTC by losborn@fwm.tv comment:2

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

Changed November 03, 2011 06:27PM UTC by dcherman comment:3

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.

Changed November 05, 2011 09:33PM UTC by timmywil comment:4

cc:	→ jaubourg
keywords:	→ needsreview
status:	new → open

Changed November 06, 2011 04:45AM UTC by dcherman comment:5

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/

Changed June 26, 2012 02:57AM UTC by dmethvin comment:6

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.

Changed June 26, 2012 02:58AM UTC by dmethvin comment:7

keywords:	needsreview

Side navigation

#10592 closed bug (wontfix)