[rabbitmq-discuss] Cannot send message with STOMP

[Lionel Cons]

Steve Powell writes:
 > The STOMP 1.0 specification is unsatisfactory in many respects, [...]

Indeed. This is what triggered the creation of 1.1.

 > The STOMP 1.1 specification has drawbacks of its own -- [...]

Although I agree that 1.1 is not perfect (so I'm sure we will see 1.2
or 2.0 one day), I do not share your view on the points you mention.

 > the rather arbitrary notion of escaping colons in header values as
 > well as names (why?) [...]

Without backslash escaping, header names and values would have been
limited. This quite simple escaping removed this restriction.

 > and the insistence of UTF-8 for all header names and values [...]

Here again, without this in the spec, the headers would have been
limited to basically US-ASCII. Some users (us included) do need
more. This widely used encoding allows any text string in the header.
Icing on the cake: it's backward compatible with 1.0 and transparent
to implementations using only US-ASCII.

 > So I think it is _incorrect_ in that it specifies a considerable
 > superset of what you can receive (or are allowed to send) over the wire.

The BNF indeed allows more than what the protocol accepts. The best
solution is probably to ignore the BNF and only implement what is in
the protocol text. After all, it's probably two orders of magnitude
shorter than AMQP 1-0 ;-)

 > I'm going to raise a bug [24896] to track this, and propose the
 > following solution:

Thanks.

 > We use the negotiated connection type to determine the parsing rules
 > (and generating rules) for frame headers.

Perfect.

 > For 1.0 connections we will allow OCTET streams for header names and
 > values, excepting colons in names, and excepting newlines (\u000A
 > newline character coded in UTF-8 is x'0A') anywhere, and do NO escaping
 > either on input or output. We will reject no headers on input unless
 > they do not contain a colon before the first newline (because they
 > cannot be malformed under these rules) though the remaining frame
 > parsing can fail.

Maybe you also want reject empty header names (e.g. SEND\n:foo\n\n\0).
This is arguable.

 > For 1.1 connections we will allow OCTET streams for header names and
 > values, excepting colons, newlines and backslashes, interpreting escape
 > sequences for these, and generating escapes for these characters on
 > output. We will NOT reject non-UTF-8 OCTETs but instead just pass them
 > through asis in order to allow the simplest client access. We will NOT
 > reject other escapes (\ followed by non c, n or \), but leave these
 > asis.
 > 
 > Although this is not strictly what the spec says (we would not enforce
 > UTF-8 or the errors on bad escape sequences) I believe it is a
 > reasonable compromise.

Fair enough.

IMHO, the main point is that RabbitMQ should accept any valid STOMP
1.1 input. Your proposed solution seems address this point.

If you also accept invalid input, this should not be a problem in
practice.

Thanks for your work improving RabbitMQ's STOMP support.

Cheers,

Lionel