locked
Setting User-Agent header in a WinJS.xhr request RRS feed

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

    Monday, June 4, 2012 7:00 PM
    Moderator

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 PM
    Moderator
  • 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)

    Monday, June 4, 2012 6:15 PM
    Moderator
  • 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
  • Hi Phil,

    Here is the XHR document: http://www.w3.org/TR/XMLHttpRequest/

    -Jeff


    Jeff Sanders (MSFT)

    Monday, June 4, 2012 6:43 PM
    Moderator
  • 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)

    Monday, June 4, 2012 7:00 PM
    Moderator
  • 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