A user points out (via personal email) that libevent supports weird sequences of (CR|LF)+ as HTTP line-endings, while HTTP requires only CR LF and recommends only LF as a regrettable heresy. Other weird sequences (LF CR, CR) should not be accepted.
So, this seems to be an underlying problem with evbuffer_readline. I don't want to change the current behavior of this function, since although it may be daft for HTTP, it is less than wholly crazy for other protocols.
Options include:
1 Add a new function, evbuffer_readline_crlf(evbuffer) that accepts
a line terminated by \r\n or \n.
2 Add a new function, evbuffer_readline2(evbuffer, flags) that takes
flags to set the end-of-line style.
3 Add a new function, evbuffer_set_eol_style(evbuffer, flags) that
changes future behavior of evbuffer_readline on the offending buffer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How about adding a new function? This might even be wholly internal if we don't want to export. This would be your option 2. I just wonder if we should take a flags approach or let the caller specify the delimiters explicitly? In any case, the current evbuffer_readline should be a specialization of the new more generic function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=499
Originator: YES
So, this seems to be an underlying problem with evbuffer_readline. I don't want to change the current behavior of this function, since although it may be daft for HTTP, it is less than wholly crazy for other protocols.
Options include:
1 Add a new function, evbuffer_readline_crlf(evbuffer) that accepts
a line terminated by \r\n or \n.
2 Add a new function, evbuffer_readline2(evbuffer, flags) that takes
flags to set the end-of-line style.
3 Add a new function, evbuffer_set_eol_style(evbuffer, flags) that
changes future behavior of evbuffer_readline on the offending buffer.
Logged In: YES
user_id=245089
Originator: NO
How about adding a new function? This might even be wholly internal if we don't want to export. This would be your option 2. I just wonder if we should take a flags approach or let the caller specify the delimiters explicitly? In any case, the current evbuffer_readline should be a specialization of the new more generic function.
Logged In: YES
user_id=499
Originator: YES
Fixed in svn trunk r550-r551.