New handling for URI scheme handlers

[Bastien Nocera]

On Mon, 2013-12-02 at 09:40 +0000, Jerome Leclanche wrote:
> On Mon, Dec 2, 2013 at 7:57 AM, Bastien Nocera <hadess at hadess.net> wrote:
> > On Mon, 2013-12-02 at 07:49 +0000, Jerome Leclanche wrote:
> >> On Mon, Dec 2, 2013 at 7:13 AM, Bastien Nocera <hadess at hadess.net> wrote:
> >> > On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote:
> >> >> (very old mail, but this is bugging me again :)
> >> >>
> >> >> Context: I believe that associating a webbrowser with x-scheme-handler/http is
> >> >> wrong.
> >> >>
> >> >> On Wednesday 06 October 2010 00:38:40 Bastien Nocera wrote:
> >> >> > David Faure wrote:
> >> >> > >  When you click a http URL that
> >> >> > > points to an .odt document, you want to launch openoffice, not a
> >> >> > > web-browser.
> >> >> >
> >> >> > If you're already in a web browser, yes, but in this case, the lookup
> >> >> > shouldn't be including a scheme handler lookup, just an application that
> >> >> > handles that particular mime-type.
> >> >>
> >> >> But what if you're not in a webbrowser in the first place?
> >> >> E.g. in a desktop email application, you click on an HTTP link to a .odt
> >> >> document. Should that really start firefox, just so that it can then launch
> >> >> openoffice?
> >> >> (same with any other content application that can handle HTTP urls on its own;
> >> >> same with other schemes that apps might support, like FTP).
> >> >>
> >> >> Note that at this point we have no clue about the mimetype. We can start a
> >> >> download and find it out, but the first question is: should we do that, or
> >> >> just blindly trust the app that says it wants all URLs with this scheme (http,
> >> >> in my example).
> >> >>
> >> >> Since we don't want this to happen in KDE, I had to write code such as "if KIO
> >> >> supports a scheme and an app exists for the mimetype x-scheme-
> >> >> handler/<scheme>, then give priority to KIO". (for the special case of http,
> >> >> there is actually a user setting for "send all http urls to this particular
> >> >> app", but that's not the default setting).
> >> >> I don't like it very much though, it feels like a hack :)
> >> >> But I guess it makes sense, since in KDE we prefer to open HTTP urls by
> >> >> mimetype, while IIUC in Gnome you prefer to open them with a single scheme-
> >> >> associated application (i.e. webbrowser).
> >> >>
> >> >> So, it's all fine, I'm just curious about what happens in your case when the
> >> >> user isn't in a webbrowser in the first place (and to pick the worst case - if
> >> >> it's not running yet, which means a long delay coming from the startup of two
> >> >> large applications one after the other).
> >> >
> >> > I wish it worked like that as well, but you've just broken one-time URLs
> >> > and tried to open a login page in LibreOffice if you don't share cookie
> >> > jars between all the clients.
> >>
> >> With a middleman client this is a solved issue; it would be identified
> >> as a page to take care of in the browser.
> >
> > Let me know when you have that middle man client implemented :)
> >
> > I wonder how you'll handover to the dozen of different web browsers,
> > read their cookie jars, or get applications with links to use your
> > middle man client instead of whatever HTTP library they want to use.
> >
> > It's a nice idea, but it's just not feasible without a clean slate. I
> > think that GNOME's current approach is more pragmatic, especially with
> > HTTP's baggage.
> >
> 
> I think you're confused about the complexity of the task.
> 
> 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)

This might fail if you need to log in, because the file type on the end
of the call is HTML when the URI tells you otherwise.

>  - If it is, run a match against the xdg patterns on it
>  - 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

The HTTP HEAD just ate your one-time URL. 

>  - 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
>  * If any step fails, hand off to web browser
> 
> This could be a simple script, or it could be a more involved download
> manager that would integrate with the desktop (a neat system-wide
> download bar such and such).

It seems that I didn't explain myself well enough. You cannot access the
URLs given to you from outside the client that will ultimately handle it
because you might be using up a one-time URL. You also cannot rely on
filenames because that's not how HTTP mime-types are conveyed.