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

[Matt Schuckmann]

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.