On 11/1/2010 6:03 PM, Ian Hickson wrote:
On Thu, 26 Aug 2010, Charles Pritchard wrote:
On 8/25/2010 2:02 PM, Ian Hickson wrote:
On Mon, 2 Aug 2010, Charles Pritchard wrote:
[ UAs can use<input type=file> to let the user enter remote URLs ]
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.
I don't think there'd be an origin, but that's rather up to the user
agent. (In this case it's acting on behalf of the user, not the page,
so I don't think it makes sense to give the page's origin.)
Sounds like an implementer would not include a Referer header, either.
Possibly.
Currently, this seems to be implemented by the OS:
Vista downloads a URL to the temporary files directory, then passes it
to the browser.
No cookies, or other credentials are sent with the fetch, as it is an
OS-level fetch.
Entering a remote URL does not seem to function in OS X as there is no
place on the file upload screen to enter a URL.
Is this something we want to leave undefined? As the <input type="file">
widget typically
routes directly to OS-level file management, I don't think there's a
simple solution to bringing
more control to the browser.
Continuing on with tweaking URLs to work with with the File API:
Chrome has gone ahead with their setData proposal, enhancing the
event.dataTransfer object so that users may drag a file from within the
browser onto their desktop.
The extension uses setData with a key of DownloadURL and a value
including a mime type, file descriptor and URI.
I'd like this interface to work within ondrop; if getData(DownloadURL)
is set, then a FileList would be returned in event.dataTransfer.files,
much like it is when users drag files from their desktop into the
browser.
This would of course require Origin checks; whereas dragging onto the
desktop does not require an Origin check.
I'm not quite sure I follow what you are proposing. However, in a future
version of this API we should definitely add a "promise"-like feature that
lets you specify drag data without having it already downloaded, so that
when the user drops the data somewhere, the browser can then ask the JS
for the data. I'm not sure using setData('DownloadURL') is a good way to
do it; that just seems to add more hacks to an already pretty hacky API.
The DataTransferItem proposal is heading in this direction.
Currently, a file collection ".files", works with the File API and
XmlHttpRequest.
Drag+drop from the desktop returns file objects.
I'm proposing we explore methods to enable drag+drop from within the
browser to return file objects.
The FileSystem API is a resource: we can now build a file from within
standard APIs.
Until that point, we could only use the BlobBuilder semantics.
The proposal DataTransferItem.add(fileData)
pretty much takes care of the request (when used with a working/complete
FileSystem API).
We still need a promise-like feature, as you've pointed out.
....
On a side note -- I've been having a lot of issue with building blobs:
Are there currently semantics in place to distinguish a DOMString from
binary data?
At present, I can only think of Typed Arrays from the WebGL-related specs.
Currently, when I try to build a Blob using binary data, I end up with a
UTF-8 escaped DOM String.
I'm still forced to run an XHR request, to grab binary data for an image
(one already loaded by the browser),
so that I can store that image data in local storage. I then use a
js-based base64 encoder, as browser encoders are expecting
a DOMString and throw errors on binary (per specs).
This would be solved in part, via FileSystem/File APIs, but they're also
expecting DOMString.
I expect it's meant to be solved by adding Blob support directly to XHR.
