Writing a null character at the end of TCP payload

[coulas]

I need to send a null character at the end of a message on a tcp output...
But this null is considered to be an end of string.

My use case is sending a GELF message to a graylog's tcp input.
GELF message is a json syntax quite simple to comply with thanks to format-json.
Graylog needs a null character at the end of a GELF message in TCP but not in UDP.

I tried many combination in the template with \x0, echo \x0, global_definition_of_null, etc...
The matter is that null character when interpreted is an end of string, and is not written in the tcp message.
I see truncated messages with ngrep.

Gelf Specification is not clear about it, but I have tested it
After finding a clue in Graylog's issues

In syslog-ng's mailling list, we have seen three options with Balazs Scheidler and Gergely Nagy :

1. the creation of $(format-gelf) which would solve both the NUL issue and makes it easier for someone else to create GELF output
2. add an option to $(format-json) to add a suffix (and perhaps a prefix) in front of and after the resulting string
3. $(char 0) as a template function? That can be reused outside
   of format-json

A format-gelf as in 1 is missing, but my case and other may be satisfied with a template function that writes raw characters as in solution 3

[algernon]

Instead of $(char 0), we should name it $(literal), and it would take a string, not just a char.

[algernon]

In the long run, we'll have proper gelf support (which would be more than just $(format-gelf), since we want to support Chunked GELF too). Until then, I'll go with $(literal), which would be option 3, but a little bit more flexible.

[coulas]

I agree with $(litteral "x0"), it seems good to me.
Thank you. 👍

[algernon]

Right. This is going to be harder than it first seemed, because even if we manage to append a NULL character to the string, and the GString's length is correct too, we end up using result->str somewhere down the line, and that does not handle embedded null-chars.

So $(char 0) is not implementable at the moment, neither is $(format-json --append-suffix) for the same reason.

To be able to implement this feature, we need to teach templates to handle embedded NULLs.

[juhaszviktor]

As far as I saw, the problem is that the parser eliminates the NULL character. If the compiled template somehow contains the NULL character it will be contained in the formatted template's result.
So I think the $(literal "x0") or the $(char 0) should be work.