On 8/2/2010 6:54 PM, Ian Hickson wrote:
On Wed, 5 May 2010, Charles Pritchard wrote:
Sorry, it didn't make much sense: I meant a FileList object which
FileReader would use.
I still don't really see what you want here.
Is there currently a method for allowing cross-domain access to an
image based on user input?
XMLHttpRequest is the intended way to do this.
XMLHttpRequest relies upon CORS headers from the server
Yes. We would have to rely on CORS whatever the solution was to be.
I'm sorry to have approached this so poorly; what I'm looking for is a
solution to the following use case:
A person is assembling a digital scrap-book, using a web application, of
pictures they've found related to their love of kittens. Those that
they've downloaded to their computer, they simply drag and drop into the
application -- (File API, FileReader, ondrop). Those that they find on
the internet, they drag their bookmark onto the application, drag the
image onto the application, or simply, copy and paste the URL into an
<input type="url"> box.
Oh, you mean the ability for the user to give the page access to remote
resources that themselves aren't opting in to giving the page access.
Why wouldn't<input type=file> be usable for this? You should be able to
drag any file to that, just like you can type in a URL in Windows in an
open file dialog box.
<input type="file"> would be usable.
Were this implemented:
When a user through selection, click+drag or manual entry of a URL
should the browser still submit an Origin request header? It seems that
CORS doesn't come
into effect here -- but at the same time, it'd be handy for logging
purposes and added security.
When a cross-site resource is fetched via CORS, the agent submits an
"Origin" header.
A secure site (such as a bank), may always return a Forbidden response
if the "Origin" header is set;
blocking any kind of cross-site sharing, even sharing attempted by a
user (through an <input type="file"> field).
