Subject: [hybi] Proposal for RLE framing and escape mechanism

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Jan 2011 09:01:30 -0500

As an outsider reading Jamie Lokier's comment on escape sequences as a
mechanism to avoid CRLF and other potentially harmful sequences.

As I understand it, the proposed framing already has the form

<opcode><length><data>

Would it be sufficient to amend it as follows:

<opcode><length><data not including unwanted characters or sequences>
<opcode representing the unwanted character or sequence><0>
<opcode><length><continuation of data not including unwanted
characters or sequences>

Timothy Meade
(real time web developer)

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 14 Jan 2011 18:55:46 +0100

> <opcode><length><continuation of data not including unwanted

In would still have a few defaults :
  - if either <opcode> or <length> encode as the CR or LF chars, you lose.

  - when sending binary data, we'd have on average 2/256 chars escaped,
    which considerably reduces the average frame length. It can come with
    a substantial frame parsing cost.

Regards,
Willy

---

From: John Tamplin <[email-masked]>
Date: Fri, 14 Jan 2011 16:51:57 -0500

> <opcode><length><continuation of data not including unwanted

This is essentially the suggestion proposed earlier to fragment frames in
the middle of dangerous sequences, with the addition of using one of the few
opcodes available to represent quoted characters.

If we are going to go down that route, I would prefer to simply define only
text framing, and choose an encoding mechanism for the text such that CR/LF
can't occur in the data (perhaps use long UTF8 sequences for them, or use
FF-quoting).  However, we are just deferring the question of how to handle
binary frames until later and not actually solving the basic problem.

-- 
John A. Tamplin
Software Engineer (GWT), Google