Change file download action

[Gregg Orangio]

Saving the configuration of my wireless router causes the download of a file named SETTINGS.CFG which contains non-printable data (binary). I expected that this file would be saved into the downloads folder, but it is instead displayed in the browser window. In various forum postings I have found that there is/should-be a Chrome setting for ‘Clear auto-opening settings’ which would be used to change this action. However this setting option does not exist on my system as the "Downloads" settings section includes only the download location and "Ask where to save each file before downloading"  (see attached screen-grab). I've also checked the Preferences file and found the "downloads" section to include only the following, nothing obvious that may apply to this problem:

   "download": {
      "default_directory": "/Users/gregg/Downloads",
      "directory_upgrade": true,
      "prompt_for_download": true
   },

How can I change this so that the .CFG file can be saved directly to a file?

--

[Torne (Richard Coles)]

There aren't any configuration options for whether to display files in Chrome or download them. The auto-opening settings only dictate what happens to files that are downloaded *after* the download completes.

Unfortunately this is the router's fault: unless the web server tells the browser otherwise, browsers will simply display any file type that they know how to display directly in the browser, and will only download unknown file types. If this file is being displayed then probably the server is sending it with a text file type. If the server intends for this to be a download it should set the header "Content-Disposition: attachment" which causes browsers to treat them as downloads.

You can work around this by selecting "Save page as" from the chrome menu to save it as a file; it will be saved correctly even if it doesn't look readable.

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Gregg Orangio]

Thanks for the response @Torne.

I get your point about the data being downloaded, however the control of the destination of that data is my point. There is a difference between the data being displayed versus it stored in a file with my choice of names (ie. "Save As"). So this is not completely under the control of the server. Rather it is controlled by the method used by the browser.   For example, I tested this same operation using Firefox. That results in the "Save As" panel popup offering to save the file into the "downloads" folder.

My understanding was that it is dependent upon the browser's configuration for handling the ' Content-Type' or MIME type.  In this case that is "text/txt". Right or wrong, this 'server' does not send the 'Content-Dispatch' header.

One additional complication is that this operation is started by a button. Your suggested "Save As..." technique does not work with a button since that saves the HTML page not the downloaded data.  "Save As..." could be used AFTER the data is displayed within the browser window. But since there are "unprintable characters" in the data, that does not work because they get converted/changed.

--

[PhistucK]

Browsers are free to display text/* files, I believe, so it is not a non compliant behavior and it does sound like the fault of the server (it is not text, obviously).

Perhaps Firefox has some heuristics that make it save the file instead of displaying it (for example, some special characters or sequences), or perhaps it gets a slightly different headers or response (have you checked that?) that make it save the file.

By the way, what does Internet Explorer do (if it is available to you for testing)?

Note - generally, you can fix it for yourself using an extension that modifies the response headers (I think the webRequest API allows that, not sure, though), or blocks the response and otherwise saves the content.

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[Gregg Orangio]

Yes, IE8 prompts to save the downloaded data into a file (ie "Save as").

I thought that the Content-Type header was a MIME type specification and that browsers used that to determine the action. But apparently that is not the standard.

Thanks to all as your responses led me to an extension that looks to be the basis for defining exactly what I expected. See @Ori's answer in 

“View As MIME Type” in Chrome or Firefox and his extension Force Media-Type.  I just have to work out "the button issue", ie making this work when a button is used activate the download.

--

[Torne (Richard Coles)]

Browsers use the mime type given in the Contebnt-Type header to determine whether they *can* display the content, and Content-Disposition to determine whether they *should*. In the absence of a content disposition, they display anything they can, and download anything else. So yes, you are right, but that's not the whole story.

Chrome considers all text/* mime types to be displayable with a few specific exceptions such as text/csv and text/vcard. Other browsers may have a specific white list of which text types they will try to display and will not attempt to display unknown types like text/txt (which is not a registered mime type). There isn't any standard which says which mime types should be treated which way as far as I know, nor could there be really (for example, a browser without a PDF viewer can never render application/pdf no matter what any spec or header tells it to do).

[Torne (Richard Coles)]

Also, if "Save page as" does not save the file correctly that sounds like a bug to me; I would expect us to save the bytes we got from the network exactly as we received them, regardless of how they were displayed.

[Christian Biesinger]

I think the issue with "Save Page As" not working right is because
they chose "Web Page, Complete" as the file type in the file picker.
As that one serializes the DOM it will not do the right thing.
Choosing "Web Page, HTML only" should save the exact bytes we got.

Though for text we should be smart enough to always do the latter?

-christian

On Thu, Apr 23, 2015 at 5:43 PM, Torne (Richard Coles)

[Torne (Richard Coles)]

Yeah, if the document was plain text we should not even offer saving it the other way I think.

[Gregg Orangio]

Torne,

Thanks, this makes sense to me as a standard and what I was expecting. Since my router does not conform to this "standard" with either of the response headers, I need to determine some alternative to handle it.

Although what I was expecting the browser(s) would do is provide a method of defining operations either a) for all data downloads or b) for specific MIMEtypes/Content-Types. So getting back to my OP, there "used to be" an Chrome option/setting for ‘Clear auto-opening settings’. That implies to me a possible solution. However I still dont know why Chrome v42. does not include that setting and if it applies to my request.

--

[PhistucK]

It does not apply to your request. Automatic opening of files applies to files downloaded for saving (not downloaded for viewing, like HTML documents). Your file is downloaded for viewing (due to its text/* MIME type), not for saving.

☆PhistucK