New handling for URI scheme handlers
Bastien Nocera
hadess at hadess.net
Mon Dec 2 07:05:56 PST 2013
On Mon, 2013-12-02 at 15:53 +0100, Kevin Krammer wrote:
> On Monday, 2013-12-02, 15:34:34, Bastien Nocera wrote:
> > On Mon, 2013-12-02 at 15:16 +0100, Kevin Krammer wrote:
> > > On Monday, 2013-12-02, 09:40:12, Nicolas Mailhot wrote:
> > > > Le Lun 2 décembre 2013 00:59, David Faure a écrit :
> > > > > (same with any other content application that can handle HTTP urls on
> > > > > its
> > > > > own;
> > > > > same with other schemes that apps might support, like FTP).
> > > >
> > > > Having managed a very large proxy configuration for some years (150k+
> > > > users, high-availability) I can tell you that pretty much any
> > > > application
> > > > that pretends talking http lies, and only full browsers implement
> > > > (mostly)
> > > > the complete http spec (including error handling)
> > >
> > > David obviously looks at this from a KDE perspective, where the same HTTP
> > > implemention is used by all applications, including the browser.
> > > IIRC it can even transfer a session from one application to another, e.g.
> > > avoiding the one-time-URL problem.
> >
> > If I use Opera, Firefox or Chrome in KDE, I'm not sure it magically uses
> > the same HTTP implementation.
>
> Sure, but David also mentioned that we enable users to tell our URL handling
> code to delegate HTTP always to a certain program/browser and was, in my
> interpretation, discussing the implications on the standard setup.
>
> So, within this assumed context, I was pointing out to Nicolas that the HTTP
> implemention in question was "browser capable".
It's certainly possible to implement this feature the way mentioned when
you know that the default HTTP handler will be able to transfer/share
session information with the browser.
But David's original request was for this to work the same way across
desktops. We don't have any such support in GNOME, and I don't see it as
something that's worth the effort either. I guess that brings David's
question to a close.
More information about the xdg
mailing list