This is RFC 7231 Section 3.1.1.1.  Note that parameters can be preceded by OWS (see definition of |media-type|), so it is okay to trim leading whitespace, but within |parameter|, the token is immediately followed by "=", so trailing whitespace must not be trimmed.

Looks to me like we should also make it so the charset of "text/html;charset= gbk" is interpreted as " gbk".  i.e., only remove leading/trailing whitespace from either size of the semi-colon separated string, and keep them on either side of the "=".

Note that for '...= gbk' and '...=" gbk"' you still need to end up with GBK due to https://encoding.spec.whatwg.org/#concept-encoding-get. https://github.com/w3c/web-platform-tests/pull/7764 has tests for that, but it's not tracked by any specific MIME Sniffing issue (most browsers don't seem to trim whitespace for the double quoted case, but it seems wrong not to reuse that code path).

Is there a motivation for that?  Seems rather unexpected.

And by "that" I mean the mismatch in behavior for the key and field.  Seems like a recipe for differing behaviors between implementations.

I don't know why HTTP is the way it is. For now I've been assuming that anything it considers valid browsers want to consider valid input as well.

The whitespace stripping for the field/value is specific to the charset key and does not generally apply. That's just how we handle "charset" values throughout the platform, we strip whitespace and then match (per the algorithm I pointed to).

Trimming leading whitespace from the parameter name is contrary to the specification.  RFC7231 Section 3.1.1.1 explicitly states that "Unlike some similar constructs in other header fields, media type parameters do not allow whitespace (even "bad" whitespace) around the "=" character.".

What is the relationship between https://encoding.spec.whatwg.org and RFC7231?  Does the former supersede the latter?  Or is it a path to a future erratum to the RFC?  I would like to make Chrome do the right thing, but I am not sure I agree that an in-progress specification is more the right thing than a published RFC.

I'm not talking about the parameter name. I'm saying that eventually the value of the parameter whose name is "charset" should end up being trimmed per the algorithm I pointed to. (That doesn't happen in the HTTP layer most likely.)

Sorry for the confusion caused.

I see.  So in general, leading whitespaces should not be removed from parameter values.  At some other point in the code (which in Chromium happens to be in the same HttpUtil::ParseContentType() method) leading whitespaces shall be trimmed from the value of "charset", and also the optional double quotation marks.  Okay, I can do that.

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

commit c0399701530ae196c656e644d19646e88cfa58af
Author: Bence Béky <bnc@chromium.org>
Date: Tue Nov 14 17:48:23 2017

Modify whitespace trimming for MIME parameters.

* Do not trim trailing whitespace from MIME parameter names.
* Do not trim leading whitespace from MIME parameter values.
* Except keep trimming leading whitespace from "charset" value.

Bug:  772834 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Ie7f5bc493ea0c8fece9a6a8159b27c85bb58ac2b
Reviewed-on: https://chromium-review.googlesource.com/763667
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Bence Béky <bnc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516348}
[modify] https://crrev.com/c0399701530ae196c656e644d19646e88cfa58af/net/http/http_util.cc
[modify] https://crrev.com/c0399701530ae196c656e644d19646e88cfa58af/net/http/http_util_unittest.cc