gianni.leuani@ Thanks for the issue.

Please provide us any sample test file or URL to reproduce the issue from test team end.

Thanks,

"Please provide any additional information below. Attach a screenshot if
possible."

1) Startup Chrome
2) Put "ftp://localhost:12055" into Chrome's address bar, hit enter
3) Ftp server on local pc, listening on port 12055 receives the following commands from Chrome:
fromChrome: USER anonymous
fromChrome: QUIT
fromChrome: USER jrm
fromChrome: PASS sect
fromChrome: SYST
fromChrome: PWD
fromChrome: TYPE I
fromChrome: SIZE \
fromChrome: CWD \/
fromChrome: EPSV
4) At this point, Chrome SHOULD BE in passive mode, and is requesting the ftp server to open a receiving port to receive incoming data.
5) Chrome now sends this command to the ftp-server
fromChrome: LIST -l

6) Chrome ALSO CONNECTS TO THE REQUESTED PASSIVE PORT SOCKET. I can tell because the thread that handles the "LIST -l" command waits for the ServerSockt to accept a connection before proceding.

7) ftp-server sends back the response "150 Listing"

8) ftp-server lists out the following on THE REQUESTED PASSIVE SOCKET:
07-05-16 02:31PM <DIR> folder1
07-05-16 02:41PM <DIR> folder2
07-05-16 02:51PM 12 file1.txt
07-05-16 02:51PM 274 file1.txt

9) Somehow.... Chrome doesn't understand something this simple and reports this error:
"Oh, no! This server is sending data Google Chrome can't understand. Please report a bug, and include the raw listing."

Please... what other undocumented "magical" data is Chrome expecting that standards-complient ftp-servers are supposed to be sending to make Chrome happy.

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

There isn't actually a FTP standard directory listing format.  FTP servers generally just use the format that you get from a local command prompt on that particular OS, and hope the client can parse it (The format was originally meant to be read directly by users, hence the lack of any documented directory listing format).

You've pasted what looks to be responses in two very different formats.

In the original post, you've pasted things that look like "file1.txt 23 2017/06/29 11:45.32".  I don't believe I've ever seen that format before.

In comment #3, you posted something that looks more like a standard response from a Windows FTP server.  Is that the entire listing?  It looks like something that Chrome should handle.

Also, are you implementing your own FTP server, or are you using a standard software package?  Given the difference in the two response formats, I'm assuming it's your own?

Yes, your assumption is correct. I'm creating my own ftp server as a Java
app. (easier to code/debug in Java first, then transfer the logic directly
to an Android app)  Theoretically, I could use a standard software package,
but in my experiences there would end up being a "gotcha" later on. (one of
the many reasons why Android is based on a re-implementation of Java rather
than being owned by Sun Microsystems or Oracle).

The responses are being sent across a Printstream object wrapped around the
original connecting socket.  And the listing data ends up being sent across
another Printstream object wrapped around the requested passive socket.  I
can see that Chrome was requesting binary mode with the TYPE I request, but
it would also make sense that Chrome should still read from whatever the
Printstream was sending to Chrome.

The binary mode should be irrelevant.  Could you paste the entire text of a response, and I'll see if I can figure out why it can't be parsed.  Given that FTP is a legacy protocol, we aren't much interested in improving support of it, but hopefully I can at least point out why we can't parse it.

Our Windows FTP directory listing code can be found at https://cs.chromium.org/chromium/src/net/ftp/ftp_directory_listing_parser_windows.cc, if you're curious.

Also, what error are you seeing, exactly?  It could either be a network error due to an error parsing the response as a valid FTP response (Which would result in a page like chrome://net-error/-2, only with a more exciting error code, or a directory parsing error, which would load the FTP display javacsript, but then display an error on top of that.

Hang on, I think I have something.  Does Chrome not like it when I try to
print out individual parts of a line? I was trying to capture everything to
a single buffer and Chrome finally listed everything out if I pack
everything to a buffer instead of letting Chrome wait until it receives the
newline indication.
My code was doing:
prt.print(dateVal+"\t");
if (f.isDirectory() {
   prt.print("<DIR> \t");
} else {
   prt.print(f.length()+"\t");
}
prt.println(f.getName());

Adding TE-NeedsTriagehelp as the issue related to ftp server.

It shouldn't matter - rather than using a streaming parser, we wait until we have the entire list before we do any parsing.  If printing it out all with a single print command fixed the issue, I suspect there's some problem with the actual output on the socket when you're using print calls.  You may want to use Wireshark to see just what you're sending.  Anyhow, doesn't sound like a Chrome issue to me.

Going to go ahead and close this as WontFix - the issue seems to be the server.  If wireshark (Or about:net-internals by byte logging enabled) seems to show otherwise, I'll reopen.