1. Launch MiniBrowser browser and load: http://iop4.nokia-boston.com/users/HTML5/xhrSecurity/tests/resources/manual.html 2. Click on each of the links of Link#7, Link#9 to Link#13 3. Result in each of the test pages show failure. … EXPECTED OUTCOME: Should show Success Details: These tests try to detect if the banned headers are sent to a cross-domain target in a XHR request. These headers are: • Accept-Encoding • Accept-Charset • Accept-Language • User-Agent • Referer • Host These are not expected to be sent to a cross-domain target as per Browser security handbook at: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest
Setting those headers should be banned on same-origin requests too. Are you sure you're able to manipulate them to a non-default value?
It would be nice if the server echoed back the header value it received.
(Sorry, I don't mean to complain; I just need a slightly fancier setup to look at this bug.)
The test index link is changed. Here is the new URL: http://iop4.nokia-boston.com/users/tests/bug68032/index.html
These tests do not attempt to send custom header fields, they only check that something was sent. It is forbidden to set these headers to non-default values using XMLHttpRequest.setRequestHeader(), but it's perfectly OK for the browser to provide its own value. Please see <http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html> for more detail. • Accept-Language This header field is an exception, authors are actually allowed to change it with XMLHttpRequest.setRequestHeader().