Unable to process UserEvent

Issue still present in 0.8.3. As soon as UserEvent invoked with two parameters (eventname and body) AMI connection dies.

It seems there is no issue levels here at lighthouse so I would like to emphasize the fact that this issue is major. This is IMHO of course. But the fact is that any UserEvent with two parameters (event name + event body) executed by Asterisk dialplan immediately kills all Adhearsion applications listening for events. Adhearsion hangs reading that UserEvent and never able to read any following events.

The dialplan is like

UserEvent(justeventname);
UserEvent(eventname,eventbody);
Hangup;

Events are:

Event: Newexten
Privilege: call,all
Channel: SIP/1001-b7b1a790
Context: default
Extension: 111
Priority: 1
Application: UserEvent
AppData: justeventname
Uniqueid: 1258239297.33

Event: UserEvent
Privilege: user,all
UserEvent: justeventname

Event: Newexten
Privilege: call,all
Channel: SIP/1001-b7b1a790
Context: default
Extension: 111
Priority: 2
Application: UserEvent
AppData: eventname|eventbody
Uniqueid: 1258239297.33

Event: UserEvent
Privilege: user,all
UserEvent: eventname
eventbody

Event: Hangup
Privilege: call,all
Channel: SIP/1001-b7b1a790
Uniqueid: 1258239297.33
Cause: 0
Cause-txt: Unknown

Wow, okay, I see the problem now. This is an anomaly to the AMI protocol that I didn't foresee. At the moment only "Response: Follows" messages have bodies that follow them like that.

Fixing this will require changing the parser to expect a totally new kind of event. I can do it but I risk breaking other parts of the parser so I need to be pretty careful. Let me tinker with this...

Researching Asterisk source code. Now I'm convinced they expect developer to format body as 'Header1;value,Header2:value' etc. Which of course makes sense.

Which means the specific issue I'm reporting is void and can be closed.
However... I believe I definitely identified a problem with protocol parser (lexer). Under no circumstances should it be dying like this. Even if input is complete garbage. Think about a situation when Asterisk is upgraded and now it can send one extra event which is slightly different from others. It will be unpleasant surprise if Adhearsion event connection will be hanging each time it encounters such an event.

Unfortunately I do not understand lexer's grammar so I can not point you to some place I consider a problem :( but general logic to me is following:
1. I would disallow values containing cr or lf just like key can not contain them.
2. I would use loose_crlf everywhere in protocol not requiring strict crlf even if spec says so. In fact I would rename loose_newline to newline (just to shorten name) and would replace all (or most) usages of crlf to newline.
3. I would allow any message to have a "rest_of_message" at the end. Where rest_of_message is just rest_of_line zero or more times.

The main idea is to organize things in a way so double CRLF always break the current message/event - first CRLF breaks current line or keyvalue pair and the second serves as message terminator.(Of course with exception of Response: Follows case) This way we can loose one message if we can not parse it properly but we will re-sync on next 2xCRLF and will get next one successfully.

And of course-of course-of course before doing things like this, we need some unit-test coverage for the lexer. You will sleep much safer knowing that some modification of a lexer you did does not break all other things. If you create some testing framework for the lexer, I can probably participate in adding more tests.