Please provide the net internals log using the steps in:
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

We don't actually need net-internals for this - that raw listing should be enough.  Hrm...I don't see anything obviously wrong with it, it largely matches the format we expect from POSIX FTP servers.

From dir-listing-ls-16:

dr-xr-xr-x   1 owner    group               0 Nov 28  2008 documentales
dr-xr-xr-x   1 owner    group               0 Nov 28  2008 dosier
dr-xr-xr-x   1 owner    group               0 Dec  1  2008 promos
dr-xr-xr-x   1 owner    group               0 Nov 28  2008 Sue os_futbol
dr-xr-xr-x   1 owner    group               0 Nov  2 15:53 test
dr-xr-xr-x   1 owner    group               0 Nov 25 10:04 tmp
-r-xr-xr-x   1 owner    group             125 Oct 11  2007 Gastronom a.txt

The problem is the following line:

-rwxr--r--   1 user     group  791127648 Jun 31 23:30 icewarp-12.0.2.0_x64_20170601-0129.exe

June only has 30 days, but the listing claims that file was modified on June 31, so our code to try and identify the format of each column fails when it gets to that line.  If this were a common problem, might be worth looking into a workaround for this sort of behavior, but as-is, I don't think it's worth the investment to hack around servers with this particular bug.

I don't want to spend time with that issue too, but I just want to point out, that you are incorrect, because that date is perfectly valid and if you don't think so, then you can file a bug report against the filesystems that enable those dates or change the error message for handling those situations or change the code that tries and identifies the format of each column, because real world June has nothing to do with modification date June. 

The date is not valid.  There is no such day as June 31 on the Gregorian calendar.  If the time was really July 1, then it should display July 1.  If we accepted invalid dates everywhere on the web platform, everyone else would, too, and since this is the only bug report we've had about this in the last 5 years, this does not seem to be a common problem.  Supporting everyone else's one-off bugs means everyone else has to as well, and basically breaks all specs.

If I were you, I'd just change the modification date on that file, file a bug against whatever OS is responsible, and call it a day.

Correction - I believe we tightened up our date parsing about a year ago, and this is the second bug I've seen filed about it, though the other was about a Flash unit test.  Anyhow, still a WontFix.