Answered by:
Setting User-Agent header in a WinJS.xhr request

Question
-
Hi all,
i've installed the new Win8 RC and the new Visual Studio RC and now i'm experiencing a strange behaviour of the xhr-request. I need to set a custom User-Agent header in every request because the app backend uses it to determine which client app is calling it. The code is quite straighforward:
//Start the request var xhrOptions = { url: baseURL, type: "PUT", data: JSON.stringify({ test: "testdata" }), headers{ "User-Agent": "CustomAgent", "Content-Type": "application/json; charset=UTF8", "Accepts-Encoding": "gzip" } }; WinJS.xhr(xhrOptions).done( function success(response) { //Success }, function fail(response) { //fail });
But on the server the header is logged as:
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; MSAppHost/1.0)
The strage thing is, that everything worked in Win8 Consumer Preview and WinJS.0.6. What exactly has been changed in WinJS.1.0.RC and how can I set a custom user agent? Rewriting the server is not an option because a bunch of other apps rely on this behaviour.
Regards,
Al
Friday, June 1, 2012 4:20 PM
Answers
-
No problem Phil... Sorry I was not explicit:
http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method
User-Agent is in this list so it is not processed: 5. Terminate these steps if <var>header</var> is a case-insensitive match for one of the following headers:
Here is their reasoning: The above headers are controlled by the user agent to let it control those aspects of transport. This guarantees data integrity to some extent. Header names starting with
Sec-
are not allowed to be set to allow new headers to be minted that are guaranteed not to come from-Jeff
Jeff Sanders (MSFT)
- Proposed as answer by Jeff SandersMicrosoft employee, Moderator Monday, June 4, 2012 7:01 PM
- Marked as answer by Jeff SandersMicrosoft employee, Moderator Monday, June 4, 2012 7:09 PM
Monday, June 4, 2012 7:00 PMModerator
All replies
-
Hi Al,
I confirmed the change in behavior. This would be a change in IE 10 since we utilize it's XMLHttpRequest object. I will see if they have any information about this.
-Jeff
Jeff Sanders (MSFT)
Friday, June 1, 2012 6:40 PMModerator -
Hi Jeff,
thanks a lot for the reply. Do you have any idea how we can workaround this issue?
Al
- Edited by Al Brose Monday, June 4, 2012 10:17 AM
Monday, June 4, 2012 8:45 AM -
This would be a breaking change that is not mentioned anyway in the migration docs. I also customize the User-Agent header.
Also XMLHttpRequest is "optimizing" port informations out of URLs, which is quite annoying. If I specifically want to set a port as :80 in the URL I do not expect IE to remove it just because its "the default port for that protocol". Or is this part of the W3C spec?
Monday, June 4, 2012 9:04 AM -
Hi Al,
There is no way to set this header. This is to conform to the W3C RFC on this header.
The only way to work around this would be to handle a query string on the backend.-Jeff
Jeff Sanders (MSFT)
- Proposed as answer by Jeff SandersMicrosoft employee, Moderator Monday, June 4, 2012 6:15 PM
Monday, June 4, 2012 6:15 PMModerator -
Jeff, where in the spec is it mentioned that you cannot set this header? http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
edit: Ah, understand your response now. MS is playing babysitter for its app developers (again?)... why oh why!?
- Edited by phil_ke Monday, June 4, 2012 6:33 PM
Monday, June 4, 2012 6:31 PM -
Monday, June 4, 2012 6:43 PMModerator
-
Jeff, I am sorry I still don't see where it says that the implementor of this interface should prevent changes to the sent User-Agent header?Monday, June 4, 2012 6:53 PM
-
No problem Phil... Sorry I was not explicit:
http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method
User-Agent is in this list so it is not processed: 5. Terminate these steps if <var>header</var> is a case-insensitive match for one of the following headers:
Here is their reasoning: The above headers are controlled by the user agent to let it control those aspects of transport. This guarantees data integrity to some extent. Header names starting with
Sec-
are not allowed to be set to allow new headers to be minted that are guaranteed not to come from-Jeff
Jeff Sanders (MSFT)
- Proposed as answer by Jeff SandersMicrosoft employee, Moderator Monday, June 4, 2012 7:01 PM
- Marked as answer by Jeff SandersMicrosoft employee, Moderator Monday, June 4, 2012 7:09 PM
Monday, June 4, 2012 7:00 PMModerator -
I understand. We are already using a custom "X-ourapp" header so we do not depend on MS set headers. But the reasoning seems plausible. That said... server processing should not (entirely) depend on http headers, especially if they are coming from an untrusted client :)Monday, June 4, 2012 7:08 PM
-
Ok, thanks for the explanation.
- Proposed as answer by killua1989 Monday, June 11, 2012 8:11 PM
- Unproposed as answer by killua1989 Monday, June 11, 2012 8:11 PM
Tuesday, June 5, 2012 8:53 AM