Bad request if charset in content-type header

[Wes Mason]

If you set a charset in the content-type header of a request to any method in the API, which is a perfectly valid part of the Content-Type HTTP header, then the request automatically fails with a 400 response (and a plaintext response body, not JSON), e.g.:

POST /api/v2/requests/validate HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate, compress
Content-Length: 82
Content-Type: application/json; charset=utf-8
Host: login.ubuntu.com
User-Agent: HTTPie/0.8.0

{
    "authorization": "blah",
    "http_method": "get",
    "http_url": "http://example.com/"
}

HTTP/1.1 400 BAD REQUEST
Connection: close
Content-Encoding: gzip
Content-Language: en
Content-Length: 31
Content-Type: text/plain
Date: Mon, 13 Oct 2014 09:46:59 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Authorization,Accept-Language,Cookie,Accept-Encoding
X-Frame-Options: SAMEORIGIN
strict-transport-security: max-age=15552000; includeSubDomains
x-content-type-options: nosniff
x-xss-protection: 1; mode=block

Above I use "; charset=utf-8" on the end of the content-type to inform the upstream service that my request is also UTF-8 codebooked, if I just provide "application/json" as the content-type however the request works as documented.

[Daniel Manrique (roadmr)]

$ curl -X POST https://login.ubuntu.com/api/v2/requests/validate -H "Content-Type: application/json; charset=utf-8" -d '{"authorization": "blah"}'
* upload completely sent off: 25 out of 25 bytes
< HTTP/1.1 200 OK
< Date: Tue, 08 Oct 2019 15:09:03 GMT
< Server: gunicorn/19.3.0
< Content-Length: 57
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< Content-Language: en
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< Vary: Authorization,Accept-Language,Cookie
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/json; charset=utf-8
< X-Bzr-Revision-Number: 1697
< X-Request-Id: (null)1
<

{
    "is_valid": false,
    "account_verified": false
}