[whatwg] Input URL State and Files object

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
> 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 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?

/ Jonas

Received on Thursday, 26 August 2010 19:53:56 UTC