[Vortex] BUG: Vortex sends messages with incorrect syntax

[Francis Brosnan Blazquez]

Hi Jens,

> Unless I'm confused, which is possible, it looks to me as though  
> Vortex sends syntactically incorrect BEEP messages. RFC 3080, sec
> 2.2,  
> specifies that messages are in MIME format, and:
> > Each frame consists of a header, the payload, and a trailer. The  
> > header and trailer are each represented using printable ASCII  
> > characters and are terminated with a CRLF pair. Between the header  
> > and the trailer is the payload, consisting of zero or more octets.
> >
> 
> Thus, in the common case where there are no headers, the message
> must  
> begin with a CRLF. Otherwise there's no way to tell whether there
> are  
> headers or not. (Consider a message with no headers whose body
> begins  
> with "Hello: Goodbye\r\n".)

You are right Jens; this is not properly implemented in Vortex. See [1]
for more details.

> But Vortex doesn't do this. The function  
> vortex_frame_build_up_from_params_s (at vortex_frame_factory:384)
> only  
> appends a CRLF if there are headers.

..it's a bit more complex. 

> The only reason Vortex can read its own messages is that the
> existing  
> header-parsing code is a hack that merely checks whether the message  
> begins with the string "Content-Type: "; if so, it assumes that's a  
> header and removes all the text up to the next CRLF. This has two  
> implications:
> (1) Anyone using Vortex to send a message whose payload begins with  
> "Content-Type:" will find that it got mysteriously deleted on the  
> receiving end.

yes

> (2) Messages sent by Vortex are unreadable by any other BEEP client,  
> since without the leading CRLF a real MIME parser will probably
> reject  
> the message as invalid (unless the payload happens to contain two  
> consecutive CRLFs, in which case everything up to them will be  
> stripped.)

yes

> (3) Messages sent by other BEEP clients are mostly unreadable by  
> Vortex, unless they happen to contain nothing but a single Content- 
> Type: header. If they contain zero or multiple headers, Vortex can't  
> parse them.

yes

> It would be trivial to fix this by making  
> vortex_frame_build_up_from_params_s always add the CRLF before the  
> payload. However, doing this will break compatibility with any
> earlier  
> builds of Vortex, due to reasons 2 and 3. This could be bad news for  
> anyone who's deployed applications already using Vortex.

..you hit the main problem. In general, MIME support inside vortex is
missing, but implementing it could break applications already deployed.

> What should we do?

I see the following points to consider while creating a solution for
this issue (more revision is required):

1) Backward compatibility must be ensured. Though MIME is a core
component of BEEP, many people do care about it. 

2) As a general approach, we lack of a VortexMessage abstraction to
represent messages. For BEEP, frames aren't MIME objects, but messages.
I'm not stating we should add this type, but I see an API consistency
issue to improve VortexFrame MIME support assuming a frame isn't a MIME
object.

3) Though it is implemented a more serious MIME support, I would
recommend to have support to disable it completely (both sides) to allow
application level to use its own MIME parsers. 

Maybe, the best approach would be to completely disable current MIME
support (through an API) allowing to take full control of MIME objects..

In any case, comments and suggestions are welcome.

> (Has anyone ever tested Vortex for compatibility with other BEEP  
> implementations?)

;-) Sure, in fact, the problem you found is something generally not
properly implemented in other BEEP implementations we tested.

Cheers!

[1]
http://drakken.dbc.mtview.ca.us/pipermail/beepwg/2006-May/001645.html

> —Jens
-- 
Francis Brosnan Blazquez <francis.brosnan at aspl.es>
Advanced Software Production Line, S.L.