Tested this issue using #59.0.3071.115 on Win 10, Mac 10.12.5 and Linux Ubuntu 14.04 and was able to reproduce the issue.

Note:
1. This issue seems to be a Non-Regression issue as same behavior is seen since M45. Hence untriaged the issue to get more inputs from Dev.
2. This issue seems to be a site specific issue as same behavior is seen in Fire fox too
3. Issue is seen in latest M61 as well.

Please refer the screenshot.

Thanks!!

Deleted: Screen Shot 2017-07-05 at 11.57.51 AM.png 249 KB

	Screen Shot 2017-07-05 at 11.57.51 AM.png 249 KB View Download

Download an login works without problems with:
Internet Explorer 11
Opera 12
and
wget 'ftp://test:tE5T!12345@labs.gwendragon.de/a.mkv'
curl 'ftp://test:tE5T!12345@labs.gwendragon.de/a.mkv' -o a.mkv
w3m 'ftp://test:tE5T!12345@labs.gwendragon.de/a.mkv' 

Works with 
winscp ftp://test:tE5T!12345@labs.gwendragon.de/a.mkv

Opens without problems on these:
Windows 10 x64
vlc.exe ftp://test:tE5T!12345@labs.gwendragon.de/a.mkv
ffprobe.exe ftp://test:tE5T!12345@labs.gwendragon.de/a.mkv
ffplay.exe ftp://test:tE5T!12345@labs.gwendragon.de/a.mkv

Debian 8.8 x64
Konqueror 4.14.2 
Firefox 52.2

Hrm...We're correctly using the entered credentials, and getting the response body.  If you go to other files on the site, it works fine (Like ftp://test:tE5T!12345@labs.gwendragon.de/a.html).  So I think this is media playback + ftp URL with credentials in it.

We issue a request, get the media mime type and response body, pass that to the media code, and then the media code issues another request without credentials.

Media guys:  You have any idea what happens to the credentials here?

(And yes, I have verified the network stack sees two requests from the renderer, one with the credentials, and one without.  We prompt for credentials in response to the credential-less URL)

Hmm, I guess I didn't think ftp + video was a supported thing, but I see that other browsers support it.

I thought these kind of credentials were handled similarly to cookies.
By the time the media code gets the URL, the username/PW has been stripped off, or we would just send it back as is. My assumption is that the credentials gets associated with the WebFrame, but I don't know why they don't get added on to the request when we make it...

When credentials are entered by the user, the network stack tracks and adds them to requests as needed.  When they come from a URL, however, we don't.

I consider this a pretty low priority feature (We don't even support FTP for subresources anymore), so may just be a WontFix.

[+mkwst] who removed FTP for subresources, and may have thoughts on using FTP for anything other than downloads / directory listings.

Seems to be WAI:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp?rcl=5946acdc3a28c62847b18991fe06f86e631a40c1&l=1220

Not sure why though.

Testing with other browsers, IE doesn't do anything.  FireFox downloads it to a file, rather than playing it.  FireFox still renders the HTML file, though, so can't just disable MIME sniffing for FTP entirely, unfortunately (Well, without breaking compat, at least).

I've been working on the assumption that we'd eventually like to move FTP support out of Chrome, into some sort of helper. We're also looking skeptically at embedded username/passwords, which we're now blocking for subresource loads, and have been thinking about blocking for top-level navigations as well (the numbers are super low, but the folks who use the feature are vocal, so, it's tough to measure the actual impact).

I suspect that this is both related to the code hubbe@ pointed to, and to our implementation of the media playing widget, which basically rewrites the MKV file into an HTML page that contains a `<video>` element which embeds the MKV file. It acts as a subresource, so it's affected by the subresource-blocking code mmenke@ mentioned above.

I'd suggest that this is WAI, with the caveat that I'd be even happier if we just downloaded resources from FTP sites rather than rendering them as webby resources. Given the numbers for Navigation.MainFrameScheme and Navigation.MainFrameSchemeDifferentPage, FTP navigation is very uncommon (0.0013% of the former, 0.0028% of the latter over the last 28 days).

This is not intended to work, and as such, I'm not going to fix it.

Actually, no we should probably just make the file download, but how?

Handing off to mkwest@ feel free to delegate further... :)

We could either non-mime sniff FTP files, or only mime sniff them text/* or image/* formats (And if there are any other mime types we don't load as a subresource when they're navigated to, includes those as well).  We currently don't have any scheme-specific mime sniffing logic, so that solution seems kinda funky.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot