[Webkit-unassigned] [Bug 18490] [SOUP] Local files are not handled

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=18490





------- Comment #2 from danw at gnome.org  2008-04-20 09:30 PDT -------
Created an attachment (id=20699)
 --> (http://bugs.webkit.org/attachment.cgi?id=20699&action=view)
first draft of a patch for file: (and ftp:) support

OK, here is a first draft. It works for local files, mostly.

Among the problems with the patch are:

  1. It adds a bunch of crap to ResourceHandleInternal, although all of the
     other backends add lots of crap there too, so this is probably expected

  2. It doesn't handle any error cases at all. Even in the places where it
     looks like it handles errors, it doesn't really; you just get a blank
     page in GtkLauncher instead of an error message. (Maybe that's a
     GtkLauncher problem?) At any rate, there are also other places where
     it should return an error, but it doesn't. Also, I wasn't sure if you're
     allowed to call ->didFail() after having called didReceiveResponse(),
     etc.

  3. queryInfoCallback probably needs to be failing with ERROR_UNKNOWN_PROTOCOL
     in some situation, but I don't know what that is. (None of the GIOError
     values seem to correspond to that). Actually, we should probably just
     limit the gio usage to specific URI types. ("file" and "ftp"? What are
     we expected to support?)

  4. ftp support sort of works a little bit, but there's no code to deal with
     mounting remote filesystems currently, so it only works if you first
     "Connect to Server..." from nautilus, and then try to access the ftp:
     URL in GtkLauncher. To fix this, we should be looking for
     G_IO_ERROR_NOT_MOUNTED, and calling g_file_mount_enclosing_volume() in
     that case (and keeping a timeout and unmounting the volume later if we're
     done with it).

  5. What should happen if the URI is a directory rather than a file? We can
     use gio to iterate the directory and find out about its children, but
     how do we return that to the caller?


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.