Disclaimer: This repository is a git-svn mirror of the project found at http://java.net/projects/jsip whose original repository is developed collaboratively by the Advanced Networking Technologies Division at the National Institute of Standards and Technology (NIST) - an agency of the United States Department of Commerce and by a community of individual and enterprise contributors. TeleStax, Inc. will perform some productization work, new features experimentation branches, etc for its TelScale jSIP product that doesn't concern the community from the main repository hence this git repository.
Run into issue with NioPipelineParser when processing SIP message with an extra CRLF at the end of message body received over TCP connection that stays alive forever.
Say SIP message has "Content-length" reported as 20000 and body that ends with double CLRF like:
messagebody\r\n\r\n
Only first \r character included in "Content-length" so we end up with \n\r\n characters at the end.
Parser switch back to message headers processing and read \n as line of new message headers then see \r\n and treat it as headers separator switching back to message body processing. Because it didn't read any "Content-length" in this new fake message Content-length stays at 20000
So now any subsequent message we receive on same TCP channel goes straight to body of that fake message until we accumulate enough bytes to meet 20000 Content-length mark. Then it switch back to headers processing and read tail of last message received as headers of another new fake message. And so on.
It is able to recover if at some point it read "Content-length" of one of subsequent messages that set to "0" while processing message headers.
But goes into this loop again on next message with extra CRLF at the end of body
From SIP RFC 3261 :
7.5 Framing SIP Messages
Implementations processing SIP messages over stream-oriented
transports MUST ignore any CRLF appearing before the start-line
[H4.1].
The Content-Length header field value is used to locate the end of
each SIP message in a stream. It will always be present when SIP
messages are sent over stream-oriented transports.
From HTTP/1.1 RFC 2616 referred in SIP RFC:
4 HTTP Message
4.1 Message Types
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
Run into issue with NioPipelineParser when processing SIP message with an extra CRLF at the end of message body received over TCP connection that stays alive forever.
Say SIP message has "Content-length" reported as 20000 and body that ends with double CLRF like: messagebody\r\n\r\n
Only first \r character included in "Content-length" so we end up with \n\r\n characters at the end. Parser switch back to message headers processing and read \n as line of new message headers then see \r\n and treat it as headers separator switching back to message body processing. Because it didn't read any "Content-length" in this new fake message Content-length stays at 20000 So now any subsequent message we receive on same TCP channel goes straight to body of that fake message until we accumulate enough bytes to meet 20000 Content-length mark. Then it switch back to headers processing and read tail of last message received as headers of another new fake message. And so on.
It is able to recover if at some point it read "Content-length" of one of subsequent messages that set to "0" while processing message headers. But goes into this loop again on next message with extra CRLF at the end of body
From SIP RFC 3261 :
7.5 Framing SIP Messages
Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1]. The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports.
From HTTP/1.1 RFC 2616 referred in SIP RFC:
4 HTTP Message 4.1 Message Types
In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.