Morten Fangel wrote: > It should be noted that it won't continue to be able to set the > Authorization-header via JavaScript, so JS-clients will not be able to > support Authorization-headers in the future.. > > See the Editors Draft for reference (bullet point #5) > http://dev.w3.org/2006/webapi/XMLHttpRequest/Overview.html#setrequestheader > > Safari 4 Beta still allows the header to be set, but WebKit Nightly > denies the header. > This coincidentally broke my current application horribly because it > required the ability to set the Authorization-header. I'll now have to > rewrite the API-calling code to use OAuth transmitted over one of the > two remaining ways.. > > Someone maybe want to contact W3C / WhatWG that the Authorization-header > is Nice To Have as a allowed header.. >
Depending on what motivated this change, it may also be worth proposing a higher-level API for using OAuth specifically via XMLHttpRequest. The Note below the list implies that it is included here because the browser is better able to determine its value. I assume the thinking is that if the browser has Basic credentials cached (for example) then it'll automatically include them. However, coming at this from another angle, what is the use-case for using OAuth in XMLHttpRequest? Since XMLHttpRequest can only be used to talk to your own site, and is only used in the browser scenario, I would expect that in most cases such requests would be authenticated via a session cookie rather than via OAuth. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
