After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 509341 - g_file_get_parent etc. can't be used with http uris
g_file_get_parent etc. can't be used with http uris
Product: gvfs
Classification: Core
Component: client module
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
: 511927 (view as bug list)
Depends on:
Blocks: 512581
Reported: 2008-01-14 11:47 UTC by Jan Arne Petersen
Modified: 2008-01-31 16:55 UTC
See Also:
GNOME target: ---
GNOME version: ---

A partly tested implementation idea (8.10 KB, patch)
2008-01-29 22:06 UTC, Jan Arne Petersen
none Details | Review

Description Jan Arne Petersen 2008-01-14 11:47:31 UTC
The http uri implementation should use info->path (like dav) to support g_file_get_parent etc.
Comment 1 Alexander Larsson 2008-01-15 11:18:44 UTC
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.
Comment 2 Jan Arne Petersen 2008-01-17 17:26:11 UTC
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.
Comment 3 Alexander Larsson 2008-01-21 09:38:35 UTC
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.
Comment 4 Alexander Larsson 2008-01-28 11:55:56 UTC
*** Bug 511927 has been marked as a duplicate of this bug. ***
Comment 5 Bastien Nocera 2008-01-28 19:41:47 UTC
       GFile *file, *rel;

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

       resolved = g_file_get_uri (rel);

resolved will be:

       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);

resolved will be:

(This is without any http support, no libsoup 2.4 installed). I checked that gdaemonfile is being used, and not the gdummyfile in gio.
Comment 6 Jan Arne Petersen 2008-01-29 22:06:38 UTC
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.
Comment 7 Alexander Larsson 2008-01-30 10:49:29 UTC
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. 
Comment 8 Bastien Nocera 2008-01-30 11:44:15 UTC
I wanted to use it to resolve URIs in totem-pl-parser. Eg. a playlist in 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.
Comment 9 Alexander Larsson 2008-01-30 13:03:54 UTC
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.
Comment 10 Jan Arne Petersen 2008-01-30 22:14:40 UTC
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).
Comment 11 Alexander Larsson 2008-01-31 16:55:15 UTC
Ok. Commited something based on the patch posted here with additional work on the daemon side. Seems to work now.