locked
Diff between WinJS.xhr() and xmlHttpRequest RRS feed

  • Question

  • Hi,

    I know xmlHttpRequest is the regular javascript API that we use to send request, which subjects to cross-domain restrictions. 

     

    At the meantime, WinJS.xhr() is the WinJS API for xmlHttpRequest which returns a promise and can be processed by the .then(successHandler, errorHandler, progressHandler).

     

    So,

     

    what's the difference between regular xhr and WinJS.xhr?

    When sending a GET/POST request, which one shall we use?

    Has Metro native app UNrestricted the same-origin policy to enable communication between app and web services by xhr or WinJS.xhr?

     

     

    Thanks,


    Louis

    • Edited by Louis_PiG Tuesday, January 24, 2012 4:32 PM
    Tuesday, January 24, 2012 7:36 AM

Answers

  • WinJS.xhr is just a wrapper around XHR that creates a promise out of the response (rather than you having to create a onreadystatechange function.) There is no capability difference between the two. Both are able to retrieve resources according to package permissions in the local context. That is to say if you are in the local context and have the internet permission you can talk to any web service (if you want to talk to a web service on your intranet, make sure to include that permission too.)

    If you are in the web context then all the same rules apply to XHR as you are used to in IE (you can make JSONP calls but you can't directly interact with web services on a different domain.) Here's a handy table of how the contexts differ:

     http://msdn.microsoft.com/en-us/library/windows/apps/hh465373.aspx

     

    Cheers,

    -Jeff

    Tuesday, January 24, 2012 6:39 PM

All replies

  • Hi Louis,

    The WinJS version is preferred for Metro Apps since you can use the async promises.

    What is the 'same-origin' policy?  I must admit I have never heard of it?

    -Jeff


    Jeff Sanders (MSFT)
    Tuesday, January 24, 2012 1:38 PM
    Moderator
  • Hi Jeff,

    I should have said Cross Domain restriction of XHR instead of "same origin policy". Could you please explain whether both WinJS.xhr and XHR has unrestricted for cross-domain access to web services. 

    I got the information from here (page 9 under XDomainRequest): http://msdn.microsoft.com/en-us/library/windows/apps/hh465373.aspx

    Just want to confirm whether I can use both to communicate with web services or any preference to WinJS.xhr.

    If there is other resources that talks more about it, please provide a link. 

    Thank you very much.

     

     


    Louis
    Tuesday, January 24, 2012 4:14 PM
  • WinJS.xhr is just a wrapper around XHR that creates a promise out of the response (rather than you having to create a onreadystatechange function.) There is no capability difference between the two. Both are able to retrieve resources according to package permissions in the local context. That is to say if you are in the local context and have the internet permission you can talk to any web service (if you want to talk to a web service on your intranet, make sure to include that permission too.)

    If you are in the web context then all the same rules apply to XHR as you are used to in IE (you can make JSONP calls but you can't directly interact with web services on a different domain.) Here's a handy table of how the contexts differ:

     http://msdn.microsoft.com/en-us/library/windows/apps/hh465373.aspx

     

    Cheers,

    -Jeff

    Tuesday, January 24, 2012 6:39 PM
  • Thank you, Jeff. 

    Just to confirm my understanding of Local context and web context.

    1. Any pages (say, grid layout collection pages) in my javascript metro app is in Local Context, in which I can talk to any web services with no CORS concern.

    2. A metro page that hosting an iframe is in Local Context too, but he iframe is considered as in Web Context? So any restrictions that applied to a xhr will in effect in the iframe. But the host-page, which is a native page in the app, can still talk to any web services without CORS concern.

    3. Does the server side need to set to accept the cross doamin header?

    Is my understanding correct?

    Thanks,


    Louis
    • Edited by Louis_PiG Tuesday, January 24, 2012 8:50 PM
    Tuesday, January 24, 2012 7:34 PM
  • #1 is correct assuming you aren't explicitly loading it in the web context.

    For #2, The context of an iframe depends upon its URI scheme, so if it's http://, https://, or ms-wwa-web:// then it will be in the web context. If it is ms-wwa:// then it will be in the local context. But yes, assuming that you have a normal metro page iframing a page on the web or a local page via ms-wwa-web, then you are correct.

    For #3 it should not have to if you are always accessing the page from a local context.

    It's worth noting that in the time since //BUILD that IE10 has added support for CORS (http://blogs.msdn.com/b/ie/archive/2011/11/29/html5-for-applications-the-fourth-ie10-platform-preview.aspx) so in future releases of Windows 8 one could use the web context for making cross-origin calls, provided the appropriate HTTP headers are returned by the remote server.

     

    Cheers,

    -Jeff

    Tuesday, January 31, 2012 6:38 PM
  • Perhaps I may be ignorant of the full power of XmlHttpRequest, so does the standard JS XHR for all browsers support binary requests? HTTP POST with binary content or getting HTTP response with binary content.

    I was under assumption (at least this may be true of earlier days of XHR) that it only did text transfers as you couldn't work with binary data much in javascript within the browser and sending it with POST would probably require encoding it to base4 first. I haven't worked with the latest AJAX features of browsers to know of any recent added functionality.

    I notice in learning Win 8 app dev with HTML and JS that WinJS.xhr() supports binary (download in example I saw). So wondering if that's another difference or if native xhr already has binary support.

    Also, I believe native XHR doesn't have cookie handling built in, so you have to manage cookies yourself like with this blog post

    http://blog.netnerds.net/2006/04/asp-sustain-remote-cookie-sessions-in-an-asp-script-using-vbscript/

    so does WinJS.xhr wrapper have it built in, or one also needs to manually manage cookies?

    • Edited by daluu Saturday, November 10, 2012 4:51 AM
    Saturday, November 10, 2012 2:53 AM
  • Hi daluu,

    WinJS.xhr is simply a wrapper around XMLHttpRequest!

    -Jeff


    Jeff Sanders (MSFT)

    Monday, November 12, 2012 1:15 PM
    Moderator
  • Hi Jeff, from the document we can't make any cross-origin call from web context, is there any way to work around this ?

    Thursday, May 30, 2013 9:57 AM