FTP: correctly handle newlines in file names

FTP: correctly handle newlines in file names

This converts all .expected test files to CRLF line endings.

BUG=164724
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=172656

[mmenke, 2012-12-12 17:20:44]

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
File net/ftp/ftp_directory_listing_parser.cc (right):

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
net/ftp/ftp_directory_listing_parser.cc:98: const char* kNewlineSeparators[] = {
"\n", "\r\n", "\r" };
SplitString trims whitespace, so if |text| only has "\r\n" line breaks, it
returns identical results with "\n" and "\r\n".

Suppose servers could use CRLF line breaks, and have LFs in file names, but that
seems unlikely.

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
net/ftp/ftp_directory_listing_parser.cc:98: const char* kNewlineSeparators[] = {
"\n", "\r\n", "\r" };
If we run into a server that uses "\r"-style linebreaks, with no "total blah"
prefix, and try to parse it with "\n" style linebreaks, won't we just treat it
as one file with a really long name?

I'd like to see a test with multiple lines using "\r" line breaks.

[Paweł Hajdan Jr., 2012-12-12 18:26:19]

PTAL

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
File net/ftp/ftp_directory_listing_parser.cc (right):

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
net/ftp/ftp_directory_listing_parser.cc:98: const char* kNewlineSeparators[] = {
"\n", "\r\n", "\r" };
On 2012/12/12 17:20:44, Matt Menke wrote:
> Suppose servers could use CRLF line breaks, and have LFs in file names, but
that
> seems unlikely.

That's exactly what the bug is about. :)

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
net/ftp/ftp_directory_listing_parser.cc:98: const char* kNewlineSeparators[] = {
"\n", "\r\n", "\r" };
On 2012/12/12 17:20:44, Matt Menke wrote:
> If we run into a server that uses "\r"-style linebreaks, with no "total blah"
> prefix, and try to parse it with "\n" style linebreaks, won't we just treat it
> as one file with a really long name?

Good point. I just removed "\r" then. I haven't yet seen a server sending these
line endings (and I've done research to check as many servers as possible). We
can worry about that when it happens, not in advance.

[mmenke, 2012-12-12 18:36:12]

LGTM

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
File net/ftp/ftp_directory_listing_parser.cc (right):

https://codereview.chromium.org/11470035/diff/1/net/ftp/ftp_directory_listing...
net/ftp/ftp_directory_listing_parser.cc:98: const char* kNewlineSeparators[] = {
"\n", "\r\n", "\r" };
On 2012/12/12 18:26:19, Paweł Hajdan Jr. wrote:
> On 2012/12/12 17:20:44, Matt Menke wrote:
> > If we run into a server that uses "\r"-style linebreaks, with no "total
blah"
> > prefix, and try to parse it with "\n" style linebreaks, won't we just treat
it
> > as one file with a really long name?
> 
> Good point. I just removed "\r" then. I haven't yet seen a server sending
these
> line endings (and I've done research to check as many servers as possible). We
> can worry about that when it happens, not in advance.

Oops - didn't see the bug.