Midori Web Browser

content-disposition is ignored

Bug #648471 reported by Matt Read on 2010-09-27

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	Midori Web Browser	Confirmed	Medium	Unassigned
	Steadyflow	Triaged	Low	Unassigned

Bug Description

Some download servers serve there files using content-disposition header. For example:

Content-Disposition: attachment; filename="diff.tar.gz"

However steadyflow has no option to support this and instead tries to determine a filename from the URI.

So, for example, downloading a file served as an attachment content-disposition from http://example.com/get_file/23rt674948 would result in a filename of 23rt674948. Which in turn means I have to go back to the webpage and determine if it was a zip, tar.gz, tar.bz2, etc. (cause in CLI it's hard to find that out ;) )

There should be an option for "determine file name automatically", so it can use the content-disposition header properly.

Tags:

Revision history for this message

Matt Read (mattread) wrote on 2010-09-27:

OR, as another thought, it should provide a way via DBus to pass in the url AND filename of the file.

Maia Everett (linneris) on 2011-05-04

Changed in steadyflow:
status:	New → Triaged
importance:	Undecided → Low

Revision history for this message

Cris Dywan (kalikiana) wrote on 2012-03-20:

It should accept HTTP headers via DBus, which would also allow parsing of authentication and cookies. Otherwise all applications have to handle these details before calling the SteadyFlow API.