I'm not really sure of this. http uris are really kinda weird and not really a hierarchy like a typical directory mount. For instance, there is no guarantee that the parent (in the textual sense) exists or is of a type directory.

The implementation we use to somehow make http work in a statefull filesystem model is that each uri is a mount of itself that only contain the particular file that GETing that uri results in. Its kinda weird, but then http is really not a filesystem.

Ok, but relative http uris are a common use case. With this concept it isn't possible to use the g_file api to resolve relative http uris for example.

That is true, but unfortunately I don't know a good way to handle this. http is quite far from a file system, and emulating one over http shows of some of the odd corners.

It will work with dav:// though.

*** Bug 511927 has been marked as a duplicate of this bug. ***

--8<--
       GFile *file, *rel;

       file = g_file_new_for_uri ("http://localhost:12345/foobar");
       rel = g_file_resolve_relative_path (file, "/leopard.mov");

       resolved = g_file_get_uri (rel);
--8<--

resolved will be:
http://localhost:12345/foobar

--8<--
       GFile *file, *rel;

       file = g_file_new_for_uri ("http://localhost:12345/foobar/");
       rel = g_file_resolve_relative_path (file, "another_file");

       resolved = g_file_get_uri (rel);
--8<--

resolved will be:
http://localhost:12345/foobar/

(This is without any http support, no libsoup 2.4 installed). I checked that gdaemonfile is being used, and not the gdummyfile in gio.

Created attachment 103989 [details] [review]
A partly tested implementation idea

This patch allows to create a new GMountSpec for a new path. Allows to drop fragment and query parts of the uri and create a new "uri" value for http uris.

There are some issues with this. 

First of all you pass in a path in addition to the base uri in the mount. The backend will currently append this to the uri, leading to reading the wrong uri. I think we can handle this in the daemon side, but it needs some care as the code is shared with webdav which does use paths.

Secondly, there is the question of semantics for something like this. If you have a "path" to something, and you can get its parent, you generally expect said parent to exist, and to be a directory (with the file in it). This does not at all apply to http uris, which can be highly confusing for applications that expect filesystem semantics.

However, being able to resolve relative pathnames on http uris is useful in some situation, so maybe having this weird semantics is worth it?

What exactly do you expect to use this feature for? Remembering that GFile is designed as a file system abstraction and is not the right place for general URI manipulation as needed by e.g. a web browser. 

I wanted to use it to resolve URIs in totem-pl-parser. Eg. a playlist in http://foobar.com/playlists/foobar.asx pointing to a file in /videos/myvideo.avi.

I agree that it might change the meaning of the mount for http, but right now it doesn't match what I expected the functions to be doing. Furthermore, you say that you expect the parent to be a directory, but all over the documentation there are caveats like "This operation never fails, but the returned object might not support any I/O operation if path is malformed." and "Note that the file with that specific name might not exist, but you can still have a GFile that points to it.".

Maybe adding a warning in the docs for g_file_parent would be in order.

Its true that any GFile operation can fail with any error.
For instance, if you stat /etc/passwd, then /etc it may happen that someone removed /etc and replaced it with a file inbetween your calls, so its not an *error* per se if the parent is not a directory. But that is sort of a edge case, wheres this is standard fare for http uris.

From filesystem semantics you wouldn't expect to get a root (HTTP-)file instead of a root-directory as in the current implementation. So I think it would be also a valid approach from filesystem semantics to map the path part of the HTTP-URI to "virtual directories" (defined by the hierarchical structure of the path component in the HTTP-URI).

Ok. Commited something based on the patch posted here with additional work on the daemon side. Seems to work now.