Make multipart/x-mixed-replace parser more robust

Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the remainder inputs to the client as body data
if it is parsing body and the input ends with LF, although the parser
might be ought to ignore that LF in the future if it's the end-of-body.

BUG=570608
Committed: https://crrev.com/16099ee7cc1e68d6ffea2b50d4faa1763e33a6af
Cr-Commit-Position: refs/heads/master@{#382790}

[yhirano, 2016-03-18 06:45:34]

Description was changed from

==========
Fix multipart/x-mixed-replace parser.

BUG=570608
==========

to

==========
Make multipart/x-mixed-replace parser more robust

BUG=570608
==========

[yhirano, 2016-03-18 07:16:35]

Description was changed from

==========
Make multipart/x-mixed-replace parser more robust

BUG=570608
==========

to

==========
Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as 
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the reminder inputs as body data if it is parsing
body and the input ends with LF, although the parser might be ought to
ignore that LF if it's the end-of-body.

BUG=570608
==========

[yhirano, 2016-03-18 07:30:46]

Description was changed from

==========
Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as 
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the reminder inputs as body data if it is parsing
body and the input ends with LF, although the parser might be ought to
ignore that LF if it's the end-of-body.

BUG=570608
==========

to

==========
Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as 
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the remainder inputs to the client as body data
if it is parsing body and the input ends with LF, although the parser
might be ought to ignore that LF in the future if it's the end-of-body.

BUG=570608
==========

[yhirano, 2016-03-18 08:26:39]

yhirano@chromium.org changed reviewers:
+ hiroshige@chromium.org, japhet@chromium.org

[Nate Chapin, 2016-03-18 19:45:11]

lgtm

[yhirano, 2016-03-23 01:41:35]

The CQ bit was checked by yhirano@chromium.org

[commit-bot: I haz the power, 2016-03-23 01:41:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1808353003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1808353003/1

[commit-bot: I haz the power, 2016-03-23 04:21:59]

Description was changed from

==========
Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as 
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the remainder inputs to the client as body data
if it is parsing body and the input ends with LF, although the parser
might be ought to ignore that LF in the future if it's the end-of-body.

BUG=570608
==========

to

==========
Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as 
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the remainder inputs to the client as body data
if it is parsing body and the input ends with LF, although the parser
might be ought to ignore that LF in the future if it's the end-of-body.

BUG=570608
==========

[commit-bot: I haz the power, 2016-03-23 04:22:00]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-23 04:23:17]

Description was changed from

==========
Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as 
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the remainder inputs to the client as body data
if it is parsing body and the input ends with LF, although the parser
might be ought to ignore that LF in the future if it's the end-of-body.

BUG=570608
==========

to

==========
Make multipart/x-mixed-replace parser more robust

1. The parser eats leading CR, LF, CRLF and LFLF. It would be better to
eat only LF and CRLF, as other parts such as
net::HttpUtil::LocateEndOfHeaders does the same thing.

2. The parser eats leading EOLs repeatedly. For example, it eats "\n"
when "\n\nfoo" is given, but it eats "\n" twice when "\n" is given
and then "\nfoo" is given.

3. The parser sends the remainder inputs to the client as body data
if it is parsing body and the input ends with LF, although the parser
might be ought to ignore that LF in the future if it's the end-of-body.

BUG=570608

Committed: https://crrev.com/16099ee7cc1e68d6ffea2b50d4faa1763e33a6af
Cr-Commit-Position: refs/heads/master@{#382790}
==========

[commit-bot: I haz the power, 2016-03-23 04:23:18]

Patchset 1 (id:??) landed as
https://crrev.com/16099ee7cc1e68d6ffea2b50d4faa1763e33a6af
Cr-Commit-Position: refs/heads/master@{#382790}