This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm not sure why http://dev.w3.org/2006/webapi/FileAPI/#cross-origin-requests-on-blobs is included in this specification. That should follow from URL / Fetch, no? Duplicate requirements are bad.
(In reply to Anne from comment #0) > I'm not sure why > http://dev.w3.org/2006/webapi/FileAPI/#cross-origin-requests-on-blobs is > included in this specification. That should follow from URL / Fetch, no? > > Duplicate requirements are bad. You're right. I've fixed this now so that Fetch is normative.
Now you use must in a non-normative section.
Fixed! http://dev.w3.org/2006/webapi/FileAPI/#NetworkError
This still seems wrong. :-( I think basically you do not want to say anything about cross-origin URLs and let that part of the security model be handled by Fetch.
(In reply to Anne from comment #4) > This still seems wrong. :-( > > I think basically you do not want to say anything about cross-origin URLs > and let that part of the security model be handled by Fetch. But File API defines the origin and origin policy of Blob URLs, and what requests are legal. It would be weird to be silent on the matter of cross-origin requests. I suppose I could just invoke the Fetch specification. Also, what "seems wrong?" We already defer to Fetch and URL for most of the dereferencing. This just says that cross-origin requests return with a network error.
I don't see how that makes sense. If Fetch defines that, why would we define it again here?
(In reply to Anne from comment #6) > I don't see how that makes sense. > > If Fetch defines that, why would we define it again here? Well, I'm talking about: http://dev.w3.org/2006/webapi/FileAPI/#requestResponseModel Should ALL of it be subsumed by Fetch?
Yeah I think so. Unless you think Fetch should defer to the File API for the extracting bits from a blob bit, but I'm not sure why we would intertwine them like that.
(In reply to Anne from comment #8) > Yeah I think so. Unless you think Fetch should defer to the File API for the > extracting bits from a blob bit, but I'm not sure why we would intertwine > them like that. Any FileAPI guidance on request/response when fetching Blob URLs is now non-normative, and I consider it provisional (e.g. can delete finally) when Fetch fully owns Blob URLs as per bug 24338, which is assigned to annevk. http://dev.w3.org/2006/webapi/FileAPI/#requestResponseModel