Re: [RFC 2/3] [gdb/dap] Allow Content-Length on separate line

[Tom de Vries <tdevries@suse.de>]

On 3/14/23 15:13, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Tom> Also allow:
> Tom> ...
> Tom> Content-Length: 54
> 
> Tom> {"seq": 1, ...}
> Tom> Content-Length: 163
> 
> Tom> {"seq": 2, ...}
> Tom> Content-Length: 136
> Tom> ...
> Tom> which makes command files a bit easier to read.
> 
> Doesn't this violate the XML-RPC protocol?  The issue being that the
> header is terminated by a blank line, but now this ignores the blank
> line.  Though of course it's also bad to not have a Content-Length.

OK, let's try the example from here ( 
https://microsoft.github.io/debug-adapter-protocol/overview ), two after 
each other, as confirming DAP:
...
Content-Length: 119\r\n
\r\n
{ "seq": <n>, ... }Content-Length: 119\r\n
\r\n
{ "seq": <n>, ... }
...

What I'm proposing with this patch allows in addition:
...
Content-Length: 119\r\n
\r\n
{ "seq": <n>, ... }\r\n
Content-Length: 119\r\n
\r\n
{ "seq": <n>, ... }
...

So the \r\n that terminates the header is still there.

And the blank line (^\r\n) that separates header and content is still there.

Whether this is still confirming DAP, I can't tell from the specification.

I can imagine that it makes sense for GDB to be as strict as possible to 
flush out problems in actual clients.

OTOH, the mock-up client we create by feeding a text file into gdb 
doesn't actually need to conform to DAP, and there's something to win by 
making this text file easy to read and edit, which is what the goal of 
this patch is.

So, perhaps we want to enable this selectively, say with a setting 
dap-parse-strict, and perhaps have some "set dap-cmd-input gdb.in" that 
automatically sets dap-parse-strict to 0.

Alternatively, we could move this into the command-sphere and do 
something like:
...
interpreter-exec dap-wrap { "seq": <n>, ... }
...
and let dap-wrap take care of adding a header with the correct size.

But this all might be overkill, I'm not sure.

Thanks,
- Tom