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 724970 - GsfInputGio is unable to read files from http
GsfInputGio is unable to read files from http
Status: RESOLVED FIXED
Product: libgsf
Classification: Core
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2014-02-22 20:17 UTC by Jean Bréfort
Modified: 2014-03-07 23:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (1.66 KB, patch)
2014-03-06 12:42 UTC, Jean Bréfort
committed Details | Review
Corresponding goffice patch (405 bytes, patch)
2014-03-06 13:30 UTC, Jean Bréfort
none Details | Review

Description Jean Bréfort 2014-02-22 20:17:07 UTC
This occurs because the file size is not correct in GFileInfo. Looks like it's always 0, and then Gsf refuse to read anything.
Comment 1 Morten Welinder 2014-03-01 01:26:43 UTC
Do we have an easy test for this?
Comment 2 Jean Bréfort 2014-03-01 19:40:22 UTC
The abiword bug in the "See Also" field.
Comment 3 Morten Welinder 2014-03-06 01:42:34 UTC
We have two different http readers:

gsf-input-http.c    [based on nanohttp from libxml2]
gsf-input-gio.c     [glib]

I see the same bug for both: we get a length that isn't right.  In my case
(reading http://www.gnumeric.org/download.html) the size I see is
the one in the http header.  That's "Content-Length: 1057" which is the
content's size subject to "Content-Encoding: gzip".  I.e., it is useless
and nanohttp claims we cannot rely on it anyway.
Comment 4 Morten Welinder 2014-03-06 02:01:13 UTC
Filed bug 725782 with glib/gio for that.
Comment 5 Morten Welinder 2014-03-06 02:11:57 UTC
Hmm...  gio has 245 open bugs.  I probably wasted my time reporting that.
Comment 6 Morten Welinder 2014-03-06 02:18:05 UTC
Workaround committed.  Please test.
Comment 7 Jean Bréfort 2014-03-06 07:45:01 UTC
Abiword freezes. Seems gio tries to mount the http directory. This is just stupid, imho.

  • #0 poll
    at ../sysdeps/unix/syscall-template.S line 81
  • #1 g_main_context_poll
    at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c line 4007
  • #2 g_main_context_iterate
    at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c line 3708
  • #3 g_main_loop_run
    at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c line 3907
  • #4 g_dbus_connection_send_message_with_reply_sync
    at /tmp/buildd/glib2.0-2.38.2/./gio/gdbusconnection.c line 2252
  • #5 g_dbus_connection_call_sync_internal
  • #6 g_dbus_connection_call_with_unix_fd_list_sync
    at /tmp/buildd/glib2.0-2.38.2/./gio/gdbusconnection.c line 6059
  • #7 g_dbus_proxy_call_sync_internal
    at /tmp/buildd/glib2.0-2.38.2/./gio/gdbusproxy.c line 2908
  • #8 g_dbus_proxy_call_sync
    at /tmp/buildd/glib2.0-2.38.2/./gio/gdbusproxy.c line 3100
  • #9 gvfs_dbus_mount_call_query_info_sync
    from /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so
  • #10 ??
    from /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
  • #11 gsf_input_gio_new
    at gsf-input-gio.c line 138
  • #12 gsf_input_gio_new_for_uri
    at gsf-input-gio.c line 201
  • #13 UT_go_file_open_impl
    at ut_go_file.cpp line 1192

Comment 8 Jean Bréfort 2014-03-06 08:46:30 UTC
Ok, found a working solution: we need to check in go_file_open() if the uri starts with "http://" or "https://" and return a GsfInputHTTP if yes and a GsfInputGIO if not.
Comment 9 Jean Bréfort 2014-03-06 10:20:13 UTC
But this still leaves the size issue. I can open images from http in abiword, but not html files (premature end of data).
Comment 10 Jean Bréfort 2014-03-06 12:42:01 UTC
Created attachment 271093 [details] [review]
Proposed patch

This patch (along with a go-file.c patch) makes abiword able to read http://www.gnumeric.org/download.html
Comment 11 Morten Welinder 2014-03-06 13:19:19 UTC
Patch is fine, but please add a reference to this bug when you commit.
Note, that even if nanohttp returned the right size we would still need
this kind of code because nanohttp documents that the size is sometimes
not available.
Comment 12 Jean Bréfort 2014-03-06 13:30:56 UTC
Created attachment 271102 [details] [review]
Corresponding goffice patch
Comment 13 Morten Welinder 2014-03-06 14:57:01 UTC
You need to test the protocal with g_ascii_strncasecmp since the protocol
is not case sensitive.

Also, that needs a comment are someone will optimize it away one day.

Other than that, go ahead and commit.
Comment 14 Jean Bréfort 2014-03-06 15:09:09 UTC
Done, may be we can close even if GIO itself is not fixed.
Comment 15 Morten Welinder 2014-03-06 18:11:59 UTC
Yes, we no longer get hit by the gio/gvfs issue.

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 16 Morten Welinder 2014-03-07 23:03:02 UTC
One should note that gio has the potential to be better than libxml
for this purpose.  If a login is required, for example, gio might work
where libxml will not.

As long as it doesn't work that is purely hypothetical, of course.