The Content-Type field in the header part is not supported

[micbou]

Consider the following Python 3 script that starts the server and sends the initialize request with the Content-Length and Content-Type fields as specified by the protocol:

import json
import os
import subprocess

DIR_OF_THIS_SCRIPT = os.path.abspath(os.path.dirname(__file__))

env = os.environ.copy()
env['RUST_LOG'] = 'rls=trace'
handle = subprocess.Popen(['rls'],
                           stdin=subprocess.PIPE,
                           stdout=subprocess.PIPE,
                           env=env)

content = {
  'id': '1',
  'jsonrpc': '2.0',
  'method': 'initialize',
  'params': {
    'processId': os.getpid(),
    'rootPath': DIR_OF_THIS_SCRIPT,
    'rootUri': DIR_OF_THIS_SCRIPT,
    'capabilities': {}
  }
}
data = json.dumps(content)
request = ('Content-Length: {0}\r\n'
           'Content-Type: application/vscode-jsonrpc;charset=utf8\r\n'
           '\r\n'
           '{1}'.format(len(data), data))

handle.stdin.write(bytes(request, encoding='utf8'))
handle.stdin.flush()
handle.stdout.read()

Running this script will output:

DEBUG:rls::server: Language Server starting up. Version: 0.122.0-nightly (93b47d1 2017-09-25)
TRACE:rls::server::io: reading: 238 bytes
TRACE:rls::server: Read message `
{"id": "1", "jsonrpc": "2.0", "method": "initialize", "params": {"processId": 12464, "rootPath": "C:\\Users\\micbou\\tests\\ycmd-rust-language-server", "rootUri": "C:\\Users\\micbou\\tests\\ycmd-rust-language-server", "capabilities": {}`DEBUG:rls::server: parsing error, Error { code: ParseError, message: "Parse error", data: None }
TRACE:rls::server::io: response: "Content-Length: 75\r\n\r\n{\"jsonrpc\":\"2.0\",\"error\":{\"code\":-32700,\"message\":\"Parse error\"},\"id\":null}"
DEBUG:rls::server: Server shutting down

The issue is that the code assumes that the header part of a request only contains the Content-Length field, which is not the case.

[ggilmore]

I'd like to chime in and point out that not handling this field causes the body of any request to be incorrectly parsed (since there are 2 newlines separating the content-length header and the body, not only one since the content-type field is present). Any client that sends this field will run into this issue.