Last Comment Bug 600111 - XMLHttpRequest.setRequestHeader() throws NS_ERROR_FAILURE inappropriately
: XMLHttpRequest.setRequestHeader() throws NS_ERROR_FAILURE inappropriately
: dev-doc-needed
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla17
Assigned To: :Ms2ger (⌚ UTC+1/+2)
: Andrew Overholt [:overholt]
Depends on:
Blocks: xhr 704787
  Show dependency treegraph
Reported: 2010-09-27 19:19 PDT by Zack Weinberg (:zwol)
Modified: 2013-04-04 13:53 PDT (History)
3 users (show)
ryanvm: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

WIP (5.02 KB, patch)
2011-03-03 12:48 PST, :Ms2ger (⌚ UTC+1/+2)
no flags Details | Diff | Splinter Review
Patch v1 (8.48 KB, patch)
2012-07-24 15:07 PDT, :Ms2ger (⌚ UTC+1/+2)
jonas: review+
Details | Diff | Splinter Review

Description User image Zack Weinberg (:zwol) 2010-09-27 19:19:49 PDT
The W3C spec for XMLHttpRequest (see URL) says that setRequestHeader() is supposed to distinguish two kinds of errors, and doesn't license it to produce any other kind of exception:

# Throws an INVALID_STATE_ERR exception if the state is not OPENED or
# if the send() flag is true.
# Throws a SYNTAX_ERR exception if header is not a valid HTTP header 
# field name or if value is not a valid HTTP header field value.

Our implementation uses NS_ERROR_FAILURE for conditions falling under both these heads, and also for some internal, should-never-happen conditions (IsPending() or IsCapabilityEnabled() fails - death to xpcom).  And it can throw NS_ERROR_IN_PROGRESS under conditions that are unclear to me but probably shouldn't be visible to JS.

Also, HttpBaseChannel::SetRequestHeader can throw NS_ERROR_INVALID_ARG for conditions that I think are supposed to be mapped to SYNTAX_ERR in this case, and NS_ERROR_NOT_AVAILABLE for another probably should-never-happen condition (nsHttp::ResolveAtom fails).  And several things can produce NS_ERROR_OUT_OF_MEMORY, but we probably don't need to worry about that.
Comment 1 User image Zack Weinberg (:zwol) 2010-09-27 19:33:53 PDT
Hm, if this belongs in DOM:MozillaExtensions then so do a whole bunch of other XMLHttpRequest bugs.
Comment 2 User image :Ms2ger (⌚ UTC+1/+2) 2011-03-03 12:48:54 PST
Created attachment 516677 [details] [diff] [review]

This needs tests. I think I'll submit them to the official test suite first.
Comment 3 User image :Ms2ger (⌚ UTC+1/+2) 2012-07-24 15:07:40 PDT
Created attachment 645527 [details] [diff] [review]
Patch v1
Comment 4 User image :Ms2ger (⌚ UTC+1/+2) 2012-08-04 01:58:21 PDT
Comment 5 User image Ed Morley [:emorley] 2012-08-04 11:28:29 PDT
Backed out with the mass tree revert to get rid of the OS X M5 orange:
Comment 6 User image Ryan VanderMeulen [:RyanVM] 2012-08-04 14:50:40 PDT
Comment 7 User image Ryan VanderMeulen [:RyanVM] 2012-08-04 18:40:34 PDT

Note You need to log in before you can comment on or make changes to this bug.