New handling for URI scheme handlers
faure at kde.org
Tue Dec 3 00:32:31 PST 2013
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
More information about the xdg