The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c5c1a790acc423f359c22641ac2ab0f3f9e6d7a9

commit c5c1a790acc423f359c22641ac2ab0f3f9e6d7a9
Author: ricea <ricea@chromium.org>
Date: Fri Jul 15 05:26:18 2016

Make calling SetHeader() with invalid value fatal

crrev.com/2134083003 made net::HttpUtil::IsValidHeaderValue() reject
individual CR and NL as well as CRNL.

I believe that all callers of net::HttpRequestHeaders::SetHeader() and
SetHeaderIfMissing() which use user-supplied values already verify the
value with IsValidHeaderValue() first. However, to be sure, temporarily
make it a fatal error to call SetHeader() with an invalid value.

If you see a crash attributed to this CL:

1. Associate it with the bug.
2. Follow the stack flow to work out how untrusted data ended up
being passed to SetHeader().
3. Add a call to IsValidHeaderValue() at the point where the untrusted
data was introduced. A tighter check such as IsToken() may be appopriate.

BUG= 627398 

Review-Url: https://codereview.chromium.org/2143903002
Cr-Commit-Position: refs/heads/master@{#405702}

[modify] https://crrev.com/c5c1a790acc423f359c22641ac2ab0f3f9e6d7a9/net/http/http_request_headers.cc

This is live in canary. No crashes so far. We should have more confidence once it goes to the dev channel.

Non-update: this is live in dev. No crashes so far. I will leave it another week then revert and close this bug.

Update: we have 12 crashes. I found this bug:  Issue 634225 

Only one other root cause so far:  issue 634234 

I spoke too soon. One more:  issue 634263 . There's no known root cause for this one, and I suspect memory corruption.

Issue 638117 is another. Garbage In Garbage Out for Cookie headers.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6c2cdfb89375fe0734615bd8081283d25fb0aad5

commit 6c2cdfb89375fe0734615bd8081283d25fb0aad5
Author: ricea <ricea@chromium.org>
Date: Fri Aug 26 02:29:04 2016

Revert of Make calling SetHeader() with invalid value fatal (patchset #1 id:1 of https://codereview.chromium.org/2143903002/ )

Reason for revert:
This CL has served its purpose of finding bad callers of SetHeader() and should be reverted before the branch point.

Original issue's description:
> Make calling SetHeader() with invalid value fatal
>
> crrev.com/2134083003 made net::HttpUtil::IsValidHeaderValue() reject
> individual CR and NL as well as CRNL.
>
> I believe that all callers of net::HttpRequestHeaders::SetHeader() and
> SetHeaderIfMissing() which use user-supplied values already verify the
> value with IsValidHeaderValue() first. However, to be sure, temporarily
> make it a fatal error to call SetHeader() with an invalid value.
>
> If you see a crash attributed to this CL:
>
> 1. Associate it with the bug.
> 2. Follow the stack flow to work out how untrusted data ended up
> being passed to SetHeader().
> 3. Add a call to IsValidHeaderValue() at the point where the untrusted
> data was introduced. A tighter check such as IsToken() may be appopriate.
>
> BUG= 627398 
>
> Committed: https://crrev.com/c5c1a790acc423f359c22641ac2ab0f3f9e6d7a9
> Cr-Commit-Position: refs/heads/master@{#405702}

R=mmenke@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 627398 

Review-Url: https://codereview.chromium.org/2268423004
Cr-Commit-Position: refs/heads/master@{#414633}

[modify] https://crrev.com/6c2cdfb89375fe0734615bd8081283d25fb0aad5/net/http/http_request_headers.cc

The fix never made it to the stable branch. This is causing crashes in stable: see issue 666845.

Merging would be trivial and safe.

[Automated comment] Request affecting a post-stable build (M54), manual review required.

Adding TE-NeedsTriageHelp as its out of scope from TE end.

M55 has shipped. The fix was already in M55, so there is no longer anything to do here.