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 551298 - read edit/display name from Content-Disposition response header
read edit/display name from Content-Disposition response header
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: http backend
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-09-07 23:04 UTC by Jonathan Matthew
Modified: 2011-05-08 13:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
parse content-disposition header (1.38 KB, patch)
2008-09-08 12:12 UTC, Jonathan Matthew
needs-work Details | Review
Use soup's content_disposition support to set the basename (1.51 KB, patch)
2010-03-12 05:15 UTC, Michael Gratton
none Details | Review

Description Jonathan Matthew 2008-09-07 23:04:28 UTC
Sometimes, the content-disposition header is the only way you can get a useful filename out of a response.

For example (from bug 551292):

$ gvfs-info http://www.publicbroadcasting.net/tavis/.jukebox/media/tavis/751757/mp3/June2008Podcasts/podcast/480/751757.mp3
  [some delay here caused by bug 551990]
display name: QuerySplicedItemContent
edit name: QuerySplicedItemContent
 ...


Following the redirect chain manually (with curl -I or similar), you can see a Content-Disposition header in the final response:

Content-Disposition: inline; filename="751757.mp3"


It'd be great if we could get the edit/display names from this header, rather than hacking around the problem by using the filename from the original request.
Comment 1 Jonathan Matthew 2008-09-08 12:12:53 UTC
Created attachment 118295 [details] [review]
parse content-disposition header

This was mostly a cut and pasted from gnome-vfs.
Comment 2 Dan Winship 2008-12-10 17:49:08 UTC
libsoup 2.25 has explicit Content-Disposition support, which parses much more reliably than that code (differences in optional whitespace, unescaping backslashed stuff in quoted-strings, etc), and also handles UTF-8-encoded filenames. Just do:

  GHashTable *params;
  if (soup_message_headers_get_content_disposition (msg->response_headers,
                                                    NULL, &params))
    {
      const char *name = g_hash_table_lookup (params, "filename");
      if (name)
        {
           g_free (basename);
           basename = g_strdup (name);
        }
      g_hash_table_destroy (params);
    }

(Hm... probably ought to add an API to just get the filename directly...)

And it strips the path off "filename" internally, so you don't have to do that yourself.
Comment 3 Michael Gratton 2010-03-12 05:15:16 UTC
Created attachment 155925 [details] [review]
Use soup's content_disposition support to set the basename

Use the built-in support in soup to set the basename using the content-disposition header, if present.
Comment 4 Michael Gratton 2010-03-12 05:20:33 UTC
Getting this patch applied would be awesome since AFAICT PyGTK applications can't work around it - there's no way to access the SoupMessage from PyGTK so we can't manually check for a Content-Disposition header.
Comment 5 Christian Kellner 2011-05-08 13:54:31 UTC
I committed a slightly modified version to git master (fb8deae). Thank you both for the patches.