[Live-devel] Problem with RTSPServer::RTSPClientSession::incomingRequestHandler1() and SET_PARAMETER & GET_PARAMETER

[Matt Schuckmann]

Am I correct in assuming that all RTSP requests must start with a alpha 
character?

I'm trying to do some simple validation and ignoring of garbage that 
might come across the RTSP TCP socket and I'm thinking that if we are 
waiting to receive the start of a new RTSP request we can throw away 
anything that's not a alpha character (as determined by the isAlpha() 
function). Sound reasonable?

Thanks
Matt S.


Matt Schuckmann wrote:
> Thanks for the info.
> I'm working on writing a RTSPRequest handler class to handle receiving 
> request, across multiple transport packets, deal with the 
> Content-length header, and I'll try to roll the 
> ParseRTSPRequestString() code into it. I'm also going to add some 
> minimal code to ignore interleaved RTP/RTCP messages just because that 
> other problem is getting in my way right now.
>
> One question I have is does the capitalization of the headers matter? 
> In the RTSP standard it looks like it supposed to be "Content-Length" 
> however I see it as both "Content-Length" and "Content-length".  I 
> suppose to be truly versatile it should be a case insensitive match.
>
> Thanks,
> Matt S.
>
>
>
> Ross Finlayson wrote:
>>> I guess the solution is going to have to be to make this while loop 
>>> smarter to detect what type of command is being received and if it's 
>>> a GET or SET look at the content-length header to determine how much 
>>> data needs to be read.
>>
>> Yes.  In fact, the code should really be looking for (and handing, if 
>> present) a "Content-Length:" header for *any* command (not just 
>> ?ET_PARAMETER), in case people want to subclass the server code to 
>> handle non-standard custom data of some sort (ugh).
>>
>>
>>> Any on the best way to accomplish this? Is there generalized header 
>>> parsing code anywhere in the library.
>>
>> No, not really.
>>
>>
>>> PS. The current code appears to work most of the time in that 
>>> generally an entire message comes in at once and the server passes 
>>> all the data it received on to the lower level handling code, even 
>>> the stuff that is beyond what it thinks was the end of the message. 
>>> However, if the socket receive code ever split the message up after 
>>> the first <CR><LF><CR><LF> the server could get very confused.
>>
>> Yes.  We already handle messages that get split before the \r\n\r\n, 
>> or even those that get split in the midst of the \r\n\r\n.  The code 
>> would also need to handle the possibility of getting the 
>> "Content-Length:" bytes of data in multiple chunks.
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>