<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>Range header parsing</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Ross,<BR>
<BR>
I would note that within the parseRangeHeader function (in the file liveMedia/RTSPServer.cpp), the Range header is parsed expecting spaces to be present between the elements of the NPT specification. See below:<BR>
<BR>
590 float start, end;<BR>
591 if (sscanf(fields, "npt = %f - %f", &start, &end) == 2) {<BR>
592 rangeStart = start;<BR>
593 rangeEnd = end;<BR>
594 } else if (sscanf(fields, "npt = %f -", &start) == 1) {<BR>
595 rangeStart = start;<BR>
596 } else {<BR>
597 return False; // The header is malformed<BR>
598 }<BR>
<BR>
Is there a reason for the parsing of NPT information in this manner? The specification of NPT within RFC2326 does not appear to include spaces between NPT elements. And I would additionally note that even when Range headers are returned by the liveMedia library, these do not include spaces between NPT elements.<BR>
<BR>
As such I would propose the following amendment of this code (which maintains operability with existing code which may depend upon this specification of NPT information):<BR>
<BR>
590 float start, end;<BR>
591 if (sscanf(fields, "npt = %f - %f", &start, &end) == 2 ||<BR>
592 sscanf(fields, "npt=%f-%f", &start, &end) == 2) {<BR>
593 rangeStart = start;<BR>
594 rangeEnd = end;<BR>
595 } else if (sscanf(fields, "npt = %f -", &start) == 1 ||<BR>
596 sscanf(fields, "npt=%f-", &start) == 1) {<BR>
597 rangeStart = start;<BR>
598 } else {<BR>
599 return False; // The header is malformed<BR>
600 }<BR>
<BR>
Regards,<BR>
Rob<BR>
</FONT>
</P>
</BODY>
</HTML>