New handling for URI scheme handlers

[David Faure]

On Monday 02 December 2013 09:40:00 Jerome Leclanche wrote:
> All the client does is, for http:
>  - Parse the url given to it
>  - Identify whether it's potentially a file through its name (get a
> filename if there's one)

That's broken.   http://www.davidfaure.fr/kde, is that a file or a directory?
In a way that one is both, actually. It returns HTML so it's a file, but it 
contains other files so it's a directory :)

>  - If it is, run a match against the xdg patterns on it

That's broken. http://example.org/cgi-bin/script.pl looks like a perl script 
but actually returns HTML. There are a thousand more examples like that.
Extensions over HTTP cannot be trusted.

>  - If there's any match that is not an app that is associated with
> x-scheme-handler/http(s), do HTTP HEAD on the url

That's broken. HTTP HEAD is badly implemented by many many webservers.
We used to use it, but we don't any longer. Instead we start a HTTP GET, to 
get the headers, extract the mimetype, put the download on hold, and resume it 
from the launched app. Works great for one-time urls too -- but yeah, it 
relies on using the same underlying http technology and being able to resume a 
transfer started by another app [which we can do in KIO since the transfer is 
handled by a separate process].

>  - If the HEAD was successful and returns a mime type in the mime type
> db and the mime type is associated with an app, *download* the file
>  -> Hand off downloaded file to the associated app

Downloading into a temporary file means no incremental rendering
(e.g. for a long text, or image, or worse, movie).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5