Last modified: 2014-07-28 19:32:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18963, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16963 - Content-disposition: download insufficient to force download of Special:Export output; consider forcing Content-Type
Content-disposition: download insufficient to force download of Special:Expor...
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Export/Import (Other open bugs)
1.13.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-11 00:05 UTC by Dan Jacobson
Modified: 2014-07-28 19:32 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2009-01-11 00:05:14 UTC
Regarding this section of includes/specials/SpecialExport.php,

	header( "Content-type: application/xml; charset=utf-8" );
	if( $wgRequest->getCheck( 'wpDownload' ) ) {
		// Provide a sane filename suggestion
		$filename = urlencode( $wgSitename . '-' . wfTimestampNow() . '.xml' );
		$wgRequest->response()->header( "Content-disposition: attachment;filename={$filename}" );
	}

For me, I would expect two different responses in the users' browser:

1) if the wpDownload box is checked, the browser would insist they
save the response in a file, and would not show them anything on the
screen.

2) if the wpDownload box is NOT checked, the browser would show them
the same contents directly.

This all works fine if one uses Firefox, but in midori, emacs-w3m,
etc. browsers I tested here on Debian GNU/Linux, one just gets for 1
and 2 the same mishmosh of semi rendered mess.

Yes, this is all the fault of those browsers not being up to date with
the trends of today, but I still propose you instead make the
wpDownload choice a radio button with additional choices:
* "send as text/plain, for guaranteed visibility in ones browser"
* "send as application/download or application/octal-stream or
something, for guaranteed forcing the browser to save in a file"

Of course the default checked item should still be like 1) above.
Comment 1 Dan Jacobson 2009-01-11 00:18:14 UTC
P.S., on this page you might want to give a link to
http://www.mediawiki.org/wiki/API to alert the user to alternatives...
Comment 2 Brion Vibber 2009-03-02 22:42:29 UTC
Updated summary to clarify issue.
Comment 3 This, that and the other (TTO) 2014-07-28 11:56:20 UTC
The "save as file" feature appears to work correctly in modern browsers.

(In reply to Dan Jacobson from comment #0)
> This all works fine if one uses Firefox, but in midori, emacs-w3m,
> etc. browsers I tested here on Debian GNU/Linux, one just gets for 1
> and 2 the same mishmosh of semi rendered mess.

According to [[mw:Compatibility#Browser]] we generally don't make an effort to make things work 100% smoothly on obscure browsers like midori and emacs-w3m. The workaround is simple (Ctrl+S or equivalent) so it's hardly a massive break of functionality in any case.

Closing this bug as overly general. If you have specific instances of this not working in listed browsers, please file new bugs for each.
Comment 4 Dan Jacobson 2014-07-28 19:32:01 UTC
Well OK I guess.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links