Hi, Stumbled on section 9.2 in the RFC 2326, which is explicit:
Unlike HTTP, an RTSP message MUST contain a Content-Length header whenever that message contains a payload. Otherwise, an RTSP packet is terminated with an empty line immediately following the last message header. So, no Content-length header -> don't wait for data Regards, Erik -----Original Message----- From: curl-library [mailto:[email protected]] On Behalf Of Erik Janssen Sent: maandag 29 september 2014 9:34 To: [email protected] Subject: RE: rtsp authentication not working Hi Daniel, This is a follow-up to an earlier thread. Couldn't reply to the last message because I was only receiving the digest. > Looking at that old thread now, it seems I didn't get a very good > answer to the 401/407 treatment and that disturbs me. Why is the second patch > necessary? With HTTP it is feasible for a server to provide content in case of authentication failure, like a 'no trespassing' page for example. RTSP is different. The DESCRIBE, SETUP, PLAY is a machine-machine interaction and there is no way to sent human-readable stuff for viewing in case something is wrong. The back-end, typically a video decoder, has no way to know how to decode such content anyway because the format of the content is not specified in RTSP header responses. It is specified in the SDP that is sent in the DESCRIBE body. But, if client can't authenticate the server must not provide the SDP because with that it is providing clues about its content. Therefore, it makes much sense for an RTSP server to always respond without a body in case of authentication failure. Your question was whether it is not allowed to send respnse bodies in case of 401 or 407. I agree this is not clear from the RFC. Above I try to convince you why it makes no sense. Note that the typical response does indicate there is no body. See section 4.4 of rfc2326: If the Content-Length header is absent, a length 0 must be assumed. Below is the traffic between an authenticating RTSP server and non-authenticating, I prefixed the requests with '-': - OPTIONS rtsp://192.168.0.25/axis-media/media.amp RTSP/1.0 - CSeq: 1 RTSP/1.0 200 OK CSeq: 1 Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN Date: Wed, 10 Sep 2014 22:16:33 GMT - DESCRIBE rtsp://192.168.0.25/axis-media/media.amp RTSP/1.0 - CSeq: 2 - Accept: application/sdp - If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT RTSP/1.0 401 Unauthorized CSeq: 2 WWW-Authenticate: Digest realm="AXIS_00408CD7B936", nonce="000012ceY92591460e176d3cd9ed5b899e06bfda317ea6", stale=FALSE WWW-Authenticate: Basic realm="AXIS_00408CD7B936" Date: Wed, 10 Sep 2014 22:16:33 GMT So, here it says by not saying a length that there is no body and libcurl should not wait for it. Now, looking at the patch from 2011 again I think it is not good enough, although it happens to work. It shouldn't check for 401 or 407, there are many more 4xx responses for which there will be no body. It should check for a body content-length of 0 instead. Does this clarify? You also mentioned testing. How should a test look like? I could help with testcases and probably hardware. Regards, Erik Message: 3 Date: Fri, 26 Sep 2014 13:50:11 +0200 (CEST) From: Daniel Stenberg <[email protected]> To: libcurl development <[email protected]> Subject: Re: rtsp authentication not working Message-ID: <[email protected]> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII On Fri, 26 Sep 2014, Erik Janssen wrote: > http://comments.gmane.org/gmane.comp.web.curl.library/32043 > > This e-mail to plead for inclusion of this fix in the library itself. > With authentication-support libcurl is much nicer than live555, and > simpler than gstreamer, for use with IP video cameras. Without, it is > not useable. Why has it never been integrated? I think it was never integrated primarily because nobody was around and pushed hard enough for it. We basically always have more work and stuff in the queue than what we have time for so if someone drops a ball it gets lost in the stream and we may never find it again. It happens all the time. Persistance and patience are keys. Other common reasons include that we don't get good enough code, lack documentation and don't get tests for new things. RTSP of course generally lack in the test department and this patch was no exception which makes me more careful when considering code changes. Looking at that old thread now, it seems I didn't get a very good answer to the 401/407 treatment and that disturbs me. Why is the second patch necessary? -- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
