Re: [imports] credentials flag bits need to be updated to current fetch terminology
On Tue, Jul 29, 2014 at 12:21 AM, Hajime Morrita morr...@google.com wrote: I think following XHR behavior makes sense because it is well understood as it's been there for a long time and both imports and XHR load documents. I guess. It's also really weird. -- http://annevankesteren.nl/
Re: [imports] credentials flag bits need to be updated to current fetch terminology
I encountered a pre-release site that uses credentials to protect it from public. Imports in that site failed to load because the UA didn't send credentials. The current behavior solved this problem. There are a couple of options that I didn't take: - Always send credentials: We clearly shouldn't do this as the same reason why XHR doesn't this. - Introduce @crossorigin attribute: This seemed plausible, but I worried that this can be just redundant and hurts brevity if the credential-protected sites are the mainstream. Once a popular FAQ site recommends to put it all the time, that would become bad news. Then send-only-same-origin looked promising way to go. I think following XHR behavior makes sense because it is well understood as it's been there for a long time and both imports and XHR load documents. I'm not super confident about this though. On Sun, Jul 27, 2014 at 4:18 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 22, 2014 at 12:36 AM, Hajime Morrita morr...@google.com wrote: It behaved like that before. I changed it to current one so that it works with credential-protected in-house or staged apps. You'll need to elaborate a bit, I'm not sure I understand. In any event, I think XMLHttpRequest's default behavior of only sending credentials same-origin is somewhat confusing. If we only offer one mode for rel=import we should either always include credentials (and thus require more complicated CORS headers) or never. -- http://annevankesteren.nl/ -- morrita
Re: [imports] credentials flag bits need to be updated to current fetch terminology
On Tue, Jul 22, 2014 at 12:36 AM, Hajime Morrita morr...@google.com wrote: It behaved like that before. I changed it to current one so that it works with credential-protected in-house or staged apps. You'll need to elaborate a bit, I'm not sure I understand. In any event, I think XMLHttpRequest's default behavior of only sending credentials same-origin is somewhat confusing. If we only offer one mode for rel=import we should either always include credentials (and thus require more complicated CORS headers) or never. -- http://annevankesteren.nl/
Re: [imports] credentials flag bits need to be updated to current fetch terminology
It behaved like that before. I changed it to current one so that it works with credential-protected in-house or staged apps.
Re: [imports] credentials flag bits need to be updated to current fetch terminology
On Wed, Jul 16, 2014 at 10:58 PM, Hajime Morrita morr...@google.com wrote: https://github.com/w3c/webcomponents/commit/90da4809a207916486bc7af83a568f3762e780a0 Does this really make sense though? We want to include credentials for same-origin fetches, but not cross-origin? Why not always exclude them in that case? -- http://annevankesteren.nl/
Re: [imports] credentials flag bits need to be updated to current fetch terminology
That's right. Thanks for the catch! Fixed: https://github.com/w3c/webcomponents/commit/90da4809a207916486bc7af83a568f3762e780a0 On Tue, Jul 15, 2014 at 10:00 AM, Boris Zbarsky bzbar...@mit.edu wrote: In http://w3c.github.io/webcomponents/spec/imports/#fetching-import the spec says: Fetch a resource from LOCATION with request's origin set to the origin of the master document, the mode to CORS and the omit credentials mode to CORS. There is no omit credentials mode in the current Fetch draft, and the mode that _is_ there, credentials mode, doesn't have CORS as a value. Presumably this is asking for same-origin? -Boris -- morrita
