Specify charset=UTF-8 when serving non-base64 files

[gnestor]

Closes #2397

[takluyver]

This handles the fallback case where we don't find a mimetype for a file. Do we also want to do the same if guess_type returns text/plain as the mimetype of e.g. a .txt file?

[digitalresistor]

@takluyver does mimetype return the charset for a file? I wouldn't think it would, but for text/plain sending charset=utf-8 wouldn't be that bad of a guess in most cases.

When you have a .txt file and click on it in the browser, you open up an editor that correctly shows the contents as a UTF-8, it is only when you download the raw file at the moment, for example when you rename a file with UTF-8 characters within it to somefile.log for example, because that won't cause the editor to be opened when clicked.

[gnestor]

@takluyver It sounds like a good idea to me. Does that look right?

[takluyver]

Thanks, that looks good. There's a test failure, though, because we have a test that expects text/plain:

FAIL: make sure ContentsManager returns right files (ipynb, bin, txt).
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\notebook\notebook\tests\test_files.py", line 98, in test_contents_manager
    self.assertEqual(r.headers['content-type'], 'text/plain')
AssertionError: 'text/plain; charset=UTF-8' != 'text/plain'
- text/plain; charset=UTF-8
+ text/plain

I don't think mimetype - or anything in the standard library - does encoding detection.

[gnestor]

Ok, tests are passing! Let's wait to see if these resolves #2397 before merging...

[digitalresistor]

This resolves the issue for me and log files are now downloaded correctly.