> Perhaps, though an empty string ("") would be returned if the
> server's response included a "Public:" header that was empty - i.e.
>
> Public:
Ok, that make sense
>
> >But in this case it would be good to note this can happen in the
> >function description.
>
> Yes, we already do ("RTSPCl
On Fri, 2011-02-04 at 01:10 -0800, Ross Finlayson wrote:
No, this is not a bug. As you can see, the server is some
brain-damaged non-standard Microsoft thing. It's not including a
"Public:" header in its response to our RTSP "OPTIONS" command. So,
as far as our client is concerned, this is
On Fri, 2011-02-04 at 01:10 -0800, Ross Finlayson wrote:
> No, this is not a bug. As you can see, the server is some
> brain-damaged non-standard Microsoft thing. It's not including a
> "Public:" header in its response to our RTSP "OPTIONS" command. So,
> as far as our client is concerned, th
I have a case where the response to a "sendOptionsCommand" returns no
error, (result = 200) but the result string is NULL.
I read RTSPClient.hh and the description of the responseHandler isn't
very clear if this can be possible.
Could you tell me if it's a bug, in the library ?
I noticed you call
Hi,
I have a case where the response to a "sendOptionsCommand" returns no
error, (result = 200) but the result string is NULL.
I read RTSPClient.hh and the description of the responseHandler isn't
very clear if this can be possible.
Could you tell me if it's a bug, in the library ?
I noticed you c
