"error in process filter: Unable to find Content-Length header." over TRAMP after update to 2023.11.24

[JeremyWeed]

Thank you for the bug report

• [X] I am using the latest version of lsp-mode related packages.
• [X] I checked FAQ and Troubleshooting sections
• [X] You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

Seeing this in version 2023.11.24, rolling back to 2023.08.23 solves the issue.

error in process filter: Args out of range: "ntent-Length: 40^M
^M
{\"id\":114,\"jsonrpc\":\"2.0\",\"result\":null}Content-Length: 40^M
^M
{\"id\":115,\"jsonrpc\":\"2.0\",\"result\":null}Content-Length: 305^M
^M
{\"id\":116,\"jsonrpc\":\"2.0\",\"result\":{\"contents\":{\"kind\":\"markdown\",\"value\":\"### param `param_name`  \\n\\n---\\nType: `const char *`  \\n\\n---\\n```cpp\\n// In ClassName::FunctionName\\nconst char *param_name\\n```\"},\"range\":{\"end\":{\"character\":62,\"line\":75},\"start\":{\"character\":48,\"line\":75}}}}Content-Length: 262^M
^M
{\"id\":117,\"jsonrpc\":\"2.0\",\"result\":{\"contents\":{\"kind\":\"markdown\",\"value\":\"### type-alias `size_t`  \\n\\n---\\nType: `unsigned int`  \\n\\n---\\n```cpp\\ntypedef unsigned int size_t\\n```\"},\"range\":{\"end\":{\"character\":70,\"line\":75},\"start\":{\"character\":64,\"line\":75}}}}", 60, 16^M
error in process filter: Args out of range: "ntent-Length: 40^M
^M
{\"id\":114,\"jsonrpc\":\"2.0\",\"result\":null}Content-Length: 40^M
^M
{\"id\":115,\"jsonrpc\":\"2.0\",\"result\":null}Content-Length: 305^M
^M
{\"id\":116,\"jsonrpc\":\"2.0\",\"result\":{\"contents\":{\"kind\":\"markdown\",\"value\":\"### param `param_name`  \\n\\n---\\nType: `const char *`  \\n\\n---\\n```cpp\\n// In ClassName::FunctionName\\nconst char *param_name\\n```\"},\"range\":{\"end\":{\"character\":62,\"line\":75},\"start\":{\"character\":48,\"line\":75}}}}Content-Length: 262^M
^M
{\"id\":117,\"jsonrpc\":\"2.0\",\"result\":{\"contents\":{\"kind\":\"markdown\",\"value\":\"### type-alias `size_t`  \\n\\n---\\nType: `unsigned int`  \\n\\n---\\n```cpp\\ntypedef unsigned int size_t\\n```\"},\"range\":{\"end\":{\"character\":70,\"line\":75},\"start\":{\"character\":64,\"line\":75}}}}", 60, 16

("^M" manually added to replicate error seen in *Messages*)

Steps to reproduce

Running clangd over a remote connection, navigate to a line containing a function definition with multiple parameters, and it prints a bunch of errors. Most other LSP features work, and this error doesn't cause the server connection to drop. Seems to be a line break issue with lsp-sideline-ui preview feature with the updated TRAMP config.

Expected behavior

No errors

Which Language Server did you use?

clangd

OS

Linux

Error callstack

No response

Anything else?

No response

[juarez-gonza]

I have the same problem here. Did you find any solution?

[JeremyWeed]

Nope, no luck. Have been using the rolled-back version since I encountered this bug.

[JeremyWeed]

I've started tracking this down again. Seems the error is specifically with clangd, and other LSP servers like Pyright and json-ls work correctly over tramp after the update. I've got a suspicion it's the content of this message specifically:

{"id":15,"jsonrpc":"2.0","result":{"contents":{"kind":"markdown","value":"### static-method `parse`  \n\n---\n→ `basic_json<>`  \nParameters:  \n- `const std::basic_string<char> & i`\n- `const parser_callback_t cb = nullptr (aka const function<bool (int, parse_event_t, nlohmann::basic_json<std::map, std::vector, std::basic_string<char>, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char>>, void> &)>)`\n- `const bool allow_exceptions = true`\n- `const bool ignore_comments = false`\n\n@brief deserialize from a compatible input  \n@sa https://json.nlohmann.me/api/basic_json/parse/  \n\n---\n```cpp\n// In basic_json<>\npublic: template <>\nstatic basic_json<> parse<const std::basic_string<char> &>(\n        const std::basic_string<char> &i,\n        const parser_callback_t cb = nullptr,\n        const bool allow_exceptions = true,\n        const bool ignore_comments = false)\n```"},"range":{"end":{"character":63,"line":79},"start":{"character":62,"line":79}}}}Content-Length: 39

From the error message in *Messages*:

error in process filter: Args out of range: "ntent-Length: 39

Looks like we're parsing one too many characters out of the previous message, and missing the "C" of the next header. Given that, the → looking really suspicious.

[JeremyWeed]

Digging more, the LSP protocol spec requires Content-Length to denote the length of the message in bytes. Looking at the preceding header, Content-Length: 1054, this checks out. The message posted above is 1052 characters long, but due to the →, it is 1054 bytes in length. Currently, I'm thinking the issue is a mismatch between bytes and characters in the length value used on this function