mef: Can you help route this?

I see that 'http://wdwzqq.com.cn/test/test' indeed returns base64-encoded text without specifying Content-Type.
Chrome appears to detect base64 encoding, decode it and interpret as text/html:

<script>alert(0)</script>

I'm not quite sure that I understand security implications. 

According to the comment at the top of https://cs.chromium.org/chromium/src/net/base/mime_sniffer.cc it is working as intended:

// Detecting mime types is a tricky business because we need to balance
// compatibility concerns with security issues.  Here is a survey of how other
// browsers behave and then a description of how we intend to behave.
//
// HTML payload, no Content-Type header:
// * IE 7: Render as HTML
// * Firefox 2: Render as HTML
// * Safari 3: Render as HTML
// * Opera 9: Render as HTML
//
// Here the choice seems clear:
// => Chrome: Render as HTML

Am I missing something?

33240: URL_REQUEST
http://wdwzqq.com.cn/test/test
Start Time: 2019-01-08 16:52:12.586

t=50573 [st=  0] +REQUEST_ALIVE  [dt=812]
                  --> priority = "HIGHEST"
                  --> url = "http://wdwzqq.com.cn/test/test"
t=50573 [st=  0]    NETWORK_DELEGATE_BEFORE_URL_REQUEST  [dt=0]
t=50573 [st=  0]   +URL_REQUEST_START_JOB  [dt=812]
                    --> load_flags = 1026 (BYPASS_CACHE | MAIN_FRAME_DEPRECATED)
                    --> method = "GET"
                    --> privacy_mode = 0
                    --> url = "http://wdwzqq.com.cn/test/test"
t=50573 [st=  0]      NETWORK_DELEGATE_BEFORE_START_TRANSACTION  [dt=0]
t=50574 [st=  1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=50574 [st=  1]      HTTP_CACHE_DOOM_ENTRY  [dt=0]
t=50574 [st=  1]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t=50574 [st=  1]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=50574 [st=  1]     +HTTP_STREAM_REQUEST  [dt=582]
t=50574 [st=  1]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                        --> source_dependency = 33242 (HTTP_STREAM_JOB_CONTROLLER)
t=51156 [st=583]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                        --> source_dependency = 33243 (HTTP_STREAM_JOB)
t=51156 [st=583]     -HTTP_STREAM_REQUEST
t=51156 [st=583]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=51156 [st=583]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                        --> GET /test/test HTTP/1.1
                            Host: wdwzqq.com.cn
                            Connection: keep-alive
                            Pragma: no-cache
                            Cache-Control: no-cache
                            Upgrade-Insecure-Requests: 1
                            User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3665.0 Safari/537.36
                            Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                            Accept-Encoding: gzip, deflate
                            Accept-Language: en-US,en;q=0.9
t=51156 [st=583]     -HTTP_TRANSACTION_SEND_REQUEST
t=51157 [st=584]     +HTTP_TRANSACTION_READ_HEADERS  [dt=228]
t=51157 [st=584]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=228]
t=51385 [st=812]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                        --> HTTP/1.1 200 OK
                            Date: Tue, 08 Jan 2019 21:52:13 GMT
                            Server: Apache/2.4.34 (Ubuntu)
                            Last-Modified: Mon, 07 Jan 2019 07:16:27 GMT
                            ETag: "1a-57ed901d26e53"
                            Accept-Ranges: bytes
                            Content-Length: 26
                            Keep-Alive: timeout=5, max=100
                            Connection: Keep-Alive
t=51385 [st=812]     -HTTP_TRANSACTION_READ_HEADERS
t=51385 [st=812]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=51385 [st=812]      HTTP_CACHE_WRITE_DATA  [dt=0]
t=51385 [st=812]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=51385 [st=812]      NETWORK_DELEGATE_HEADERS_RECEIVED  [dt=0]
t=51385 [st=812]   -URL_REQUEST_START_JOB
t=51385 [st=812]    URL_REQUEST_DELEGATE_RESPONSE_STARTED  [dt=0]
t=51385 [st=812]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=51385 [st=812]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                    --> byte_count = 26
                    --> bytes = "PHNjcmlwdD5hbGVydCgwKTwvc2NyaXB0Pgo="
t=51385 [st=812]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=51385 [st=812] -REQUEST_ALIVE

To me this looks like WAI. Indeed, the standard the reporter quotes says explicitly "if and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection and/or the name extension(s)".

As a result, I'm going to close as WontFix, since this seems like a failure of a server, rather than the failure of the user agent. If the reporter has a different, more egregious example, we're always happy to revisit.