Samir Halilčević
Samir Halilčević
Thanks for reporting, seems like you pinpointed the issue. Looking at the ascii table, characters from `0x00` to `0x1f` are non-printable. Regarding the bytes above `0x7f` - JSON uses UTF8...
Using `std::string` for binary data isn't very wise. Nothing in the language forces you to comply, but you have to know what you're doing. For example, try putting a zero...
I've tested this locally and the close frame didn't show up as in the description. Also, I've been trying to reproduce the fix and I don't see any difference with...
I didn't think of it, good catch. I'll update the PR once ready.
@Neverlord question regarding the `\u` escapes. According to the specs, every code point might be escaped and written as either `\uxxxx` or `\uxxxx\uxxxx`, which corresponds to the way UTF16 code...
I was prototyping this a bit and couldn't find an elegant solution. We'll probably have to touch on the deterministic mailbox implementation. Fully agree that we have more urgent tasks.
Yeah, looking at the code and the RFC we're not compliant. Shouldn't be a hard fix. The error message can only originate from the resource part in the first HTTP...
@raxyte just out of curiosity, what was the request target of the HTTP request you sent?
Thanks for the provided command. We have a different kind of issue here. We have a bug that would try processing the body of the request again if it contained...
> The `size_field_type` setup is something we can do now, but this PR is touching the DSL stuff. Since we're going to refactor that, this PR will have to wait...