Escaping/unescaping special chars from headers

[leandrogaspar]

Draft for #77. I still have some doubts about it.
The issue is about escaping backslash, but the specification only mentions escaping "any carriage return, line feed or colon":

The commands and headers are encoded in UTF-8. All frames except the CONNECT and CONNECTED frames will also escape any carriage return, line feed or colon found in the resulting UTF-8 encoded headers.

Escaping is needed to allow header keys and values to contain those frame header delimiting octets as values. The CONNECT and CONNECTED frames do not escape the carriage return, line feed or colon octets in order to remain backward compatible with STOMP 1.0.

C style string literal escapes are used to encode any carriage return, line feed or colon that are found within the UTF-8 encoded headers.

The backslash is only mentioned on the frame headers decoding:

When decoding frame headers, the following transformations MUST be applied:

\r (octet 92 and 114) translates to carriage return (octet 13)
\n (octet 92 and 110) translates to line feed (octet 10)
\c (octet 92 and 99) translates to : (octet 58)
\ (octet 92 and 92) translates to \ (octet 92)

I do agree that escaping it makes sense but I have followed the "strict" interpretation of the spec. What are your thoughts about it?

Another point is that each spec version has some difference between what should be escaped. So, the implementation assumes that we must follow the rules from the connected version. Is this really necessary? It would be simpler to just follow the 1.2 version.

Last but not least, the webstomp-client was trimming the header values, I have removed that based on:

The STOMP 1.0 specification included many example frames with padding in the headers and many servers and clients were implemented to trim or pad header values. This causes problems if applications want to send headers that SHOULD not get trimmed. In STOMP 1.2, clients and servers MUST never trim or pad headers with spaces.

Sorry about the text wall, but the issue turned a little bit more tricky than expected 😄