1380035 - finance.gov.sk - Problems with spaces in filenames (content-disposition not quoted)

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect, P2)

Description

[mrninko]

Attachment: sketch-1499788305187.png

User Agent: Mozilla/5.0 (Android 7.1.1; Mobile; rv:55.0) Gecko/55.0 Firefox/55.0
Build ID: 20170706211248

Steps to reproduce:

Go to http://www.finance.gov.sk/Default.aspx?CatID=8581 and download any *.rtf file


Actual results:

Files are diwnloaded witout their fornat, without *.rtf


Expected results:

Download files with also with *.rtf format as other browsers do

Comment 1

[Jan Henning [:JanH]]

The server is sending a content-disposition: attachment;filename=Prakticke priklady II.rtf, i.e. it's using white space within the file name without properly quoting it, which is incorrect.

Moving this over to Tech Evangelism, as the site owners need to be contacted about this to correct this (i.e. like filename="Prakticke priklady II.rtf").

Comment 2

[Mike Taylor [:miketaylr]]

I'm guessing we'll have better success contacting this site if we try this is Slovak... mrninko, would you be willing to help us try to contact them? The suggested fix is in Comment 1, thanks.

Comment 3

[mrninko]

i've already sent request there to tech department. but i have no hopes (know how it works with government support) btw. it's happening only on android firefox, desktop works well

Comment 4

[Mike Taylor [:miketaylr]]

Thanks -- yeah. Contacting sites is hard, and even harder when they're government sites. :(

JanH, is the different behavior between desktop and mobile expected?

Comment 5

[Jan Henning [:JanH]]

This can happen on Desktop, too - if you choose a fixed download directory in the settings and then save the file, it gets saved without a file extension even on Windows, because we simply call validateLeafFileName, which doesn't do anything with the extension unless the file name is empty (https://dxr.mozilla.org/mozilla-central/rev/b07db5d650b7056c78ba0dbc409d060ec4e922cd/toolkit/mozapps/downloads/nsHelperAppDlg.js#375) or else if we're on Windows and the file is an executable (https://dxr.mozilla.org/mozilla-central/rev/b07db5d650b7056c78ba0dbc409d060ec4e922cd/toolkit/mozapps/downloads/nsHelperAppDlg.js#422).

Other than that, for launching the file we append the extension to the temporary file name, but only on Windows (https://dxr.mozilla.org/mozilla-central/rev/b07db5d650b7056c78ba0dbc409d060ec4e922cd/uriloader/exthandler/nsExternalHelperAppService.cpp#2441) and for saving a file through a file picker I think what happens is that we set the default extension on Windows's file dialogue (https://dxr.mozilla.org/mozilla-central/rev/b07db5d650b7056c78ba0dbc409d060ec4e922cd/widget/windows/nsFilePicker.cpp#508), so the file name returned by it probably automagically ends up with the extension we retrieved from the MIME type (testing on Linux on the other hand no extension was added through the file picker).

On Android, the download can either be handed off completely to an external app, or else our behaviour is similar to that of Desktop when using a fixed download directory, that is we don't do anything with the suggested extension unless the file name is empty (https://dxr.mozilla.org/mozilla-central/rev/b07db5d650b7056c78ba0dbc409d060ec4e922cd/mobile/android/components/HelperAppDialog.js#345).

In theory we could have some logic here to always try adding a fitting extension (although I'm not sure if this wouldn't cause problems elsewhere and maybe add additional extensions even when they aren't needed), but in this particular case it wouldn't help anyway: When promptForSaveToFileAsync is called (https://dxr.mozilla.org/mozilla-central/rev/b07db5d650b7056c78ba0dbc409d060ec4e922cd/mobile/android/components/HelperAppDialog.js#324), on my phone (Android 6.0.1) aSuggestedFileExt was empty anyway. This is because our attempts to get a corresponding extension for a MIME type I think end up here (https://android.googlesource.com/platform/libcore/+/master/luni/src/main/java/libcore/net/MimeUtils.java), which only knows "text/rtf" - the server however claims these files to be "application/rtf".

Comment 6

[Mike Taylor [:miketaylr]]

Roger that, thanks for the great explanation.