[whatwg] Input URL State and Files object
jonas at sicking.cc
Thu Aug 26 19:53:56 PDT 2010
On Thu, Aug 26, 2010 at 5:24 PM, Charles Pritchard <chuck at jumis.com> 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.
> Continuing on with tweaking URLs to work with with the File API:
> Chrome has gone ahead with their setData proposal, enhancing the
> object so that users may drag a file from within the browser onto their
> 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
> 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
> does not require an Origin check.
I would think that a same-origin check should always be performed. In
firefox, the save-as dialog always displays the website you are
downloading from. However with drag'n'drop no dialog will be shown and
the user will presumably think he/she is downloading from the site
where the drag started.
Or are browsers planning on displaying the save-as dialog?
More information about the whatwg