[Live-devel] Handle carriage return/line feed in base64Decode

[Chris Richardson (WTI)]

Hi Ross,

 

I recently came across a client who sends our LIVE555 based RTSP server an
HTTP message with a base64 encoded RTSP command that contains CR/LF.  It
seems fairly standard for a base64 decoder to support CR/LF, at least on 4
char boundaries, so I wrote up a patch to base64Decode to allow this.  Then
I discovered how the fragmented base64 message reading  is implemented in
RTSPServer and determined that the fix would not be so simple.

 

I have pasted the relevant part of the RTSP conversation, for your
information.  Note that the client (not under my control) is using a very
old version of LIVE555, but that is irrelevant to the test being performed,
which is that the server supports base64 data with CR/LF.

 

accept()ed connection from 192.168.2.100

RTSPClientConnection[0x5cc908]::handleRequestBytes() read 212 new bytes:GET
/swVideo HTTP/1.0

User-Agent: ONVIF Filter (LIVE555 Streaming Media v2009.11.27)

x-sessioncookie: 0695c54a1abd2adfb783b89

Accept: application/x-rtsp-tunnelled

Pragma: no-cache

Cache-Control: no-cache

 

 

parseRTSPRequestString() failed; checking now for HTTP commands (for
RTSP-over-HTTP tunneling)...

parseHTTPRequestString() succeeded, returning cmdName "GET", urlSuffix
"swVideo", sessionCookie "0695c54a1abd2adfb783b89", acceptStr
"application/x-rtsp-tunnelled"

Handled HTTP "GET" request (client output socket: 31)

sending response: HTTP/1.0 200 OK

Date: Thu, 19 Aug 1982 18:30:00 GMT

Cache-Control: no-cache

Pragma: no-cache

Content-Type: application/x-rtsp-tunnelled

 

accept()ed connection from 192.168.2.100

RTSPClientConnection[0x5d1788]::handleRequestBytes() read 281 new bytes:POST
/swVideo HTTP/1.0

User-Agent: ONVIF Filter (LIVE555 Streaming Media v2009.11.27)

x-sessioncookie: 0695c54a1abd2adfb783b89

Content-Type: application/x-rtsp-tunnelled

Pragma: no-cache

Cache-Control: no-cache

Content-Length: 32767

Expires: Sun, 9 Jan 1972 00:00:00 GMT

 

----------

Below you can see that the base64 input has line breaks, which the decoder
does not handle.

----------

 

parseRTSPRequestString() failed; checking now for HTTP commands (for
RTSP-over-HTTP tunneling)...

parseHTTPRequestString() succeeded, returning cmdName "POST", urlSuffix
"swVideo", sessionCookie "0695c54a1abd2adfb783b89", acceptStr ""

Handled HTTP "POST" request (client input socket: 35)

RTSPClientConnection[0x5cc908]::handleRequestBytes() read 210 new
bytes:REVTQ1JJQkUgcnRzcDovLzE5Mi4xNjguMi42Mjo4NTU0L3N3VmlkZW8gUlRTUC8x

LjANCkNTZXE6IDANCkFjY2VwdDogYXBwbGljYXRpb24vc2RwDQpVc2VyLUFnZW50

OiBPTlZJRiBGaWx0ZXIgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDA5LjEx

LjI3KQ0KDQo=

Base64-decoded 208 input bytes into 156 new bytes:DESCRIBE
rtsp://192.168.2.62:8554/swVideo RTSP/1ã?56W¢?66WC¢?6Föâ÷6G?W6W"ÔvVç@: ONVIF
Filter (LIVE555 Streaming Media v2009.11ã#r?Ð

 

 

Thanks,

 

Chris Richardson

WTI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130621/80e60558/attachment.html>