Hrm...I suspect something is calling GenerateAcceptLanguageHeader (which adds the q values, but doesn't expect them on its input) with "en-US,en;q=0.5".  Where in the world that string actually comes from is a far more interesting question.

[+jshin]:  Looks like you own https://cs.chromium.org/chromium/src/ui/base/l10n/, which is where the default value for this comes from, I think?  https://cs.chromium.org/chromium/src/chrome/browser/ui/prefs/prefs_tab_helper.cc?q=kAcceptLanguages+-file:test%5C.&dr=C&l=548

Of course, unclear if this is the default value or being set elsewhere - I couldn't find any q=0.5's in the codebase, but that doesn't mean anything.  Testing locally with the same version (56.0.2924.87), I look to be sending the correct "en-US,en;q=0.8" header.

Seems like something is causing the preference string to have the wrong value? Did a previous Chrome version store the quality indicator in the preference string? This might mean those need to be cleaned up somehow.

Adding Blink>Network (as opposed to internals) since this is web exposed. Can someone on the network team help route this?

I don't think we can do anything here.

I can't reproduce the issue.
The function that generates the AcceptLanguage HTTP header is called in two places: user preferences and options in headless Chrome.

In the first case, a malformed string would occur only if the user preferences have been corrupted in the past and they never changed them.

In the second case, it depends on whatever device is embedding Chrome and that is outside of what we can control.


For the first case, we could implement a sanitizer that cleans malformed user preferences, but I don't think it's worth it to deploy this and run it for all Chrome users.
I would close this bug as "cannot reproduce".

@Yana: what do you think?

Agreed. Close as can't reproduce.